PHP2Shell : vulnérabilité critique de PHP — votre site web est-il menacé ?

Toutes les versions de PHP plus anciennes, dans leur branche, que 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sont concernées, ce qui veut dire presque chaque site web en PHP que personne n’a mis à jour cette semaine. Aujourd’hui, le premier travail est de savoir quelle version sert votre site web, puis de la mettre à jour : il n’existe pas de solution de contournement complète, et l’annonce de PHP elle-même dit que la mise à jour est le seul choix sûr.

Mercredi 21 octobre, l’équipe PHP a publié en même temps quatre versions d’urgence. Le couple de vulnérabilités qu’elles corrigent a reçu le nom PHP2Shell, et ce nom décrit le résultat avec précision : d’une requête réseau jusqu’à l’exécution de code sur le serveur. Cet article porte sur ce qui a été trouvé exactement, sur la façon de comprendre si cela vous concerne, et sur l’ordre dans lequel agir, y compris lorsque vous ne pouvez pas mettre à jour tout de suite.

PHP2Shell et ce qui s’est passé le 21 octobre

L’annonce officielle dit que 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux vulnérabilités critiques, qui peuvent permettre à un attaquant non authentifié d’exécuter du code à distance, et que tous les utilisateurs de PHP sont fortement invités à se mettre à jour sans attendre. On y trouve aussi la phrase qui détermine tout le reste de cet article : il n’existe pas de solution de contournement complète, et la mise à jour est le seul choix sûr.

PHP a attribué aux deux vulnérabilités la note Common Vulnerability Scoring System (CVSS) v4.0 9.2 sur 10, mais ce sont deux bogues distincts, avec des mécanismes différents et, comme vous le verrez plus loin, un degré de confirmation différent : c’est précisément cette seconde différence qui, en pratique, décide par quel serveur commencer.

CVE-2026-109618 — mémoire corrompue après un out-of-memory (OOM) : lorsque PHP vient à manquer de mémoire, il utilise longjmp() pour interrompre le traitement de la requête. La description officielle indique qu’à certains moments la mémoire de la requête est accessible avant d’être entièrement initialisée ; si l’allocation de mémoire échoue exactement à cet instant, l’interruption n’est pas traitée correctement et il reste une mémoire invalide, que le code exécuté à la fin de la requête lit encore ou d’après laquelle il prend une décision.

Un détail important change le champ de cette menace : le manque de mémoire est obtenu par une requête multipart préparée à cet effet, et cette requête n’a pas à contenir le moindre fichier téléversé. La description officielle mentionne plusieurs problèmes de traitement multipart : une requête sans longueur déclarée utilisable, une partie avec un nombre illimité d’en-têtes, des champs de fichier vides qui ne sont pas comptés dans les limites. Cela signifie que la requête peut être tout à fait petite et rester dans les limites ordinaires de post_max_size et de memory_limit.

CVE-2026-109619 — état global périmé : dans un processus PHP, un état global persiste entre les requêtes : les données d’erreurs, de sessions, d’objets et d’extensions. La description officielle dit que cet état doit être réinitialisé avant que la mémoire de la requête soit libérée. Si une erreur fatale interrompt la réinitialisation, ou si, au moment de la fin, le diagnostic la remplit de nouveau, la mémoire est libérée mais le pointeur vers elle demeure. Cette classe de bogue s’appelle internationalement une utilisation après libération (use-after-free).

Vient ensuite la condition qui rend cette vulnérabilité plus difficile qu’elle n’en a l’air : le pointeur périmé ne peut être utilisé que par une action qui se produit avant l’initialisation ordinaire de la requête, et la description officielle nomme deux cas confirmés de ce genre, le diagnostic INI et le traitement de la progression de téléversement de session. De plus, la requête ultérieure de l’attaquant doit arriver exactement dans le même processus que celui où l’état corrompu est apparu, de sorte qu’une tentative isolée réussit rarement ; la description indique explicitement que plusieurs processus et leur remplacement réduisent les chances, mais n’éliminent pas la condition elle-même.

Dans quelle mesure c’est exploitable, et contre quoi cela a été démontré

Il vaut la peine d’être précis ici, parce que c’est exactement à cet endroit que la plupart des articles sur internet exagèrent, dans un sens ou dans l’autre.

Aucun mot de passe n’est nécessaire, et il n’est pas nécessaire non plus que quelqu’un clique quelque part sur le site : dans le vecteur CVSS, cela se lit PR:N et UI:N. Le même vecteur porte pourtant AC:H et AT:P, donc une complexité d’attaque évaluée comme élevée et des prérequis supplémentaires ; en pratique, cela signifie des tentatives répétées, et la réussite dépend du build de PHP, des extensions, du comportement du frontal et de la disposition de la mémoire. Donc non : une seule requête ordinaire ne suffit pas, mais cela ne coûte rien non plus à l’attaquant, parce que rien ne limite le nombre de tentatives.

Le degré de preuve diffère entre les deux bogues, et cette différence compte lorsqu’il s’agit de choisir à quel point se presser. Dans le cas de CVE-2026-109618, une exécution de code à distance (RCE) complète a été confirmée contre mod_php avec les limites d’entrée et de mémoire par défaut ; pour PHP-FPM, la même description dit que l’analyse du code source le tient pour vulnérable, mais qu’une attaque PHP-FPM complète n’a pas été démontrée. FrankenPHP y est mentionné comme analogue de mod_php, et LSAPI comme analogue de PHP-FPM, dans les deux cas sans attaque vérifiée.

Dans le cas de CVE-2026-109619, le chemin du cycle de vie de la session a été vérifié à la fois contre mod_php et contre PHP-FPM, tandis que l’autre chemin, qui passe par la trace de l’erreur fatale, n’est confirmé que contre mod_php.

Il en résulte un ordre pratique : si votre site web tourne sur mod_php, vous êtes en première ligne, parce que c’est précisément là que les deux bogues ont été confirmés. Pour PHP-FPM et LiteSpeed, le risque est réel, mais pour l’instant seulement en partie confirmé. Aucun de ces cas n’est une raison d’attendre : c’est une raison de savoir par quel serveur commencer.

Comment cette semaine s’est déroulée, heure par heure

La chronologie n’est pas une curiosité : elle explique pourquoi les recommandations des premières heures différaient de celles qui valent maintenant, et pourquoi une partie des articles sur internet sont encore périmés.

Le soir du 20 octobre, on savait que quelque chose arrivait, mais pas quoi exactement : PHP avait annoncé une publication d’urgence à venir, et la page de statut de CloudLinux constate le même soir qu’il est prévu de publier les données techniques et les versions concernées au moment de la publication du lendemain. La description technique n’était pas encore publique à ce moment-là.

Le lendemain, la situation avait changé, et pas pour le mieux : le matin du 21 octobre, CloudLinux constate qu’un modèle d’attaque circule déjà publiquement, et à 9 h 08 UTC il diffuse un jeu de règles de pare-feu applicatif (WAF) qui bloque le modèle de requête d’exploitation connu. Dix-huit minutes plus tard, la même page porte la phrase qui caractérise le mieux cette semaine : des tentatives correspondant à ce modèle sont déjà observées, donc quelqu’un cherchait déjà les serveurs qui n’avaient pas encore le correctif de sécurité.

Les correctifs de PHP sont sortis à 14 h 00 UTC, ce qui signifie que plusieurs heures se sont écoulées entre un modèle d’attaque publiquement disponible et un correctif publiquement disponible, et que pendant ces heures les tentatives d’attaque avaient déjà lieu.

Une réserve s’impose ici, en toute honnêteté : le monde n’était pas entièrement sans correctif, parce que l’annonce de PHP dit que les distributions Linux et les fournisseurs de support à long terme ont reçu les correctifs à l’avance, de sorte que pour une partie des serveurs la mise à jour était disponible plus tôt que pour les autres ; publiquement disponible, elle ne l’était pour personne.

Ensuite a commencé la partie la plus longue, qui continue encore : la distribution des paquets. Les mainteneurs de systèmes d’exploitation et les plateformes d’hébergement construisent leurs paquets séparément, et ils apparaissent en quelques heures ou quelques jours, chacun à son rythme. C’est précisément à ce stade que se trouve une grande partie des utilisateurs d’hébergement mutualisé, et c’est précisément pourquoi la question « le correctif est-il sorti » et la question « le correctif est-il sur mon serveur » sont cette semaine deux questions différentes, avec des réponses différentes.

Votre site web est-il menacé

Dans les avertissements officiels, les plages de versions concernées sont écrites ainsi : tout ce qui est plus ancien que 8.2.35, tout ce qui est plus ancien que 8.3.36, tout ce qui est plus ancien que 8.4.27, et tout ce qui est plus ancien que 8.5.12, chacun dans sa branche.

Un détail important, qui prête à l’erreur : le chiffre que montre php -v ne dit pas toujours tout. Les distributions Linux et les plateformes d’hébergement ont l’habitude de rétroporter le correctif sur une version plus ancienne sans en changer le numéro ; seul le numéro de version du paquet change. Dans ce cas, 8.4.26 peut déjà être corrigé, mais peut aussi ne pas l’être. La seule façon de le savoir est de regarder la description du paquet ou de demander au fournisseur ; le numéro de version lui-même ne répond pas à cette question.

Un mot à part sur les versions plus anciennes. PHP 8.1 et les versions plus anciennes ne reçoivent plus de mises à jour régulières de la part du projet PHP ; toutefois, compte tenu de la gravité, l’équipe de sécurité a préparé des correctifs minimaux du code source pour les versions 7.4, 8.0 et 8.1, à l’intention de ceux qui construisent à partir du code source ou qui n’ont pas accès au support d’un mainteneur. L’annonce recommande au même endroit de contacter votre fournisseur, parce qu’une partie des distributions et des fournisseurs de support à long terme rétroportent les correctifs. Si votre site web tourne sur PHP 7.x, le vrai problème n’est pas cette semaine : le vrai problème est que, la prochaine fois, le correctif peut aussi ne pas exister. Et PHP 8.2, qui a reçu un correctif cette fois, arrive en fin de vie le 31 décembre 2026.

Comment vérifier la version, selon l’endroit où le site web tourne

La vérification prend des minutes, et il vaut la peine de la faire pour chaque site web séparément, et non pour chaque serveur : sur un même serveur vivent souvent des sites web avec des versions de PHP différentes, et d’ordinaire c’est précisément le plus ancien, celui que tout le monde a oublié, qui est accessible publiquement.

Hébergement mutualisé avec cPanel : la version s’affiche dans la section MultiPHP Manager, où chaque domaine a sa propre ligne ; Plesk utilise pour la même chose Paramètres PHP à l’intérieur de chaque abonnement. Dans les deux cas, il vaut la peine de vous assurer que vous regardez le domaine dont il est question, et non la valeur par défaut du serveur.

Votre propre serveur ou un VPS (serveur privé virtuel) : en ligne de commande, php -v l’affiche, avec une réserve essentielle, à savoir que le PHP de la ligne de commande est souvent une version tout à fait différente de celle qui sert les requêtes web. La réponse la plus fiable vient du même chemin que celui par lequel le site web fonctionne, le fichier exécutable indiqué dans la section pool de la configuration PHP-FPM.

Conteneurs : si le site web tourne dans un environnement Docker, la version est déterminée par l’image, et non par la machine hôte, d’où deux étapes : reconstruire l’image avec une image de base mise à jour, puis redémarrer les conteneurs. Une image construite avant le 21 octobre ne contient pas le correctif, quel que soit le nombre de fois où le conteneur a été redémarré.

Si vous n’avez accès à aucun de ces moyens : la question va alors au fournisseur d’hébergement, et cette semaine c’est une question tout à fait normale, à laquelle ils ont déjà une réponse prête. La formulation qui vous évitera plusieurs allers-retours : « Quelle version de PHP sert mon domaine, le correctif PHP2Shell y est-il, et, s’il n’y est pas encore, à quelle date y sera-t-il ? »

Que faire aujourd’hui

L’ordre d’aujourd’hui est le suivant : d’abord mettre à jour PHP et redémarrer tout ce qui l’exécute, puis vous assurer que les visiteurs sont vraiment servis par la nouvelle version, ensuite vérifier si le dépôt de paquets utilisé a bel et bien publié le correctif, et seulement ensuite chercher des traces. La première étape prend des minutes, la dernière peut prendre des jours, et c’est précisément pourquoi il ne vaut pas la peine de les intervertir.

Premièrement, mettez à jour : dans le cas d’un hébergement infogéré, c’est le fournisseur qui le fait, et votre travail est de poser la question et d’obtenir une date. Si vous administrez le serveur vous-même, après la mise à jour des paquets il faut redémarrer ce qui exécute PHP : Apache, PHP-FPM ou LSAPI. Cette étape est sautée étonnamment souvent : le paquet a été remplacé, mais les anciens processus continuent de tourner avec l’ancien code, de sorte que la vérification montre la nouvelle version pendant que les visiteurs sont servis par l’ancienne.

Deuxièmement, vérifiez que la mise à jour est vraiment appliquée, par le même chemin que celui par lequel le site web fonctionne, et non par la ligne de commande.

Troisièmement, si vous utilisez un dépôt de paquets maintenu bénévolement, vérifiez s’il a publié le correctif. L’annonce de PHP contient un avertissement distinct au sujet de rpms.remirepo.net : il est recommandé à ses utilisateurs de passer aux paquets de la distribution ou de construire à partir du code source.

Quatrièmement, seulement ensuite, vérifiez s’il n’y a pas de traces sur le site web. La mise à jour ferme la porte, mais elle ne répond pas à la question de savoir si quelqu’un est déjà entré par là.

Si vous ne pouvez pas mettre à jour tout de suite

Cette section est à lire en gardant bien à l’esprit qu’aucune des étapes mentionnées ici ne remplace la mise à jour, et l’annonce de PHP le dit expressément.

Contre CVE-2026-109618, l’annonce mentionne la suppression de la mémoire limite, memory_limit=-1, et de telle sorte que l’application ne puisse pas la réécrire, par exemple avec php_admin_value dans la configuration de PHP-FPM ou d’Apache, en vous assurant qu’aucun autre réglage ne rétablit ensuite la limite finie. Il faut comprendre ce que ce choix coûte : sur un serveur mutualisé, il échange un risque contre un autre, parce qu’une seule requête peut maintenant consommer toute la mémoire disponible. La description de la vulnérabilité avertit aussi de ne pas utiliser RLIMIT_AS et RLIMIT_DATA, parce qu’ils peuvent faire échouer l’allocation de mémoire et conduire ainsi précisément au chemin vulnérable.

Contre CVE-2026-109619, l’annonce mentionne session.upload_progress.enabled=0 et, pour PHP 8.5, fatal_error_backtraces=0, dans les deux cas avec l’indication de redémarrer ensuite tous les processus. La description de la vulnérabilité elle-même mentionne aussi pm.max_requests=1, qui fait remplacer le processus de travail de PHP-FPM après chaque requête ; c’est un réglage du pool PHP-FPM, et il y est mentionné avec la réserve « si la performance n’est pas un facteur ». Il y est dit aussi ce qui tient cette mesure dans ses justes limites : le remplacement des processus réduit les chances par requête, mais n’élimine pas la condition elle-même.

Utile aussi, ce qui n’est pas un contournement mais réduit la surface d’attaque : un post_max_size conservateur, une profondeur d’imbrication des entrées raisonnable, et un volume de téléversement limité. Ce sont de bonnes valeurs pour n’importe quelle semaine, pas seulement pour celle-ci.

Comment savoir si vous êtes déjà touché

Après la mise à jour, il vaut la peine de revoir les journaux du serveur web des derniers jours. Ce qu’il faut chercher, c’est un nombre inhabituellement grand de requêtes multipart vers une seule et même adresse, et ici il est facile de chercher au mauvais endroit : elles ont tendance à être petites et à rester dans les limites ordinaires, de sorte que l’on ne les trouvera pas d’après le volume. Plus parlantes sont les séries soudaines d’erreurs 500, qui commencent et finissent sans raison visible : une attaque qui repose sur le manque de mémoire échoue beaucoup plus souvent qu’elle ne réussit, et chaque tentative infructueuse laisse une erreur.

Dans le système de fichiers, ce sont les dates de modification qui comptent : un fichier PHP modifié pendant la nuit, alors que personne ne travaillait, doit être expliqué. Il vaut aussi la peine de vérifier les tâches planifiées et les entrées qui assurent un lancement automatique après un redémarrage, car pour un attaquant qui dispose de l’exécution de code le premier travail est de prendre pied, afin que l’accès survive précisément à la mise à jour que vous venez d’installer.

Par ailleurs, il vaut la peine de vérifier la liste des comptes d’administrateur ainsi que les mots de passe et les clés de l’application. Si une exécution de code a eu lieu, alors tout ce que le serveur connaît doit être tenu pour lu, y compris les données de connexion à la base de données et les clés d’API dans le fichier de configuration.

Si quelque chose parmi cela ne semble pas correct, le nettoyage est un travail à part, avec son propre ordre, et il vaut la peine de le faire méthodiquement, plutôt qu’en supprimant les fichiers suspects un par un. Nous avons décrit séparément comment se déroule la récupération d’un site piraté, et, si vous voulez que quelqu’un d’autre le fasse, la récupération de site web piraté est un service à part, avec un ordre fixe : isolement, nettoyage, élimination de la cause, et vérification que le site web a été retiré des listes d’avertissement des moteurs de recherche.

Quand l’événement devient un incident à notifier

S’il y a lieu de penser que l’attaquant a accédé à des données à caractère personnel, la question technique devient aussi juridique. Le règlement général sur la protection des données prévoit un délai qui ne commence pas à l’attaque, mais au moment où le responsable du traitement a eu connaissance de la violation de données à caractère personnel : si possible, 72 heures au plus tard pour la notification à l’autorité de contrôle. L’obligation ne naît pas lorsque la violation est peu susceptible d’engendrer un risque pour les droits et libertés des personnes physiques ; et, si le risque est élevé, les personnes concernées elles-mêmes doivent aussi être informées. Cette obligation a elle aussi ses exceptions dans le règlement.

La portée pratique de cette section tient en un seul point : le moment où quelque chose de suspect a été trouvé dans les journaux n’est pas le moment où les 72 heures commencent à courir : c’est le moment où il faut établir s’il y a bel et bien eu violation. Une série isolée d’erreurs 500 qui, comme décrit plus haut, est le plus souvent une tentative infructueuse, n’est pas en elle-même une violation. Mais c’est précisément pourquoi cette vérification ne vaut pas la peine d’être reportée à « quand il y aura moins de travail », et c’est précisément pourquoi les journaux doivent être conservés avant que la rotation ne les réécrive : ils sont la seule preuve à la fois de ce qui s’est passé et de ce qui ne s’est pas passé.

Si plusieurs sites web sont sous votre responsabilité

Pour les agences et les entreprises qui ont plusieurs sites web, cette semaine est moins une tâche technique qu’une tâche d’organisation, et l’ordre qui fonctionne est simple : d’abord la liste, puis les versions, puis la mise à jour par ordre de priorité.

La priorité n’est pas fixée par l’importance du site web, mais par l’accessibilité et par ce qui le sert. En haut se trouvent les sites web publiquement accessibles sur mod_php, parce que c’est précisément là que les deux vulnérabilités ont été confirmées ; ensuite le reste de ce qui est public, et seulement après les systèmes internes derrière un pare-feu. Les environnements de test et de développement, que tout le monde oublie, doivent figurer dans la liste obligatoirement : ils tournent souvent sur une version de PHP plus ancienne et sont souvent accessibles depuis internet, parce qu’à un moment cela avait été plus commode.

Les sites web qu’administre quelqu’un d’autre restent dans la liste, mais avec une autre colonne : à qui la question a été envoyée, et à quelle date la réponse a été reçue. Cette colonne se révèle plus tard plus précieuse que les autres, parce que c’est précisément elle qui montre quel fournisseur réagit et lequel ne réagit pas.

Ce que l’hébergement infogéré a signifié dans ce cas

Cette semaine montre bien où se trouve la frontière entre la plateforme et l’application, et il est donc honnête de dire comment cela s’est présenté de notre côté.

Nos serveurs tournent sur CloudLinux, et Imunify360 y est intégré. Lorsque le modèle d’attaque a commencé à circuler publiquement, CloudLinux a consigné sur sa page de statut qu’un jeu de règles de pare-feu applicatif bloquant le modèle d’exploitation connu avait été diffusé à 9 h 08 UTC, plusieurs heures avant que PHP ne publie le correctif lui-même à 14 h 00, et avant que la même page n’affiche une entrée disant que des tentatives étaient déjà observées. Dans la journée ont suivi encore deux compléments, dont le second bloque l’outil d’exploitation déjà publiquement disponible. Tout cela s’est fait automatiquement, sans participation du client. Dans le secteur, une telle mesure s’appelle virtual patching : une règle de pare-feu applicatif bloque l’exploitation de la vulnérabilité sans modifier le code vulnérable lui-même.

Et maintenant, ce qu’une telle phrase ne signifie pas, parce que c’est précisément ici que le secteur a vendu le plus d’exagérations cette semaine. Une règle de pare-feu applicatif bloque des modèles d’attaque connus, et CloudLinux emploie le même mot. La même page appelle cette mesure une solution provisoire, et non un correctif complet. Ce n’est pas une invulnérabilité, et CloudLinux lui-même continue de recommander de mettre PHP à jour dès que les paquets sont disponibles. La différence entre « protégé » et « corrigé » est cette semaine tout à fait concrète, et vendre l’un comme l’autre serait malhonnête.

L’aspect du correctif lui-même illustre bien ce dont nous avons averti plus haut. Nos serveurs ont reçu un nouveau build d’ea-php84 le soir du même jour, quelques heures après la publication de PHP. Le numéro de version n’a pas changé : php -v écrit toujours 8.4.26, et non 8.4.27, et la seule chose qui, de l’extérieur, témoigne du changement est la date de build, qui a sauté du 9 au 21 octobre. C’est exactement à cela que ressemble un correctif rétroporté, et c’est précisément pourquoi une question au fournisseur d’hébergement vaut mieux que le chiffre affiché à l’écran.

La valeur qu’a achetée ici l’hébergement infogéré n’est donc pas une invulnérabilité, mais une fenêtre plus étroite : les heures pendant lesquelles le modèle d’attaque circulait déjà et les tentatives avaient déjà lieu ont été couvertes par le blocage des modèles connus, plutôt qu’attendues. Et ensuite, que quelqu’un suive les paquets et redémarre les processus, au lieu d’attendre que le client s’en aperçoive. Notre hébergement infogéré commence à 45 €/mois, et ce sont précisément les semaines de ce genre qui sont ce que cette somme paie.

Si votre site web tourne en ce moment quelque part où il est impossible d’obtenir une réponse à la question de la version de PHP et de la date de mise à jour, cela constitue en soi une réponse. Parlons d’une migration — elle se fait d’ordinaire sans coupure.

Après la mise à jour, il faut redémarrer plus qu’il n’y paraît

Un processus qui reste vivant entre les requêtes n’a rien d’exotique : c’est exactement ainsi que fonctionnent un pool PHP-FPM ordinaire et mod_php, et c’est précisément contre eux que l’exécution de code a été confirmée. CVE-2026-109619 n’est donc pas une menace propre à des configurations particulières : c’est un problème de la configuration ordinaire.

Il en découle l’étape que l’on saute le plus souvent : le remplacement du paquet n’affecte pas un processus qui tourne déjà. Après la mise à jour, il faut redémarrer chaque processus qui exécute PHP, et cela vaut aussi pour ceux que personne ne touche d’habitude. Les processus PHP qui tournent longtemps ont tendance à ne pas redémarrer pendant des semaines, de sorte qu’après la mise à jour il vaut la peine de les recenser à part et de vous assurer que chacun d’eux a été relancé.

La bonne question de vérification n’est donc pas « que montre php -v », mais « chaque processus qui exécute PHP a-t-il été démarré après que le paquet a été remplacé ».

Pourquoi il ne suffit pas de dire « nous ne téléversons pourtant rien »

Une objection courante dit à peu près ceci : notre site web est un site vitrine, il n’y a ni formulaire de téléversement ni comptes d’utilisateurs, donc cela ne nous concerne pas. Malheureusement si, et la raison est exactement ce qui a été décrit plus haut : l’attaque n’a pas besoin d’un fichier téléversé, une requête multipart préparée à cet effet suffit, et elle peut être envoyée à n’importe quelle adresse qui répond avec PHP. La présence d’un formulaire sur la page n’est pas une condition préalable, parce que l’attaquant ne remplit pas le formulaire.

De même, il importe peu que le site web soit petit. Les attaques contre de telles vulnérabilités se font à grande échelle et automatiquement, et personne ne sélectionne selon le nombre de visiteurs. L’unité Unit 42 de Palo Alto Networks a, le jour de la publication, signalé plus de 22,6 millions d’instances PHP accessibles sur internet et potentiellement concernées ; aucune d’elles n’a été choisie en particulier.

La seconde objection porte sur WordPress et les extensions. Elle non plus ne tient pas cette fois, seulement dans le sens inverse : la vulnérabilité est dans PHP lui-même, et non dans WordPress, Laravel ou une extension. Cela signifie que la mise à jour des extensions ne résout pas ce problème, et en même temps que chaque site web en PHP est concerné, quel que soit ce sur quoi il est construit.

Ce qu’il vaut la peine de retenir de cette semaine

Pour ceux chez qui tout était en ordre, ce qui a bien fonctionné n’est pas une réaction rapide, mais trois choses qui avaient été mises en ordre plus tôt : on savait quel site web tournait sur quelle version de PHP, on savait qui répond de la mise à jour, et il y avait des sauvegardes à partir desquelles on avait vraiment vérifié que le site web peut être restauré. Aucune de ces choses ne peut se faire le jour où l’avertissement est déjà publié, et c’est précisément pourquoi cette semaine a été une demi-heure de travail pour certaines équipes, et deux jours pour d’autres.

S’il faut retenir de cette semaine une seule tâche pour que la prochaine fois soit plus facile, c’est une liste : chaque site web, sa version de PHP, la façon dont il est exécuté, son fournisseur d’hébergement, et la personne qui a le droit d’appuyer sur « mettre à jour ». Le prochain avertissement de ce genre arrivera, et la seule question est de savoir combien de temps il faudra alors pour répondre à la question « est-ce que cela nous concerne ».