Les sites PHP se font pirater : voici comment vous protéger

Commençons par le nom, car il aide à mesurer l’ampleur du problème. PHP2Shell n’est pas le bug d’un plugin ou d’un thème : c’est un défaut du moteur PHP lui-même, c’est-à-dire du programme qui, sur le serveur, interprète et exécute le code des sites. Quand le défaut est là, peu importe la qualité du site qui tourne dessus : il est exposé de toute façon. Et PHP fait tourner environ 69 % des sites web du monde, WordPress compris.

Techniquement, il s’agit de deux vulnérabilités distinctes, CVE-2026-109618 et CVE-2026-109619. La première exploite un épuisement de la mémoire : si le serveur manque de mémoire au mauvais moment, les structures internes d’une requête restent initialisées à moitié, mais le nettoyage de fin de requête les traite comme complètes et finit par écrire là où il ne devrait pas. La seconde concerne l’état global : des données d’une requête survivent à la mémoire qui les contenait, et la requête suivante sur le même processus les retrouve et les utilise. Dans les deux cas, un attaquant qui envoie des requêtes construites sur mesure parvient à exécuter du code sur le serveur, sans mot de passe, sans compte et sans passer par aucun formulaire.

Le bug était là depuis des années, de la version 5.4 à la 8.5. Un indice était déjà apparu en 2024, mais sans exploit connu, personne ne l’avait jugé urgent. Il a été trouvé en août 2026 par deux groupes indépendants, les chercheurs de Wiz et le projet Patch the Planet d’OpenAI, tous deux à l’aide de modèles d’intelligence artificielle chargés de lire le code source à la recherche d’erreurs. Ce détail nous a frappés : la technologie qui trouve les failles est la même qui les exploite ensuite.

Les correctifs sont sortis le 21 octobre : PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Ceux qui sont en 8.1 ou antérieur, désormais hors support, n’ont aucune version à installer et doivent migrer. Aucune mesure d’atténuation partielle ne tient : les mainteneurs de PHP le disent, et nous le confirmons, nous qui avons suivi l’affaire dès les premiers signalements. Amazon a intercepté une tentative d’exploitation dès le 17 octobre, quatre jours avant que la faille ne soit publique, et plusieurs gouvernements européens ont préféré éteindre leurs sites plutôt que de prendre le risque.

La seconde nouvelle nous a fait réfléchir encore davantage. Reuters a rapporté une enquête de la société de sécurité NorForge : un groupe sinophone a mis des agents d’intelligence artificielle au travail contre plus de 1 200 sites aux États-Unis, au Canada, en Australie et au Japon, et en a compromis plus d’une centaine. Personne ne tapait de commandes : l’agent explorait le site, essayait les chemins possibles et continuait seul, en moyenne 23 heures par cible.

Les outils n’avaient rien d’exotique : DeepSeek, GLM, Grok et Claude Code. Ce dernier est un programme, pas un modèle, et dans les configurations retrouvées il était souvent relié à d’autres modèles que ceux d’Anthropic. Dans l’une des intrusions documentées, la porte d’entrée a encore été PHP, mais à un autre endroit : la désérialisation non sécurisée d’objets et d’anciens composants du framework Zend. Du code légitime, écrit il y a des années, jamais mis à jour et resté à l’écoute sur internet.

Mises bout à bout, les deux histoires disent une seule chose. Le délai entre la découverte d’une faille et son exploitation se mesure désormais en jours, et en face il n’y a plus une personne qui choisit la cible, mais un logiciel qui essaie tout, partout, jusqu’à ce que quelque chose cède.