Ce que disent le BSI, la CISA, l’ENISA, Cloudflare et AWS sur PHP2Shell

Projet PHP et PHP Foundation

L’avis de php.net du 21 octobre est la source opérationnelle. Il indique que les deux failles peuvent permettre une exécution de code à distance sans authentification, que toute installation PHP servant des requêtes web est exposée, que mod_php présente le risque le plus élevé et que seule une mise à jour est une solution complète. Les versions correctives sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Selon l’article de la PHP Foundation du même jour, une RCE complète a été démontrée sur Apache mod_php avec les réglages par défaut avant le code applicatif, et confirmée sur PHP-FPM via des chemins applicatifs. La Foundation ne donne aucun nombre de compromissions.

NVD

Selon la chronologie de Tanium, la NVD a publié CVE-2026-109618 le 21 octobre 2026 à 14 h 17 UTC avec le statut « Undergoing Analysis ». Lorsque ce site a interrogé l’API NVD le 22 octobre 2026 vers 07 h 20 UTC, les deux entrées avaient le statut « Modified » et portaient, à côté du score CVSS v4.0 de 9.2 de l’équipe sécurité de PHP, un score CVSS v3.1 propre à la NVD (Primary) de 9.8 (Critique), vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Les deux scores proviennent de systèmes de notation différents et ne se contredisent pas. Pour les versions corrigées, l’avis PHP fait foi.

CISA

L’alerte de la CISA du 21 octobre 2026 exige une correction immédiate vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, un inventaire de PHP y compris là où il n’est qu’un composant, et la mise hors ligne des systèmes impossibles à mettre à jour, y compris PHP 8.1 et antérieures. Un pare-feu applicatif web peut offrir une certaine protection d’ici là. Concernant l’exploitation : la CISA n’en avait observé aucune au moment de la publication. L’alerte ne dit pas qu’une des CVE a été ajoutée au catalogue KEV. Ce site a reconsulté le flux JSON KEV de la CISA le 22 octobre 2026 vers 08 h 05 UTC : la version 2026.10.21 du catalogue (publiée le 21 octobre à 14 h 04 UTC) ne contenait toujours aucune des deux CVE.

ENISA, déclaration commune de l’UE et CERT-EU

L’ENISA a publié une déclaration commune sur les vulnérabilités critiques de PHP. Selon le texte consulté, l’équipe sécurité de PHP a publié les mises à jour le 21 octobre 2026 à 13 h 40 UTC, et les failles peuvent exécuter du code malveillant sans authentification sur des serveurs vulnérables. L’avis CERT-EU 2026-018 est un document distinct : sa version 1.1 indique que les correctifs sont parus le 21 octobre à 13 h 30 UTC, que des PoC circulent, ce qui augmente la probabilité d’une exploitation en cours, et recommande de corriger immédiatement ou d’isoler les applications exposées publiquement jusqu’à ce qu’un correctif soit appliqué et vérifié. Les heures 13 h 30, 13 h 40 et 14 h 00 UTC sont conservées telles que les sources les donnent.

Royaume-Uni et Pays-Bas

Le NCSC britannique conseille d’identifier PHP en général, pas seulement les anciennes versions, d’appliquer le durcissement de l’équipe PHP et de déconnecter un système si les atténuations provisoires ne sont pas possibles à temps. Pour les systèmes exposés, il faut rechercher une compromission. Il renvoie au dépôt php2shell du NCSC-NL recensant des logiciels qui dépendent de PHP – un inventaire de départ, pas la preuve qu’un produit non listé est sûr.

Canada, Allemagne et Japon

• Centre canadien pour la cybersécurité, AL26-026, 21 octobre 2026 : les deux CVE sont décrites comme des use-after-free pouvant permettre à un acteur non authentifié d’exécuter du code arbitraire. Le Centre cite des rapports de source ouverte sur un PoC disponible et aucune exploitation active constatée ; il cite les mêmes quatre versions correctives et indique que 8.1 et antérieures ne recevront pas de version officielle.
• BSI, alerte 2026-297981-1032, version 1.0 du 21 octobre 2026 : un CVSS v4.0 de 9.2 signifie une exécution de code à distance sans authentification ni interaction de l’utilisateur. Aucune exploitation confirmée n’est connue, mais des rapports non confirmés d’exploits existent déjà. Le correctif était attendu à 16 h 00 heure allemande (14 h 00 UTC) et devait être appliqué dès sa parution. Lisez-le comme la position du BSI au moment de cette version, pas comme une levée d’alerte ultérieure.
• Le JPCERT/CC a publié le 22 octobre 2026 son alerte complète JPCERT-AT-2026-0033 : PHPにおける複数の脆弱性（CVE-2026-109618、CVE-2026-109619）に関する注意喚起. Elle indique qu’une exploitation peut permettre d’exécuter du code arbitraire avec les privilèges du processus PHP, que le JPCERT/CC a constaté une large utilisation du produit au Japon, et demande d’appliquer rapidement les correctifs et de rechercher une éventuelle compromission. Le PHP fourni par les distributions Linux et les produits qui embarquent PHP peuvent aussi être concernés. Pour la recherche de compromission, elle relaie les indices des découvreurs : cookies PHPSESSID anormalement longs ou mal formés dans des réponses passées, requêtes multipart/form-data suspectes suivies d’erreurs de limite mémoire PHP ou d’erreurs HTTP 500, workers PHP arrêtés ou redémarrés de façon inattendue. L’absence de ces traces ne prouve pas l’absence d’attaque. L’alerte ne formule pas de constat d’exploitation propre. La liste JVN du JPCERT/CC comportait le même matin une entrée liée, horodatée 10:30.
• L’IPA (Information-technology Promotion Agency, Japon) a publié le 22 octobre 2026 la page PHPの脆弱性対策について (CVE-2026-109618, CVE-2026-109619: PHP2shell), dans le prolongement de sa demande de préparation du 21 octobre. Elle décrit CVE-2026-109618 comme une faille dans la gestion du manque de mémoire (OOM) et CVE-2026-109619 comme une faille dans le traitement des requêtes, par lesquelles un tiers distant peut exécuter du code arbitraire, cite les quatre mêmes versions correctives et reprend Wiz, selon qui PHP à partir de 5.4 est touché par au moins l’une des deux failles. Pour PHP 8.1 et antérieur, qui ne reçoivent pas de correctif, l’IPA conseille de passer à une version prise en charge ou à un produit corrigé, d’appliquer des mesures provisoires ou des restrictions d’accès et, à défaut, d’envisager de bloquer l’accès externe ou d’arrêter temporairement le service. La page ne contient aucune déclaration sur l’exploitation.

Singapour, Hong Kong et Thaïlande

• La Cyber Security Agency de Singapour, alerte AL-2026-151 du 21 octobre 2026, mise à jour le 22 octobre : les deux CVE sont notées CVSS v4.0 9.2 et peuvent permettre une exécution de code à distance sans authentification. Dans la rubrique « Known Exploitation », elle fait état de signalements de tentatives d’exploitation à grande échelle et du développement de plusieurs preuves de concept. Toutes les versions de PHP seraient concernées ; elle demande une mise à jour immédiate, en priorité pour les systèmes exposés à Internet, et de vérifier si PHP est présent sur les serveurs web via des composants tiers, même si le site principal n’utilise pas PHP.
• La liste des bulletins du HKCERT du 22 octobre 2026 classe « PHP Multiple Vulnerabilities » en risque extrêmement élevé et précise que CVE-2026-109618 et CVE-2026-109619 sont exploitées dans la nature. C’est la formulation du HKCERT ; le résumé ne nomme aucun site compromis.
• ThaiCERT (National Cyber Security Agency de Thaïlande) a publié une alerte sur X le 22 octobre 2026 à 07:40 UTC (publication). Elle indique qu’une preuve de concept a été publiée, reprend les quatre mêmes versions corrigées, cite PHP-FPM, Apache mod_php, php-cgi, FrankenPHP et LiteSpeed, et rappelle que des paquets de distribution ou de panneau peuvent garder l’ancien numéro de version avec un correctif rétroporté, qu’il faut redémarrer les workers PHP après la mise à jour et reconstruire les images de conteneur à partir d’images de base corrigées. Elle ne signale pas de compromission confirmée.

Cloudflare et les chiffres du 22 octobre

Le blog de Cloudflare du 21 octobre indique que des règles WAF pour les offres gratuites et payantes étaient actives dès 03 h 02 UTC, que la faille avait fuité avant la publication officielle et que Cloudflare avait observé du trafic d’attaque et des modifications de charges visant les règles ; les clients devaient tout de même corriger. Un article de Reuters du 22 octobre 2026 cite Matthew Prince dans un message sur X (que ce site n’a pas ouvert) : des milliers de tentatives dans les dix heures précédant l’annonce, des dizaines de milliers dans les 45 minutes suivantes, des centaines de milliers en deux heures et des millions au moment du message. Le même article indique que des sites gouvernementaux en Europe et ailleurs ont été mis hors ligne, et que Mitsubishi UFJ Financial Group ainsi que le ministère japonais des Finances ont temporairement suspendu certains services par mesure d’urgence. Cela décrit des mises hors ligne, pas une compromission par PHP2Shell.

AWS et watchTowr

AWS indique que MadPot a vu une tentative d’exploitation le 17 octobre 2026, quatre jours avant la divulgation, puis d’autres tentatives et des PoC le 21 octobre, y compris avant la fin de l’embargo. On ignore si elles auraient réussi sur de vrais systèmes ; après le correctif, PHP2Shell est exploitée massivement – il s’agit des tentatives observées, pas d’une liste publiée de sites compromis. watchTowr observe des tentatives d’exploitation actives des deux CVE sur son réseau de honeypots ; selon SecurityWeek, sans tentative réussie.

Le bulletin de sécurité AWS 2026-143-AWS (publié le 21 octobre 2026 à 14 h 30 PDT, mis à jour pour la dernière fois à 20 h 30 PDT) indique que les services AWS eux-mêmes ne sont pas affectés, mais que les clients utilisant des versions de PHP affectées dans Amazon WorkMail, Elastic Beanstalk, Amazon Linux ou Lightsail peuvent l’être. L’impact est limité au worker PHP concerné et à ses droits applicatifs ; aucune propagation entre clients n’a été établie à ce jour. L’état par service figure sur la page état des éditeurs.

Datadog, Qualys, Tanium, Huntress et Elastic

• Datadog Security Labs indique avoir reproduit les deux problèmes de manière indépendante et que l’authentification dans l’application n’arrête pas le chemin mod_php. Seul le correctif est une solution complète. Nous ne reproduisons pas les étapes de reproduction.
• Qualys conseille, dans une mise à jour du 21 octobre 2026, de prioriser le PHP exposé publiquement, en commençant par Apache mod_php.
• Tanium indique qu’une exploitation dans la nature est signalée, mais que des exploits publics fiables restaient rares au moment de la rédaction, et qu’aucune CVE ne figurait dans la mise à jour KEV du 21 octobre examinée.
• Huntress conseille une mise à jour immédiate vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35 et n’avait encore observé aucune exploitation chez ses partenaires dans la partie affichée par la recherche.
• Elastic Security Labs indique, dans un billet du 21 octobre 2026, qu’aucune preuve de concept publique fiable de bout en bout n’existait au moment de la rédaction ; sa détection repose donc sur ce à quoi mène toute RCE PHP : un serveur web ou un worker PHP (php-fpm, php-cgi, lsphp, Apache, nginx) qui lance un shell, récupère une seconde charge avec curl ou wget, ou écrit de nouveaux fichiers de script dans la racine web. Le billet liste les règles Elastic (endpoint et SIEM) couvrant ces comportements et des requêtes d’inventaire pour retrouver les installations PHP. Elastic précise que cela ne garantit pas une couverture complète, par exemple face à une exécution sans fichier.

Distributions et éditeurs de panneaux en bref

Le bulletin RHSB-2026-013 de Red Hat indique que certaines mises à jour sont disponibles et d’autres en préparation. Ubuntu a publié des correctifs pour toutes les versions prises en charge. cPanel a publié des mises à jour pour ea-php74 et supérieures, Plesk des correctifs pour le PHP fourni. Détails et limites de ces affirmations sur la page des éditeurs.

Mises hors ligne préventives

Le PHPocalypse Tracker, tenu par la communauté, recense les sites mis hors ligne à cause de PHP2Shell, d’après des signalements publics et ses propres vérifications. Le 22 octobre 2026, il comptait 50 entrées : 24 aux Pays-Bas, 17 organismes publics, 44 déjà revenus en ligne. On y trouve le Parlement néerlandais et le NCSC-NL, DigiD, l’université de Vienne, DeviantArt et 4chan (en lecture seule). Côté France, la CNIL renvoyait encore une erreur HTTP 503 lors de notre vérification, et plusieurs sites de préfectures (Nord, Rhône, Bouches-du-Rhône) sont listés. La plupart parlent de précaution ; aucune entrée n’est une compromission confirmée. Les heures sont celles du premier signalement.