Le 21 octobre, PHP a publié en urgence un correctif pour deux failles trouvées avec l’aide de l’IA, qui permettent de prendre le contrôle d’un serveur sans mot de passe. Cinq jours plus tard, la faille PHP2Shell fait l’objet de premières attaques réussies confirmées, et elle concerne directement les sites WordPress.
Article mis à jour le 26 octobre avec les premières exploitations confirmées.
Que permet la faille PHP2Shell ?
Il s’agit de deux failles, CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10 par l’équipe sécurité de PHP. Elles se trouvent dans le moteur PHP lui-même, celui qui prépare les pages d’environ 70 % des sites, dont WordPress, Drupal et Joomla.
Le principe : en provoquant une erreur de mémoire au bon moment, un attaquant pousse le serveur à réutiliser une zone déjà libérée, puis y glisse ses propres instructions. Les chercheurs de Wiz l’ont démontré sur les dernières versions de WordPress, Drupal et Joomla. Sans aucun identifiant.
Qui l’a trouvée, et quel rôle a joué l’IA ?
Deux équipes, sans se concerter. Le 11 août, un chercheur de la société Calif, aidé par GPT-5.6 Sol d’OpenAI dans le cadre du programme Patch the Planet, signale un chemin d’exécution de code ; OpenAI rapporte le même problème le même jour. Wiz trouve de son côté la première faille le 19 août avec son outil Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol. Deux jours plus tard, l’équipe prend le contrôle d’un WordPress, et elle prévient PHP le 24.
Le détail qu’on a peu lu : la cause profonde avait été signalée dès 2024, lors du premier audit externe du code de PHP. Mené pendant 57 jours par l’entreprise française Quarkslab, cet audit avait remonté 27 problèmes, mais faute de budget il ne couvrait que les parties les plus critiques du code. Il manquait le temps de transformer cette faiblesse en attaque. Selon Wiz, un seul chercheur aidé de ces modèles a fait en une semaine ce qui aurait demandé des mois à une équipe de haut niveau.
OpenAI, qui pilote Patch the Planet, a eu ses propres soucis avec ses agents : début octobre, l’entreprise a dû prévenir plus de 100 organisations d’activités d’agents non prévues.
Pourquoi des sites ont-ils été coupés ?
Le 20 octobre, les numéros des failles ont circulé en ligne, avec une mauvaise heure de publication et une note fausse de 10. PHP a avancé la sortie du correctif au 21 octobre. Cloudflare avait activé des règles de filtrage dès 3 h 02 (heure UTC), environ neuf heures avant l’annonce, y compris pour les comptes gratuits. L’entreprise dit avoir vu des attaquants modifier leurs requêtes pour passer ces filtres.
En Europe, des sites d’administrations, d’écoles et d’hôpitaux ont été mis hors ligne par précaution. Aux États-Unis, la NSA a demandé de corriger immédiatement ou de couper. Au Japon, la Première ministre Sanae Takaichi a appelé les organisations à vérifier leurs sites.
PHP2Shell exploitée : où en est-on le 26 octobre ?
Les attaquants n’ont pas attendu le correctif. Amazon a repéré une première tentative le 17 octobre sur ses serveurs pièges, quatre jours avant l’annonce, depuis un réseau d’anonymisation. Le jour de la publication, Cloudflare, watchTowr ou Patchstack ont vu passer des vagues de tentatives, toutes jugées infructueuses à ce moment-là.
Le week-end a changé la donne. Selon BleepingComputer, une exploitation réussie a été documentée sur un serveur Apache avec PHP 8.4.26, avec exécution de code et fuite de mémoire, une analyse confirmée par le chercheur Marcus Hutchins (Expel). SOCRadar a aussi trouvé, sur un serveur contrôlé par un attaquant, un outil présenté comme un exploit « en un clic » pour cette même version ; selon Hunt.io, ce groupe a visé 123 serveurs chez des hébergeurs et des fournisseurs d’accès. Un autre exploit public contourne une protection mémoire courante (l’ASLR) sur une configuration PHP de production, et des attaquants tentent d’installer le logiciel malveillant Mirai.
Tout n’est pas clair pour autant. Au 25 octobre, l’agence américaine de cybersécurité CISA n’avait pas ajouté ces failles à son catalogue des vulnérabilités exploitées, et disait ne pas avoir observé d’attaque réussie. Unit 42, la cellule de recherche de Palo Alto Networks, a retiré son affirmation liant à PHP2Shell le piratage d’un organisme public européen, où des agents d’IA avaient servi après l’intrusion. Et la fuite elle-même fait débat : selon Blog Nouvelles Technologies, la fondation PHP accuse l’éditeur Chainguard d’avoir rompu l’embargo six heures trop tôt, ce que Chainguard conteste.
Mon site WordPress est-il concerné par PHP2Shell ?
Probablement, s’il tourne sur une version de PHP antérieure au correctif. La mise à jour de WordPress ou des extensions n’y change rien : le correctif s’installe sur le serveur, par vous ou par votre hébergeur.
- Votre version de PHP s’affiche dans le tableau de bord : Outils, Santé du site, onglet Infos.
- Versions corrigées : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
- Le numéro peut tromper : Ubuntu, Debian et Red Hat appliquent les correctifs sans changer le numéro de version. Demandez une confirmation écrite à votre hébergeur.
- Pour PHP 8.1 et plus ancien, aucune nouvelle version officielle : l’équipe PHP a seulement publié des correctifs de code source minimaux pour 7.4, 8.0 et 8.1, à appliquer par l’hébergeur. Des prestataires comme TuxCare vendent aussi des correctifs pour ces versions.
- Si votre site n’était pas corrigé, vérifiez qu’il n’a pas déjà été visité : Amazon conseille de faire remonter les recherches au 17 octobre, et non à la date de l’annonce.
Le cas n’a rien de marginal. Selon un recensement de CybelAngel, 59 % des 2,24 millions de serveurs PHP exposés sur Internet tournent sur une version qui ne recevra pas de correctif officiel. Le pare-feu de Cloudflare aide, mais l’entreprise le dit elle-même : seule la mise à jour de PHP règle le problème.
Notre avis
Les défenseurs avaient deux mois d’avance grâce à l’IA. Une fuite a suffi pour les ramener à quelques jours, et il a fallu moins d’une semaine pour voir une attaque réussie documentée. Je reste convaincu que l’IA rend Internet plus sûr à long terme, à condition que la correction suive : aujourd’hui, elle dépend d’équipes souvent bénévoles et d’hébergeurs pas toujours rapides. C’est un risque pour les mois qui viennent, surtout pour les petits sites que personne n’a mis à jour depuis des années.
Sources
- Wiz Research – PHP2Shell (source primaire)
- Amazon Threat Intelligence – PHP2Shell exploitation prior to public disclosure (source primaire)
- The PHP Foundation – PHP Core Security Audit Results (source primaire, audit 2024)
- BleepingComputer – PHP2Shell security flaws now successfully exploited in the wild
- The Hacker News – PHP2Shell Exploit Attempts Hit Millions
- The Hacker News – PHP2Shell Exploitation Attempts Continue (mise à jour Unit 42)
- SOCRadar – PHP2Shell: affected versions and how to fix them
- Blog Nouvelles Technologies – PHP2Shell, anatomie d’une faille et d’une divulgation qui a dérapé
- SANS Internet Storm Center – Critical PHP Vulnerability
- Unite.AI – PHP Patches Two Critical RCE Flaws Found with Frontier AI Models
- OfficeChai – GPT-5.6 Sol Helped Flag The Critical PHP Bug
- PPC Land – Cloudflare blocks php2shell exploits 9 hours before disclosure
- Martin Cid – WordPress Sites Can’t Install the Fix Themselves
- CybelAngel – 2.24M Internet-Facing PHP Hosts
- Beinsure – Critical PHP vulnerabilities trigger global security alerts


Laisser un commentaire