Face à PHP2Shell, un gouvernement du G7 a demandé à Red Sift chaque hôte exposé de son parc national, et a reçu la liste avec chaque hôte rattaché au ministère qui en est propriétaire.
Deux failles critiques de PHP concernent toutes les versions depuis PHP 5. Partout, les gouvernements se posaient la même question : où utilisons-nous PHP ? La plupart ont choisi de tout débrancher. L'un d'eux nous a sollicités, et a obtenu sa réponse pour l'ensemble de son parc national avant la publication des correctifs.
Ce sont les meilleures données que nous ayons vues.
L'équipe PHP annonce un correctif d'urgence avec un jour de préavis. Les identifiants CVE sont en ligne le soir même, et le CERT-EU publie un avis avant même qu'un correctif existe. Les honeypots d'Amazon avaient déjà enregistré une sonde visant ces failles trois jours plus tôt.
Pour quiconque exploite une infrastructure gouvernementale, le problème est immédiat. Toutes les versions depuis PHP 5 peuvent être concernées. Filtrer par version ne sert à rien. Le seul point de départ sûr est une liste complète de chaque hôte exposé sur Internet qui exécute PHP, quelle que soit sa version, où qu'il se trouve dans le parc.
Pas un échantillon, pas un seul ministère. Chaque ministère et chaque agence dont le gouvernement a la responsabilité, jusqu'au nom de chaque hôte. Constituer cette liste à la main, c'est courir après des registres d'actifs, des comptes cloud, des fournisseurs et des équipements qui intègrent PHP sans le dire. Des semaines de travail, alors que la fenêtre de correction s'ouvre le lendemain après-midi.
Red Sift Hardenize, notre solution de gestion de la surface d'attaque (ASM), découvre et surveille en continu les serveurs exposés sur Internet et enregistre les logiciels exécutés par chacun d'eux. L'inventaire dont le gouvernement avait besoin existait déjà. Nous l'avons interrogé, avons rattaché chaque hôte PHP au ministère qui en est propriétaire et avons livré la liste couvrant tout le parc dans une vue unique, avant la publication des versions corrigées le 21 octobre à 13 h 30 UTC.
Le même scan a été exécuté pour tous les clients ASM. Chaque client directement concerné a reçu ses propres noms d'hôtes, l'heure de publication et les avis officiels avant le correctif.
D'autres fournisseurs nous disent qu'il est impossible d'obtenir le niveau de données que Red Sift peut fournir.
Le correctif prend quelques minutes. Trouver chaque hôte qui en a besoin peut prendre des semaines. Les gouvernements les plus rapides avaient déjà la liste.
Un gouvernement a posé la question. Chaque client Red Sift ASM concerné a reçu la même chose : une liste nominative de ses hôtes PHP, avant la sortie du correctif le 21 octobre. Nous avons ensuite mesuré ce qu'ils en ont fait, chaque jour pendant cinq jours.
PHP CVE-2026-109618 / 109619 · 21–26 oct. 2026
10 114
serveurs clients vulnérables connus en moins en cinq jours.
En baisse de 62 %, de 16 203 à 6 089. Le nombre d'organisations clientes ayant un serveur vulnérable connu est passé de 443 à 254.
Chaque client concerné disposait de sa liste nominative d'hôtes avant la sortie du correctif.
redsift.comSource : scans quotidiens par Red Sift des serveurs clients exposés sur Internet ; variation nette entre le 21 et le 26 oct. 2026.
Au 26 octobre, 4 909 des 6 089 serveurs clients encore exposés exécutaient PHP 8.1 ou une version antérieure. Il n'existe aucune version officielle de PHP à installer pour ces branches : il faut donc un rétroportage du fournisseur ou une mise à niveau. C'est là que se situe désormais le travail, et il commence par la même question qu'au premier jour : lesquels de vos serveurs sont concernés ?
Pourriez-vous produire cette vue pour vos propres serveurs dès aujourd'hui ? Si la réponse n'est pas évidente, nous vous enverrons un bilan externe ponctuel de votre domaine.
Périmètre : hôtes exposés sur Internet sur lesquels PHP a été détecté, dans les instances clientes de Red Sift ASM (Hardenize), comparés chaque jour du 21 au 26 octobre 2026. Les instances de démonstration, de bac à sable et de recherche sont exclues. Les organisations correspondent aux instances clientes.
Corrigé signifie que l'hôte indique la version 8.5.12, 8.4.27, 8.3.36, 8.2.35 ou une version ultérieure de la même branche ; un hôte qui indique plusieurs versions n'est compté que si toutes sont corrigées. Vulnérable connu signifie qu'il indique une version non corrigée, quelle que soit la branche. Les hôtes en 8.1 ou antérieure peuvent déjà disposer d'un rétroportage invisible depuis l'extérieur.
Les variations sont nettes : un serveur sort du décompte lorsqu'il est corrigé, mis à niveau, décommissionné ou qu'il cesse d'indiquer sa version. Environ 9 185 hôtes clients n'exposaient aucune version le 26 octobre et ne sont comptés dans aucun sens. Toutes les versions depuis PHP 5 sont concernées : considérez-les donc comme potentiellement exposés.
Notre solution de gestion de la surface d'attaque (ASM) découvre et surveille en continu vos serveurs exposés sur Internet et enregistre les logiciels exécutés par chacun d'eux. Quand une faille comme celle-ci survient, la première question passe de « par où commencer ? » à « voici la liste ».
Avant que l'équipe PHP ne publie les correctifs, nous avons scanné chaque hôte que nous surveillons dans l'ensemble de notre base clients ASM pour repérer ceux qui exécutent PHP.
Nous avons rattaché chaque hôte concerné au client, au ministère ou à l'agence qui en est responsable, afin que chaque notification soit propre à un seul parc.
Chaque client directement concerné a reçu les noms des hôtes potentiellement exposés, l'heure de publication et les liens vers les avis officiels, avant la publication des versions corrigées.
Notification client · 21 octobre 2026 · avant la mise à jour de sécurité PHP
Heure de publication annoncée : 21 oct., 14 h 00 UTC. Versions corrigées : 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Corrigez d'abord les hôtes exposés sur Internet et redémarrez tous les workers.
Les noms d'hôtes sont des exemples. Les vraies notifications contiennent les hôtes du client.
Le scan externe voit ce qu'un hôte laisse paraître et couvre les actifs de votre compte. Les systèmes internes, les hôtes hors de votre périmètre surveillé et les produits qui masquent leur environnement d'exécution PHP doivent toujours être vérifiés par vos soins.
Si vous êtes client Red Sift ASM et n'avez reçu aucune notification, c'est que nous n'avons pas trouvé PHP sur les hôtes que nous surveillons pour vous. Nous vous conseillons néanmoins d'effectuer des vérifications sommaires de votre côté.
La valeur réside dans la précision : des hôtes nommés, dans votre parc, avant l'ouverture de la fenêtre de correction.
Quel que soit votre point de départ, la première étape est la même : connaître chaque hôte exposé sur Internet que vous possédez et ce qu'il exécute. Voici comment nous pouvons vous aider, selon votre situation.
Vous avez reçu nos informations préliminaires : les hôtes que nous surveillons pour vous et qui exécutent PHP, avec le calendrier de publication et les avis. Nous sommes prêts à aller plus loin avec vous sur l'ensemble de votre parc, y compris le périmètre que vous n'avez pas encore ajouté, et à vous aider à prioriser la longue traîne des hôtes qui ne peuvent pas être corrigés rapidement.
Si vous êtes un gouvernement national ou un organisme du secteur public et que vous n'utilisez pas encore notre solution de gestion de la surface d'attaque, parlez-nous. Nous produisons déjà des listes d'exposition couvrant des parcs entiers à l'échelle nationale, jusqu'au nom de chaque hôte, et ces données sont comparées à ce que d'autres fournisseurs peuvent offrir.
PHP fait tourner l'essentiel du Web, il est intégré à des produits que vous n'avez pas conçus, et l'attaque survient avant même que votre application ne la voie. Si vous ne pouvez pas dire aujourd'hui combien d'hôtes PHP exposés sur Internet vous avez, c'est le premier problème à résoudre, et nous pouvons vous y aider dès cette semaine.
Tirées de l'avis de sécurité PHP, de l'alerte du NCSC britannique et de notre propre article technique.
Commencez par les hôtes exposés sur Internet. Ne filtrez pas par version. Incluez les conteneurs, les images de base et tout ce qui est compilé à partir des sources.
8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou le paquet corrigé de votre distribution. Pour la 8.1 et les versions antérieures, utilisez un rétroportage du fournisseur ou effectuez une mise à niveau.
Un binaire corrigé n'a aucun effet sur les pools FPM ni sur les processus enfants Apache qui exécutent encore l'ancien code.
Définissez memory_limit=-1 en configuration administrateur, réduisez post_max_size, définissez session.upload_progress.enabled=0 et, en 8.5, fatal_error_backtraces=0. Redémarrez à nouveau les workers. Ces réglages bloquent les vecteurs d'attaque confirmés et doivent être considérés comme une solution transitoire en attendant le correctif.
Le CERT-EU et le NCSC conseillent tous deux de mettre hors ligne une application exposée sur Internet jusqu'à sa correction.
Recherchez des signes de compromission sur tout ce que vous n'avez pas pu mettre à jour rapidement, et consultez les avis des fournisseurs pour les produits qui intègrent PHP.
PHP2Shell est le nom donné à CVE-2026-109618 et CVE-2026-109619, deux failles d'exécution de code à distance sans authentification dans le moteur PHP lui-même. Elles se situent dans le code exécuté lorsqu'un worker manque de mémoire ou rencontre une erreur fatale : elles ne dépendent donc pas de l'application qui tourne au-dessus. WordPress, Drupal, Laravel, les applications sur mesure et les consoles d'équipements sont tous concernés.
Toute installation PHP qui traite des requêtes web peut être concernée, qu'il s'agisse de PHP-FPM, d'Apache mod_php, de php-cgi, de FrankenPHP ou de LiteSpeed. mod_php présente le risque le plus élevé, car l'exploit démontré se déclenche pendant l'analyse de la requête, avant qu'une règle de pare-feu applicatif web liée aux routes de l'application ne puisse le voir.
Des correctifs compilés existent pour quatre branches. Les branches plus anciennes n'ont reçu que des rétroportages sous forme de code source, voire rien du tout. Un troisième problème lié, CVE-2026-115560, a été divulgué le 23 octobre et est couvert par la mesure d'atténuation existante.
| Branche | Corrigé dans | Statut |
|---|---|---|
| 8.5 | 8.5.12 | Prise en charge |
| 8.4 | 8.4.27 | Prise en charge |
| 8.3 | 8.3.36 | Correctifs de sécurité uniquement |
| 8.2 | 8.2.35 | Fin de vie le 31 déc. 2026 |
| 8.1 · 8.0 · 7.4 | Rétroportages source uniquement | Aucune version compilée. Rétroportage du fournisseur ou mise à niveau. |
| 7.3 et antérieures | Aucun | Inclut PHP 5. Mise à niveau requise. |
Versions corrigées publiées le 21 octobre 2026 à 13 h 30 UTC. Source : php.net et avis de sécurité GitHub.
Équipements et consoles l'intègrent. Palo Alto Networks, Fortinet et Cisco évaluaient tous leurs produits en quelques heures.
Toutes les versions depuis PHP 5 peuvent être concernées. Première consigne du NCSC : identifier tous les systèmes qui exécutent PHP, quelle que soit la version.
Environ 42 % des hôtes PHP exposés sur Internet utilisent des branches en fin de vie sans correctif compilé (VulnCheck).
Un binaire corrigé n'a aucun effet sur les pools FPM ni sur les processus enfants Apache tant que tous les workers n'ont pas redémarré.
En 48 heures, des agences nationales de cybersécurité sur quatre continents ont demandé aux organisations de corriger immédiatement ou de mettre leurs systèmes hors ligne. Plusieurs gouvernements ont d'abord coupé leurs propres services publics, faute de pouvoir encore dire lesquels étaient exposés.
Alerte du NCSC et plus de 50 000 avertissements directs. Identifier chaque système PHP, le corriger ou envisager de le mettre hors ligne. 32 services gouvernementaux étaient indisponibles et quatre l'étaient partiellement, surtout par précaution, a déclaré le ministre au Parlement le 22 octobre. La surveillance de base des domaines du secteur public par la Government Cyber Unit utilise Hardenize, l'outil de gestion de la surface d'attaque de Red Sift, qui scanne .gov.uk toutes les huit heures.
Services gouvernementaux mis hors ligne sur avis du NCSC-NL, dont DigiD et le site web du Parlement. Le NCSC-NL tient l'inventaire public des produits qui intègrent PHP.
Tous les services web publics de l'État fermés par Valtori, l'agence informatique de l'État, le temps d'appliquer les correctifs.
Le Premier ministre a exhorté les propriétaires de sites à se préparer et à envisager une mise hors ligne. Le ministère des Finances, l'Agence météorologique et l'Agence nationale des impôts ont suspendu leurs services. Le JPCERT a publié des indicateurs de compromission.
Avertissement critique du BSI. Le centre informatique fédéral, ITZBund, a mis les sites web fédéraux hors ligne à titre purement préventif.
Alerte du CERT-FR : isoler les systèmes affectés. Le ministère de l'Intérieur a mis hors ligne les sites web des préfectures.
CISA et NSA : corriger maintenant ou mettre le système hors ligne. La NSA a déclaré que des cyberacteurs allaient probablement transformer ces failles en armes et a appelé à une correction immédiate dans l'ensemble des départements et agences du gouvernement américain.
Avis 2026-018 du CERT-EU publié avant les correctifs, suivi d'une déclaration conjointe de la Commission, de l'ENISA, du CERT-EU et d'Europol.
Alerte AL26-026 du Centre pour la cybersécurité. Certains sites web du gouvernement du Canada ont été temporairement indisponibles ; l'alerte a été mise à jour le 23 octobre pour inclure la troisième CVE.
Alerte critique de l'ACSC : agir maintenant. Identifier les systèmes PHP, surveiller toute activité malveillante, corriger dès que les mises à jour sont disponibles.
Mettre un service hors ligne est la réponse de dernier recours, et des gouvernements sur quatre continents s'y sont résolus en quelques heures. Voilà l'ampleur du problème d'inventaire, même pour des équipes bien dotées.
La gestion de la surface d'attaque Red Sift cartographie chaque hôte exposé sur Internet de votre parc et ce qu'il exécute, pour que la prochaine vulnérabilité critique arrive avec la réponse déjà prête.
Tout le contenu de cette page provient de sources publiques au 23 octobre 2026, à l'exception des résultats de la section 02, issus des données clients Red Sift ASM jusqu'au 26 octobre 2026. Le statut d'exploitation et le nombre d'expositions évoluent d'heure en heure ; consultez les avis d'origine avant d'agir sur la base d'un chiffre.