Secu
Failles PHP2Shell : Panique sur Internet et dans les DSI…
Par Laurent Delattre, publié le 22 octobre 2026
Mises au jour grâce à l’IA, deux failles critiques tapies depuis 2012 au cœur du moteur PHP ont poussé mercredi des administrations de toute l’Europe à débrancher leurs sites. Au-delà du correctif, les DSI doivent surtout savoir où PHP s’exécute réellement dans leur SI.
On aura rarement, probablement même jamais, vu autant de sites débranchés en une seule journée. Préfectures coupées par le ministère de l’Intérieur à la demande de l’ANSSI, portails gouvernementaux néerlandais et finlandais débranchés, sites de la Région flamande déconnectés… Ce mercredi 21 octobre, la prudence l’a emporté sur la continuité de service.
Et pour cause. Baptisées d’une même appellation « PHP2Shell » et notées 9,2 sur l’échelle CVSS v4.0 (autrement dit d’une sévérité extrêmement critique), les deux vulnérabilités CVE-2026-109618 et CVE-2026-109619 permettent d’exécuter du code à distance sans authentification.
Le CERT-FR a rapidement émis une alerte, le CERT-EU recommande de couper les sites impossibles à corriger sans délai. Il y a panique à bord. Car PHP anime 70 % des sites Web de la planète !
Des failles dénichées par l’IA
Les chercheurs de Calif, partenaires d’OpenAI dans le cadre du programme Patch the Planet, ont découvert la première faille grâce au modèle GPT-5.6 Sol et l’ont signalée à l’équipe PHP le 11 août. Wiz, filiale de Google, les a également découvertes de son côté et en a signalé une seconde le 24 août, là encore grâce à des modèles de dernière génération.
C’est important de le signaler car, pour Wiz, l’IA a désormais fait sauter un verrou et fait basculer la chasse aux vulnérabilités dans une autre ère : démontrer leur exploitabilité exigeait un enchaînement d’étapes aux limites des capacités humaines.
Après une fuite anonyme le 20 octobre sur Hacker News, l’équipe PHP a dû publier mercredi de toute urgence, donc hors cycle, les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35 corrigeant les failles.
Ces failles se logent dans le moteur PHP lui-même, affectant toutes les applications Web et tous les sites s’appuyant sur cette technologie. WordPress, Drupal, Joomla ou Magento, même parfaitement à jour, ont ainsi été compromis par les chercheurs par le truchement des failles PHP2Shell.
Le code fautif remonte à PHP 5.4 et la configuration par défaut est vulnérable. Cela fait une pléthore de versions PHP vulnérables et de logiciels essentiels du Web à même d’être compromis.
Une faiblesse qui ne nécessite aucune authentification
Les deux failles reposent sur le même défaut : PHP fait mal son ménage quand une requête plante. Le moteur traite les requêtes à la chaîne en réutilisant la même mémoire, qu’il doit nettoyer entre deux visiteurs. Or, quand une requête plante (mémoire épuisée, erreur fatale), PHP abandonne tout sans finir ce ménage : la requête suivante réutilise une zone mémoire déjà libérée, que l’attaquant a pu remplir à sa guise. La CVE-2026-109618 affecte la gestion des pénuries de mémoire, tandis que la CVE-2026-109619 porte sur des « notes » internes qui ne sont jamais effacées. Cette seconde faille permet en prime d’aspirer des fragments de mémoire contenant mots de passe, jetons ou clés d’API d’autres visiteurs.
L’attaquant n’a besoin d’aucun compte pour provoquer des plantages à volonté et exécuter des charges d’attaque. Ainsi, de simples formulaires d’envoi de fichiers piégés suffisent à provoquer le plantage, puis à exécuter du code malveillant avec tous les droits du serveur Web. Aucune authentification ni aucun clic d’utilisateur n’est nécessaire. L’attaquant peut ainsi prendre la main sur le serveur Web, lire les fichiers de configuration, voler les identifiants de la base de données, modifier des données, déposer une porte dérobée et même rebondir vers le réseau interne de l’entreprise !
Des attaquants déjà très actifs
Cloudflare a observé des attaques dès 9 h 43 (heure de Paris) mercredi, six heures avant les correctifs, et un outil d’exploitation circule désormais publiquement. « PHP2Shell réunit bon nombre des ingrédients de Log4Shell : une exécution de code à distance sans authentification, dans un logiciel présent presque partout, déclenchée par une seule requête spécialement conçue », souligne Debrah Galea, Senior Product Marketing Manager chez Filigran, qui note toutefois que « PHP est plus facile à repérer, ce qui permet aux organisations d’identifier plus vite leurs expositions. Et contrairement à Log4Shell, un correctif est déjà disponible ».
Encore faut-il pouvoir l’appliquer : les branches 8.1 et antérieures ne recevront aucun correctif officiel ! Mathieu Rigotto, CISO de Filigran, s’agace de la chronologie : « Publier un exploit PHP2Shell fonctionnel avant la disponibilité du correctif officiel n’était pas de la recherche. Cela a donné une longueur d’avance aux attaquants, alors que les défenseurs n’avaient rien à déployer. »
Les géants du cloud sur le pont
Les grands acteurs du cloud, eux, avaient été mis dans la confidence depuis plusieurs semaines. Google Cloud, AWS, Microsoft, Cloudflare, Akamai, Fastly ou encore Imperva figuraient parmi les partenaires associés en amont pour préparer détections et parades. Cloudflare a dégainé le premier : ses règles WAF protégeaient tous ses clients, offre gratuite comprise, dès 3 h 02 (UTC) mercredi, onze heures avant les correctifs. Fastly a suivi avec un « patch virtuel » qu’il juge lui-même partiel. Google Cloud a mis à jour d’office App Engine standard et Cloud Run, mais laisse à ses clients le soin de reconstruire leurs conteneurs, de redéployer App Engine flexible et d’abandonner les runtimes PHP 8.1 et antérieurs.
Le modèle de responsabilité partagée joue ici à plein : le PaaS se corrige tout seul, l’IaaS reste l’affaire de la DSI.
Plus discrets, AWS et Microsoft n’avaient pas publié de bulletin détaillé mercredi soir, et les mainteneurs d’Amazon Linux promettaient seulement des paquets corrigés « au plus vite ». Les hébergeurs mutualisés, enfin, comptent sur des boucliers provisoires comme Imunify360 de CloudLinux en attendant leurs propres mises à jour.
Inventorier avant de corriger
« Le plus difficile n’est pas d’installer le correctif, mais de savoir où PHP s’exécute : sous les systèmes de gestion de contenu, les plateformes d’hébergement, les appliances et les produits tiers. Leurs éditeurs ne mentionnent que très rarement la plateforme sous-jacente qui les animent. Cette diversité d’environnements animés par PHP explique aussi pourquoi des gouvernements préfèrent mettre des sites hors ligne plutôt que d’attendre une correction. Car la rapidité joue dans les deux sens. L’IA a trouvé des failles restées inaperçues pendant plus de dix ans, et les mêmes outils permettent aux attaquants de développer des exploits fonctionnels en quelques heures… », explique Samuel Hassine, CEO et cofondateur de Filigran.
D’où trois chantiers urgents qui s’imposent à tout RSSI et à tout DSI : inventorier en interrogeant éditeurs et hébergeurs, corriger d’abord ce qui est exposé sur Internet, puis supposer qu’un attaquant est déjà entré et traquer web shells, fichiers inattendus et connexions sortantes suspectes.
Pour les serveurs qui ne peuvent être mis à jour, soit pour des raisons techniques, soit parce qu’ils s’appuient sur une version antérieure à la « 8.2 », quelques palliatifs permettent de gagner du temps.
Comme l’explique l’alerte de l’ANSSI, désactiver « session.upload_progress » ne suffit pas à lui seul, et les modes maintenance des CMS ne protègent de rien, PHP analysant la requête avant l’application. Il faut donc intervenir sur le serveur Web ou sur les WAF (Web Application Firewall) pour bloquer toutes les requêtes « multipart/form-data ».
Et si cela ne peut être réalisé en urgence, alors il reste la solution radicale opérée par bien des préfectures : éteindre les serveurs. « Mettre un site hors ligne pendant une journée est une décision bien moins coûteuse que d’expliquer une compromission pendant un an », rappelle Samuel Hassine.
Reste les enseignements à en tirer. PHP2Shell démontre violemment et grandeur nature ce que l’IA change en sécurité : les modèles qui débusquent des failles vieilles de quatorze ans ramènent aussi à quelques heures (voire moins) le délai entre divulgation et exploitation par les attaquants. « Des urgences comme celle-ci ne testent pas la rapidité avec laquelle les organisations lisent les avis de sécurité ; elles testent leur capacité à savoir, avant même l’alerte, où elles sont exposées », estime Mathieu Rigotto. Une question à laquelle bien des DSI auraient préféré savoir répondre avant l’alerte du jour…
Pour en savoir plus : [Màj] Multiples vulnérabilités dans PHP – CERT-FR
Photo : Ben Griffiths / Unsplash
À LIRE AUSSI :
À LIRE AUSSI :
