Quatorze cents heures, et des sites déjà dans le noir
Le rendez-vous était précis, ce qui n'est pas la manière dont les urgences se déclarent d'ordinaire. Le mercredi 21 octobre 2026, à 14:00 UTC, PHP devait publier une mise à jour de sécurité pour deux vulnérabilités critiques. L'heure avait été postée sur la liste d'annonces du langage lui-même, reprise par des chercheurs, notée dans un billet de Dane Knecht, et répétée par des rédactions qui disaient aux administrateurs de se préparer. Huntress, dans une note de réaction rapide, décrivait des failles critiques ayant fuité et leur donnait des numéros : CVE-2026-109618 et CVE-2026-109619. PC Gamer, chroniqueur improbable d'une crise de runtime, disait aux administrateurs web de tenir bon, et de s'attendre à des mises à jour d'urgence qui colmateraient des exploits ayant fuité.
Quand cette heure est arrivée, une partie du web avait déjà choisi l'obscurité. Plusieurs grands sites avaient été mis hors ligne à cause d'une vulnérabilité critique dans PHP. La BBC rapportait des sites retirés dans le monde entier au moment où la mise à jour de cybersécurité était publiée. Ce n'est pas tout à fait la même affirmation que le conseil qui les accompagnait, et la différence mérite d'être gardée. Les autorités américaines, européennes et britanniques recommandaient aux sites de se mettre temporairement hors ligne jusqu'à ce qu'ils puissent être corrigés. Une recommandation n'est pas une panne. Une panne, dans le récit du Brussels Times et dans celui de la BBC, était déjà le fait rapporté du jour : des sites mis hors ligne au milieu de craintes de sécurité, des sites retirés au moment où la mise à jour sortait. Vu de l'extérieur, le tableau était un correctif avec un rendez-vous, et un web qui avait commencé à s'assombrir avant que l'on puisse dire que les paquets étaient arrivés.
Au Japon, cet assombrissement avait des noms. Gigazine rapportait que NicoNico, pixiv et divers autres sites et applications étaient entrés en maintenance afin de suivre le correctif d'urgence. ITmedia enregistrait une maintenance d'urgence chez CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server et つなぐ. Rien, dans ces avis, sur les éléments dont on dispose ici, n'est l'aveu qu'un intrus était déjà à l'intérieur. Ils se lisent comme un jugement : rester joignable, pendant les heures autour du correctif, était devenu l'état le plus risqué. L'équipe de sécurité de PHP avait prévenu les administrateurs la veille de se préparer à des mises à jour d'urgence visant deux vulnérabilités critiques. L'équipe annonçait la découverte de deux failles graves, et les correctifs étaient fixés au 21 octobre. Les mainteneurs les prévoyaient pour des vulnérabilités notées 9,2 sur 10.
Quand les paquets ont été publiés, ils avaient des versions. PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux vulnérabilités critiques qui peuvent permettre une exécution de code à distance sans authentification. Le National Cyber Security Centre et la BBC encadraient la mise à jour dans les termes les plus larges disponibles : un problème critique qui peut permettre à des attaquants d'exécuter des commandes sur n'importe quel serveur web faisant tourner PHP. L'épisode avait déjà un nom, PHP2Shell, et le nom faisait le travail d'un titre. Watchtowr l'employait. Huntress l'employait. Amazon l'employait pour une tentative d'exploitation. Wiz l'employait pour une découverte de recherche dans le cœur du langage.
Le récit public était une publication contrôlée à une heure annoncée. Le récit de la télémétrie était une tentative qui n'avait pas attendu l'annonce.
Amazon Threat Intelligence a identifié une tentative d'exploitation de PHP2Shell dans la télémétrie MadPot datée du 17 octobre 2026, quatre jours avant la divulgation publique de ces deux CVE. Entre la liste d'annonces et cette télémétrie se loge le malaise de la semaine. Les responsables du langage avaient réglé une horloge. Ce n'était pas la seule à tourner.
Deux chemins, et un désaccord sur l'ampleur
Les vulnérabilités, telles que les identifie les archives d'actualités de PHP, ne sont pas un même bogue décrit deux fois. CVE-2026-109618 est une exécution de code à distance via une corruption par manque de mémoire. CVE-2026-109619 est une exécution de code à distance via un état global périmé. L'impact confirmé, selon le compte qui a examiné le problème de manque de mémoire, est une exécution de code à distance sans authentification, sous le compte du worker web. Cette dernière clause fait un travail discret. Ce n'est pas une affirmation sourcée d'une prise de contrôle totale d'une machine. C'est l'affirmation qu'un code s'exécute, sans identifiant, sous le compte que le serveur web utilise déjà pour faire son travail. Pour un très grand nombre de sites, ce compte est le travail.
La faille d'état périmé a une forme que l'on peut énoncer sans la transformer en procédure. PHP contient divers états globaux — erreur, session, objet et extension — qu'un worker conserve, mais qui pointent vers une mémoire appartenant à une seule requête. Un worker, dans cet agencement, survit à la requête qui l'a rempli. La mémoire, non. Ce que la vulnérabilité fait de ce décalage est, dans les termes de l'archive, une exécution de code à distance. L'autre faille atteint une destination semblable par le chemin nommé corruption par manque de mémoire. Deux mécanismes, une même classe de résultat, et une seule publication d'urgence construite pour fermer les deux.
Le risque, disait l'archive, est le plus élevé pour mod_php, avec un exploit démontré dans lequel une requête non authentifiée peut déclencher l'attaque avant que le moindre code applicatif ne s'exécute. C'est la phrase qu'un exploitant lit deux fois. Une faille qui attend un recoin particulier d'une application peut être triée. Une faille atteignable par une requête non authentifiée, avant que l'application ait eu la chance d'être prudente, est une autre file d'attente. C'est pourquoi une note de gravité de 9,2 sur 10, qu'Ars Technica rapportait comme la notation des deux vulnérabilités que les mainteneurs s'apprêtaient à corriger, ne figure pas sur la page comme un ornement. C'est pourquoi le message de l'équipe de sécurité était de se préparer à des mises à jour d'urgence pour le lendemain, et non de trouver une fenêtre commode.
Il y a une vraie différence dans la distance à laquelle les sources poussent le rayon de l'explosion, et elle doit être nommée plutôt que lissée.
D'un côté, la BBC et le National Cyber Security Centre présentaient la mise à jour comme visant un problème critique qui peut permettre à des attaquants d'exécuter des commandes sur n'importe quel serveur web faisant tourner PHP. « N'importe quel » est un grand mot. C'est le mot qui transforme un bogue de runtime en quelque chose de plus proche d'une contingence civile. De l'autre, l'archive du langage était plus précise sur l'endroit où le danger démontré se situait : le plus élevé pour mod_php, et atteignable, dans ce cas démontré, avant que le code applicatif ne s'exécute. Ce ne sont pas de polis synonymes. Un lecteur peut tenir les deux — un large avertissement officiel sur les serveurs faisant tourner PHP, et un énoncé technique plus étroit sur l'endroit où le risque a été montré comme le plus élevé — sans prétendre qu'ils disent la même chose. L'impact confirmé demeure une exécution de code à distance sans authentification, sous le compte du worker web. Jusqu'où cette confirmation voyage, au-delà de la configuration dans laquelle elle a été démontrée, est l'argument que les avis du jour n'ont pas pris le temps de trancher. Ils ont corrigé, et ils ont dit aux gens d'envisager de se mettre hors ligne pendant qu'ils le faisaient.
La question des versions a un bord inachevé du même genre. On croit que les vulnérabilités affectent PHP 5, 6, 7 et 8 — on le croit, sans confirmation cérémonielle ligne à ligne, et cette croyance est portée par Watchtowr, BleepingComputer, la note de publication de sécurité de PHP elle-même, et Huntress. Les versions nommées comme corrigeant les deux failles critiques sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Les sources rassemblées ici ne dressent pas une carte complète de ce qui, le 21 octobre, était disponible pour chaque ligne plus ancienne que les chercheurs croient affectée. Ce qu'elles dressent, c'est un trou dans la paperasse : une croyance sur la portée qui remonte à travers 5, 6 et 7, et une liste de correctifs qui, dans l'archive et dans la note d'expédition, est une liste de versions ponctuelles 8.x. Pour un administrateur sur un 8.2, 8.3, 8.4 ou 8.5 courant, l'instruction était concrète. Pour quiconque est encore plus en arrière, le dossier public de cet épisode est un avertissement sans, dans ces sources, un numéro de version correspondant.
Wiz Research a mis au jour plusieurs vulnérabilités critiques dans le cœur de PHP, et a chiffré l'exposition à 70 pour cent de tous les sites web du monde. L'Australian Financial Review, rapportant que l'intelligence artificielle avait mis au jour des bogues critiques dans le langage utilisé par la plupart des serveurs web, employait la même proportion : 70 pour cent des sites web du monde en danger. Ce récit n'a pas de recensement indépendant. Le chiffre appartient à ces deux récits, et c'est le chiffre à l'aune duquel le comportement du jour devient intelligible. Si même une fraction sérieuse de cette part était juste, un chemin non authentifié vers l'exécution de code sur le worker ne serait pas une histoire de spécialistes. Ce serait une raison pour un ministère de passer une matinée au téléphone, ce que décrit le reportage australien.
Une faille de 2024, un accord de 2026
L'urgence a une préhistoire, et c'est la partie la moins flatteuse du dossier.
La PHP Foundation a trouvé une faille critique en 2024 mais n'a pas pu s'accorder sur un correctif avant 2026. Le récit de The Next Web est précis sur l'étroitesse de cette phrase : PHP savait pour l'une des failles en 2024, et l'obstacle n'était pas l'ignorance. C'était l'accord. Les sources ne disent pas lequel des deux CVE d'octobre était cette découverte, ni qui plaidait pour quel remède, ni ce qu'un correctif rejeté aurait coûté. Elles disent qu'une faille critique a été trouvée, qu'un correctif n'a pas pu être convenu, et que l'accord a attendu 2026.
Deux ans, c'est long pour laisser une faille critique dans un langage que Wiz et l'Australian Financial Review associent tous deux à environ sept sites web sur dix. C'est plus long encore quand la publication finale n'est pas une version ponctuelle programmée avec quinze jours d'avis, mais un correctif d'urgence, annoncé pour un mercredi après-midi en UTC, les administrateurs ayant été prévenus la veille d'être prêts. La distance entre « nous l'avons trouvé » et « nous nous sommes accordés sur la manière de le fermer » est, dans le logiciel ordinaire, une dispute d'atelier. Dans un runtime aussi largement embarqué, selon ces récits, la même distance est une fenêtre d'exposition publique. Le dossier d'octobre ne prouve pas ce qui a traversé cette fenêtre. Il montre que la fenêtre était réelle, et qu'au milieu du mois elle n'était plus seulement une affaire de gouvernance.
Il est tentant de traiter l'échec de l'accord comme une morale. Le matériau ne soutient pas la morale dans le détail. Il soutient une chronologie. Une faille critique, connue de la Foundation en 2024. Pas de correctif convenu avant 2026. Puis, en quelques jours d'octobre, un faisceau de choses qui arrivent d'ordinaire en séquence sont arrivées presque les unes sur les autres : une divulgation de recherche associée à Wiz, et à un reportage qui créditait l'intelligence artificielle ; un avertissement de l'équipe de sécurité ; une heure publiée ; des correctifs pour quatre lignes de versions courantes ; et, déjà dans la télémétrie d'un fournisseur de cloud, une tentative d'exploitation datée du 17 octobre, avant la divulgation publique des deux numéros de CVE.
La fuite, si c'est le mot, est elle-même un cadrage sourcé plutôt qu'un mécanisme tranché. Huntress titrait sur des vulnérabilités critiques ayant fuité. PC Gamer écrivait d'exploits ayant fuité, et d'administrateurs se préparant aux mises à jour qui les colmateraient. L'annonce officielle était celle d'une prochaine publication de sécurité critique, calée au 21 octobre à 14:00 UTC. Rien, dans ces sources, ne décrit comment une fuite aurait eu lieu, qui détenait les détails, ni si la tentative du 17 octobre utilisait la même information que chercheurs et titulaires appelleraient plus tard une fuite. Ce que les sources permettent, c'est une affirmation plus dure, et plus petite. La tentative précède la divulgation publique. La divulgation publique a été gérée comme une urgence avec une horloge. Et au moins l'une des failles sous-jacentes était dans la connaissance de la Foundation, non résolue par un accord, depuis 2024.
Ils n'ont pas échoué à la voir. Sur l'une des failles, ils ont échoué à s'accorder sur un correctif — de 2024 à 2026.
Cette distinction change le genre de réassurance qu'un correctif peut offrir. Un bogue trouvé le lundi et corrigé le mercredi, c'est un processus qui travaille vite. Un bogue trouvé en 2024 et livré, dans des conditions d'urgence, en octobre 2026, c'est un processus qui a fini par fonctionner, après un délai que, selon le récit de The Next Web, le consensus n'a pas pu clore. Les correctifs du 21 octobre n'effacent pas le délai. Ils y mettent fin.
Il vaut la peine de remarquer quel genre de publication cela est devenu, une fois l'accord enfin arrivé. Pas un commit discret. Une mise à jour de sécurité avec une heure publiée, annoncée sur la liste d'annonces, assez grave pour que l'équipe de sécurité passe la veille à dire aux administrateurs de se préparer, et assez grave pour que les notes attachées aux deux failles soient à 9,2 sur 10. La note de PHP, le jour même, porte dans son titre une promesse de dire comment le projet renforce sa sécurité. Le contenu d'une réforme plus longue est hors de ces sources. Le fait de l'urgence ne l'est pas. Ce qui est visible, dans le matériau réellement en main, c'est une décision de livrer, à une heure nommée, des correctifs pour deux failles que le projet n'était plus disposé à laisser jusqu'à une publication commode.
Le jour où le web ordinaire s'est éteint lui-même
Les pannes se racontent d'ordinaire de l'extérieur : un site tombe, un utilisateur s'en aperçoit, une page de statut rattrape. Celle-ci a été racontée, en plusieurs endroits, comme un choix.
Le Brussels Times rapportait de grands sites se mettant hors ligne alors que la vulnérabilité déclenchait des craintes de sécurité, et l'affirmation en dessous est directe. Plusieurs grands sites ont été mis hors ligne à cause d'une vulnérabilité critique dans le langage. L'échelle de la BBC était plus large encore : des sites retirés dans le monde entier au moment où la mise à jour de cybersécurité était publiée. Aucun des deux récits ne détaille la méthode — ce qui a été arrêté, par qui, pour combien de temps — et ce serait une fiction que de fournir les opérations manquantes. Ils fixent la cause au problème PHP. Ils fixent la réponse, dans le reportage de plus d'un pays, comme une absence plutôt que comme un correctif appliqué en silence.
Le conseil officiel donnait à ce choix un parrain. Les autorités américaines, européennes et britanniques recommandaient aux sites de se mettre temporairement hors ligne jusqu'à ce qu'ils puissent être corrigés. Il est difficile de surestimer à quel point cette phrase est rarement la phrase responsable. Mettre un site à terre est, en temps ordinaire, le résultat qu'un attaquant veut et qu'un exploitant redoute. Ici, trois ensembles d'autorités ont traité l'absence temporaire comme l'état le plus sûr, aussi longtemps que le correctif n'était pas encore appliqué. L'avis du National Cyber Security Centre sur un problème de sécurité critique affectant PHP se tient dans le même temps, même là où ce dossier ne cite pas le Centre comme ayant émis la recommandation de mise hors ligne en ces termes. Ce pour quoi le Centre est cité, aux côtés de la BBC, c'est la substance : un problème critique qui peut permettre à des attaquants d'exécuter des commandes sur n'importe quel serveur web faisant tourner PHP, et une mise à jour de sécurité publiée pour y répondre.
La version australienne de la matinée était une course au correctif. L'Australian Financial Review rapportait que l'intelligence artificielle avait mis au jour des bogues critiques dans le langage de programmation utilisé par la plupart des serveurs web, et que des agences gouvernementales se précipitaient pour corriger des vulnérabilités dans des sites. Ce détail sort l'histoire du théâtre habituel des pannes grand public. Des services nommés passant en maintenance, c'est une sorte de dommage : un public qui ne peut plus atteindre quelque chose qu'il utilise sans y penser. Une agence gouvernementale qui corrige dans l'urgence en est une autre. Le même langage, embarqué dans des sites qui ne sont pas optionnels de la même manière. Le cadre de l'AFR était le chiffre de 70 pour cent, et la découverte. Le cadre opérationnel était plus simple. Le bogue était dans le langage. Le langage était dans les sites. Les sites devaient bouger.
Le Japon fournit la liste la plus concrète, et donc le correctif le plus utile à l'abstraction. Il est facile de dire « le web » et de vouloir dire un schéma. Il est plus difficile d'écarter un avis de maintenance qui nomme CoDMon, Shadowverse: Worlds Beyond, Sakura's rental server, BASE, pictSQUARE, 킴블, X Server et つなぐ. Ajoutez NicoNico et pixiv, comme l'a fait Gigazine, et la liste cesse d'être une métaphore. L'hébergement est le multiplicateur caché dans ces noms. Une vulnérabilité dans une seule application est une vulnérabilité dans cette application. Une vulnérabilité dans le langage, sur un serveur de location ou sur X Server, est une file de clients qui n'ont pas choisi le bogue et ne peuvent pas, en aucun sens sérieux, corriger autour par eux-mêmes. Ces sources ne comptent pas ces clients. Elles montrent les hébergeurs traitant le correctif comme assez urgent pour faire entrer le service en maintenance d'urgence.
L'équipe de sécurité avait demandé de se préparer, et le calendrier montre la forme de ce qui était demandé. L'avertissement était de se préparer à des mises à jour d'urgence pour le lendemain. La publication était fixée à 14:00 UTC le 21. Les correctifs, une fois livrés, étaient les quatre versions ponctuelles déjà nommées. Ce qui a rempli les heures autour de ce rendez-vous n'était pas, sur ce dossier, un black-out unique et coordonné. C'était un patchwork : certains sites mis hors ligne au milieu de craintes de sécurité, certains retirés au moment où la mise à jour sortait, certains placés en maintenance nommée, certains sur lesquels des agences gouvernementales australiennes se précipitaient, leur problème étant le correctif lui-même. L'élément commun est le langage, et le jugement selon lequel attendre une soirée commode n'était plus le choix conservateur.
La gravité aide à expliquer le jugement sans l'expliquer pour le dissoudre. Deux vulnérabilités, chacune portant une note de 9,2 sur 10, ce n'est pas un couplet qui invite un déploiement par étapes sur un week-end calme. Une atteinte sans authentification, dans le cas démontré de mod_php, avant que le code applicatif ne s'exécute, ce n'est pas un couplet qui invite la confiance dans les contrôles qu'une application pourrait ensuite effectuer. Placez cela à côté d'un avertissement selon lequel le problème peut permettre l'exécution de commandes sur n'importe quel serveur web faisant tourner PHP, et le conseil de se mettre hors ligne jusqu'à correction cesse de ressembler à du théâtre. Il ressemble à l'option résiduelle, une fois compris que la faille siège dans le runtime plutôt que dans un recoin qu'un exploitant peut simplement éteindre.
Rien de tout cela n'exigeait que les vulnérabilités soient nouvelles pour tout le monde. Cela exigeait qu'elles soient nouvellement indéniables. La connaissance de 2024 de la Foundation, et son incapacité à s'accorder sur un correctif avant 2026, appartient à la même respiration que les avis de maintenance. Les sites qui se sont éteints le 21 octobre vivaient à l'intérieur d'un délai sur lequel ils n'avaient pas voté. C'est le fait politique à l'intérieur d'un fait d'ingénierie de publication. Un langage utilisé, selon le récit de Wiz et de l'AFR, par quelque chose comme 70 pour cent des sites web du monde n'est pas une base de code privée, même quand sa gouvernance est une dispute privée. Le coût d'un correctif non convenu est payé par des gens qui n'assistent pas à la réunion.
Qui savait, et qui essayait déjà
Il y a deux premières dans cette histoire, et elles répondent à des questions différentes.
Wiz Research a mis au jour plusieurs vulnérabilités critiques dans le cœur de PHP. Le récit de l'entreprise, et celui de l'Australian Financial Review, placent tous deux l'intelligence artificielle dans la découverte. Wiz cadrait la trouvaille comme une IA mettant au jour des vulnérabilités critiques d'exécution de code à distance affectant 70 pour cent de l'internet. L'AFR rapportait que l'IA avait découvert un bogue mettant 70 pour cent des sites web du monde en danger, et que des agences gouvernementales australiennes se précipitaient. Comment un modèle a été utilisé, ce qu'on lui a montré, ce qu'un chercheur humain avait encore à prouver : rien de cela n'est dans le matériau ici, et ce serait une fiction que de le fournir. Ce qui est dans le matériau, c'est l'attribution. Un effort de recherche associé à Wiz, et décrit en plus d'un endroit comme le travail de l'IA, a fait surface de plusieurs failles critiques dans le cœur du langage. Selon ce récit, ce n'était pas une mauvaise configuration dans une extension populaire. C'était PHP lui-même.
L'autre première n'est pas une découverte. C'est une tentative. Amazon Threat Intelligence a identifié une tentative d'exploitation de PHP2Shell datée du 17 octobre 2026, dans la télémétrie MadPot, quatre jours avant la divulgation publique de CVE-2026-109618 et CVE-2026-109619. Une tentative n'est pas un recensement de compromissions. Ces sources ne disent pas combien de serveurs ont répondu, ce qui a été pris, ni si la tentative a réussi de manière durable. Elles disent qu'elle a été identifiée, qu'elle était datée du 17, et que la divulgation publique des deux CVE est venue quatre jours plus tard. Dans une semaine de grandes affirmations — n'importe quel serveur web, 70 pour cent des sites, retraits dans le monde entier — la phrase d'Amazon est presque austère, et c'est celle qui change le plus la température. Quelqu'un n'attendait pas la FAQ.
À plat, la séquence est celle-ci. Une faille critique connue de la Foundation depuis 2024, sans correctif convenu. Une tentative d'exploitation le 17 octobre 2026, vue dans la télémétrie MadPot d'Amazon. Un avertissement de l'équipe de sécurité de PHP pour se préparer à des mises à jour d'urgence le lendemain. Une publication annoncée à 14:00 UTC le 21 octobre, portée sur php.announce et corroborée par Huntress, par le récit de PC Gamer sur des administrateurs se préparant, et par le billet de Dane Knecht. Des correctifs livrés le même jour, sous les noms 8.5.12, 8.4.27, 8.3.36 et 8.2.35, fermant deux vulnérabilités critiques qui permettent une exécution de code à distance sans authentification. Autour de cette livraison : des sites hors ligne, des sites en maintenance, des agences qui se précipitent, des autorités recommandant l'obscurité comme contrôle temporaire.
Ce que cette chronologie ne soutient pas, c'est un seul complot allant d'un désaccord de 2024 à une sonde du 17 octobre. Rien ici ne relie l'échec non publié de la Foundation à s'accorder à la tentative MadPot, ni cette tentative à la divulgation de recherche, ni la divulgation de recherche à un exploitant nommé. L'image honnête est celle de plusieurs horloges, pas d'une conspiration. Une horloge de gouvernance qui a tourné deux ans. Une horloge de recherche qui s'est terminée par une mise au jour publique attribuée à Wiz et à l'IA. Une horloge défensive réglée, très délibérément, sur 14:00 UTC un mercredi. Et une horloge offensive qui, selon le récit d'Amazon, avait déjà sonné le 17.
Le cadrage de l'exploit ayant fuité se pose maladroitement à cheval sur ces horloges, et la maladresse doit rester visible. Si Huntress et PC Gamer ont raison de dire que les vulnérabilités, ou les exploits, avaient fuité, alors la publication d'urgence est en partie une réponse à une perte de contrôle sur l'information, et pas seulement une réponse à un bogue. Si l'on lit la liste d'annonces seule, la publication est une mise à jour de sécurité critique planifiée, avec une heure de départ. Les deux peuvent être vrais : un plan, et un plan conduit là où d'autres décrivaient déjà une fuite. Les sources ne tranchent pas. Elles montrent un projet choisissant une heure publique, des chercheurs décrivant des failles ayant fuité, et les capteurs d'un fournisseur de cloud enregistrant une tentative avant que les numéros de CVE ne soient publics. Cela suffit à rejeter la version rassurante, dans laquelle la première chose qu'aurait entendue quiconque de l'extérieur aurait été un avis poli et un jeu de paquets.
Cela suffit aussi à être prudent sur le succès. « Tentative d'exploitation » est la formule que soutient le récit d'Amazon. « Peut permettre » est la formule attachée à l'exécution de commandes sur n'importe quel serveur web faisant tourner PHP. « Démontré » est le mot que l'archive de PHP emploie pour le chemin mod_php, où une requête non authentifiée peut déclencher l'attaque avant que le code applicatif ne s'exécute. « Impact confirmé » est une exécution de code à distance sans authentification, sous le compte du worker web. Empilées sans soin, ces phrases deviennent un sentiment de compromission générale déjà accomplie. Lues comme elles sont écrites, elles sont plus précises, et la précision est l'information. Il y a un chemin démontré. Il y a une classe d'impact confirmée. Il y a une tentative enregistrée avant la divulgation. Il y a un avertissement assez large pour couvrir n'importe quel serveur faisant tourner le langage. Il n'y a pas, dans ce matériau, un décompte publié d'intrusions.
Ce que quatre numéros de version peuvent fermer
Les paquets sont la partie de l'histoire qui a des numéros de version, et les numéros de version sont une merci. PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigent deux vulnérabilités critiques qui peuvent permettre une exécution de code à distance sans authentification. Quatre branches, quatre versions ponctuelles, un après-midi. Pour les exploitants de ces branches, l'urgence avait une fin que l'on pouvait télécharger. La mise à jour de sécurité n'était pas seulement promise à 14:00 UTC. Elle a été publiée, pour répondre à un problème critique qui peut permettre à des attaquants d'exécuter des commandes sur n'importe quel serveur web faisant tourner PHP. C'est la phrase que le National Cyber Security Centre et la BBC laissent dans le dossier, et c'est la phrase contre laquelle les fenêtres de maintenance ont été ouvertes, et contre laquelle elles peuvent se fermer.
Ce que les paquets ne ferment pas automatiquement, c'est l'argument sur le périmètre.
Ils ne répondent pas, à la face de ces sources, à l'administrateur dont le PHP est en 7, ou en 5, ou en 6, qui siègent tous dans l'ensemble des versions que l'on croit affectées. Une croyance n'est pas un correctif. La croyance est bien attestée — quatre sources, dont l'écriture de publication de sécurité du projet lui-même et une FAQ spécialisée de Watchtowr. Les correctifs qui sont nommés ne forment pas un jeu correspondant. Prétendre le contraire, pour le plaisir d'une fin nette, serait inventer un rétroportage que ces ensembles ne contiennent pas. L'énoncé net est l'énoncé désordonné. Les 8.2, 8.3, 8.4 et 8.5 courants ont des correctifs nommés. Les lignes plus anciennes sont, dans le jugement de ces quatre sources, à l'intérieur du rayon d'explosion cru, et ce dossier s'arrête là.
Les paquets ne dissolvent pas non plus la différence entre « n'importe quel serveur web faisant tourner PHP » et « le plus élevé pour mod_php ». Un exploitant dont l'installation n'est pas celle que l'archive a marquée comme le risque le plus élevé peut lire l'avertissement officiel et la note technique et ne pas savoir lequel gouverne la nuit. Le cas démontré de l'archive est celui dans lequel une requête non authentifiée déclenche l'attaque avant que le moindre code applicatif ne s'exécute, et il attache cette démonstration à mod_php comme risque le plus élevé. L'avertissement plus large n'attend pas la distinction. Les autorités des États-Unis, d'Europe et de Grande-Bretagne ont recommandé un statut hors ligne temporaire jusqu'à ce que les sites puissent être corrigés, et cette recommandation ne se lit pas comme limitée à un seul module de serveur. S'il y a une dispute dans cet épisode, ce n'est pas une querelle criée entre éditeurs. C'est ceci : une description institutionnelle large de qui est exposé, et une description technique plus étroite de l'endroit où le danger a été montré à son plus haut, publiées dans la même semaine, à propos des mêmes deux CVE. Les deux sont dans le dossier. Aucune n'annule l'autre.
L'énoncé d'impact a sa propre frontière, et la frontière vaut d'être gardée. L'impact confirmé est une exécution de code à distance sans authentification, sous le compte du worker web. C'est grave, et c'est précis. L'exécution de commandes, dans la formulation de la BBC et du NCSC, est le pouvoir dont on avertit. Le compte nommé dans la confirmation d'impact est celui du worker. Un lecteur attentif n'échange pas l'un contre l'autre en majorant. L'exécution de code sous le worker suffit, selon l'affirmation sourcée, à importer énormément : ce sont les mains du site lui-même. Ce n'est pas, sur ces éléments, une affirmation sourcée d'un contrôle automatique au-delà de ce compte. La peur du jour était calibrée sur l'affirmation que les sources font réellement, et cette affirmation suffisait déjà à vider des pages d'accueil et à justifier, dans le jugement de trois ensembles d'autorités, une disparition temporaire.
Il y a une frontière supplémentaire autour du mot « tentative ». Amazon a vu une tentative d'exploitation de PHP2Shell le 17 octobre, avant la divulgation. Les correctifs du 21 ne peuvent pas l'effacer. Ils peuvent fermer les bogues dont une telle tentative aurait eu besoin, sur les versions qu'ils couvrent, pour les exploitants qui les appliquent. Ils ne peuvent pas dire combien de tentatives de ce genre n'ont jamais été vues, ni combien ont réussi dans des endroits sans télémétrie du genre de MadPot. L'absence d'une liste de victimes dans ces sources n'est pas la preuve d'une semaine calme. C'est la preuve que ce dossier porte sur la faille, le correctif, le conseil, et une tentative identifiée — pas sur un comptage achevé du dommage.
Et il y a la frontière autour de 2024. Les correctifs conviennent d'un correctif. Ils n'expliquent pas le désaccord qui en a retardé un. La trouvaille de The Next Web demeure comme le grésillement sous les notes de publication : l'une des failles était connue en 2024 ; un correctif n'a pas pu être convenu avant 2026 ; l'accord, quand il est venu, est venu comme une urgence, annoncée la veille et notée 9,2 sur 10. Quiconque veut une histoire de sprint de la découverte au correctif devra faire partir l'horloge en octobre. Quiconque la fait partir là où The Next Web la fait partir verra une dispute de deux ans, puis un mercredi.
PHP2Shell est un assez bon nom pour une semaine. C'est un mauvais nom pour la condition que la semaine a exposée. La condition est qu'une faille dans ce langage peut être connue, et non convenue, puis soudain celle de tout le monde ; que le correctif, quand il vient, peut être réel et ne pas couvrir encore, dans les sources que nous avons, chaque version que les chercheurs croient dans le périmètre ; que l'avertissement officiel et la note technique peuvent tous deux être prudents et ne pas dire la même chose. L'instruction sensée, pour une journée, n'était pas d'être plus malin que le bogue. C'était d'être hors ligne jusqu'à ce que les paquets portant ces quatre numéros ne soient plus une promesse pour 14:00 UTC, mais un fichier réellement livré.
Le web, dans les récits de ce mercredi, n'est pas tombé tout seul. Des parties en ont été mises en sommeil exprès, par des exploitants et des hébergeurs qui avaient lu l'avertissement et préféraient une page de maintenance à un worker exécutant les commandes de quelqu'un d'autre. Ce n'est pas une petite histoire de version ponctuelle. C'est l'histoire de la part de vie ordinaire qui siège désormais dans un processus PHP — une part que Wiz et l'Australian Financial Review placent tous deux près de 70 pour cent des sites web du monde — et du peu de marge que cela laisse quand un worker ne peut plus être cru capable d'empêcher la mémoire d'une requête de s'attarder comme l'état de la suivante. Le correctif, sur les lignes qu'il couvre, ce sont quatre numéros de version et un après-midi. Le délai qui a fait de l'après-midi une urgence a duré deux ans.