Le 21 octobre 2026, la fondation PHP a publié en urgence des correctifs pour deux failles critiques (CVE-2026-109618 et CVE-2026-109619, score CVSS 9,2). Elles permettent d'exécuter du code à distance sur un serveur, sans compte ni authentification. Le problème est dans PHP lui-même : des millions de sites sont concernés, WordPress compris.
Ce qui s'est passé
- 19 au 24 août : selon Recorded Future, Wiz Research découvre la première faille avec des outils assistés par IA, confirme une exécution de code à distance contre Drupal puis WordPress, et signale le tout en privé à l'équipe PHP le 24 août. PHP accuse réception le 21 septembre.
- 20 octobre : la fondation PHP annonce une mise à jour de sécurité hors cycle pour le lendemain, 16 h (heure de Paris), pour deux failles notées 9,2 sur 10. Des détails techniques fuitent sur Hacker News, et la société watchTowr dit avoir reproduit l'une des failles.
- 21 octobre, 4 h 29 : une archive contenant des informations sur les failles est déposée sur VirusTotal.
- 21 octobre, vers 9 h 30 : Patchstack reçoit de ses hébergeurs partenaires plusieurs signalements d'exploitation active (9 h 34). Cloudflare observe aussi des attaques (dès 9 h 43) et protège tous ses clients avec des règles de pare-feu, offre gratuite comprise, en solution provisoire.
- 21 octobre, 15 h 52 : PHP publie les versions corrigées 8.5.12, 8.4.27, 8.3.36 et 8.2.35, un peu avant l'heure annoncée.
- Dans la journée : à la demande de l'ANSSI, le ministère de l'Intérieur met l'ensemble de ses sites en maintenance préventive. Des administrations d'autres pays européens font de même. La NSA et le CERT-EU conseillent de mettre hors ligne les sites qui ne peuvent pas être corrigés tout de suite.
Des exploits de démonstration circulent sur GitHub, mais leur fiabilité varie : certains reposent sur une hypothèse que leur auteur a lui-même invalidée depuis. Selon Recorded Future, en fin de journée le 21 octobre, les informations publiques ne permettaient pas d'établir l'ampleur des compromissions réussies.
Pourquoi c'est grave
PHP fait tourner environ 70 % des sites dont on connaît la technologie serveur : WordPress, Drupal, Joomla, Magento, Laravel, et beaucoup d'applications sur mesure.
Les failles ne sont pas dans un plugin ou dans un CMS, mais dans le moteur PHP. Mettre à jour WordPress ou son application ne suffit donc pas : c'est la version de PHP installée sur le serveur, ou fournie par l'hébergeur, qui doit être corrigée. Même un site très simple peut être vulnérable.
Le mécanisme, expliqué simplement
Quand une requête fait planter PHP (mémoire épuisée, erreur fatale), le moteur ne termine pas son nettoyage. La requête suivante peut alors réutiliser une zone mémoire que l'attaquant a remplie lui-même. Il n'a besoin ni de compte ni d'un clic de la part d'un utilisateur.
Une fois le serveur compromis, un attaquant peut lire les fichiers de configuration, voler les accès à la base de données, modifier des données, installer une porte dérobée ou rebondir vers le reste du réseau. Les chercheurs de Wiz ont aussi montré qu'on pouvait lire des mots de passe, jetons et clés d'API présents en mémoire, sans même exécuter de code. Le code concerné remonte à PHP 5.4, soit plus de dix ans.
Combien de serveurs sont exposés ?
Deux scans indépendants d'Internet donnent un ordre de grandeur. Ils ne comptent pas les serveurs réellement vulnérables et ne mesurent pas la même chose : leurs chiffres ne s'additionnent pas.
| Scan | Ce qui est compté | Total | Branches sans support |
|---|---|---|---|
| Modat | Services PHP affichant une version lisible, vus dans les 10 jours avant le 20 octobre | 4,38 millions de services, sur 1,89 million d'hôtes | ~79 % des services à version lisible ; PHP 7.4 seul : 878 761 services |
| VirusTotal | Adresses IP sous PHP au 21 octobre, version affichée ou non | ~5,1 millions d'IP, dont 1,1 million affichent leur version | ~758 000 IP (branches 5.4 à 8.1), contre 272 000 sur une branche supportée |
Deux enseignements. D'abord, l'essentiel du PHP exposé tourne sur des branches en fin de vie, qui ne recevront pas de correctif officiel : PHP 7.4, arrêté depuis 2022, pèse à lui seul plus que n'importe quelle branche supportée. Ensuite, environ quatre serveurs sur cinq ne révèlent pas leur version, donc les scans passent à côté d'une grande partie de la surface exposée.
Une compromission peut aussi dépasser le serveur web : parmi les hôtes PHP repérés par VirusTotal, environ 394 000 exposent également SSH, 233 000 MySQL et 68 000 le bureau à distance (RDP).
Le rôle de l'IA
Ces failles sont restées invisibles pendant plus de dix ans. Ce sont des modèles d'IA de dernière génération qui ont permis de les trouver. Selon les sources, les sociétés Calif et Wiz les ont signalées à l'équipe PHP en août, en s'appuyant notamment sur le modèle GPT-5.6 Sol d'OpenAI. Wiz indique aussi avoir utilisé Gemini 4 Argon.
Le point important n'est pas la découverte, mais l'exploitation. Transformer ces bugs en attaque fonctionnelle demande d'enchaîner plusieurs failles, puis d'adapter l'exploit à chaque version de PHP et à chaque configuration. Cela prenait des mois à une équipe d'experts. Wiz affirme qu'un seul chercheur, assisté par l'IA, l'a fait en une semaine, et que l'adaptation à une nouvelle cible se compte désormais en heures.
Le délai entre l'annonce d'une faille et les premières attaques se réduit. Cette fois, des attaques ont été observées avant même la sortie du correctif. Les mêmes outils aident aussi les défenseurs à trouver et corriger des failles avant les attaquants.
Que faire
- 1.Recenser vos versions de PHP : chaque site, serveur, ancien projet, sous-domaine et interface d'administration. PHP se cache souvent derrière des CMS ou des logiciels tiers qui ne le mentionnent pas.
- 2.Installer une version corrigée : PHP 8.2.35, 8.3.36, 8.4.27 ou 8.5.12, ou le paquet corrigé de votre distribution Linux ou de votre hébergeur (son numéro de version peut différer).
- 3.Redémarrer les processus PHP (PHP-FPM, Apache avec mod_php, services persistants), sinon l'ancienne version reste active en mémoire.
- 4.Chercher des traces d'intrusion, en remontant avant la publication du correctif : des attaques ont été signalées dès le matin du 21 octobre, et l'exploitation se produit sous la couche applicative. Regardez à partir du 20 octobre les requêtes web inhabituelles, les plantages de processus PHP, les commandes inattendues, les fichiers modifiés et les nouveaux comptes administrateur. Si vous trouvez une compromission, lancez une réponse à incident et changez tous les identifiants qui ont pu être exposés. Le correctif ne nettoie pas un serveur déjà compromis.
PHP 8.1 et versions antérieures
Elles ne reçoivent plus de mises à jour officielles régulières. PHP a publié des correctifs minimaux pour les branches 7.4, 8.0 et 8.1, et certains distributeurs proposent des correctifs adaptés. Demandez une confirmation à votre hébergeur, puis prévoyez une migration vers une branche maintenue.
Si vous ne pouvez pas mettre à jour tout de suite, des mesures provisoires réduisent le risque : désactiver session.upload_progress dans la configuration PHP, bloquer les requêtes multipart/form-data au niveau du serveur web ou d'un pare-feu applicatif, limiter la taille des requêtes.
- Aucune de ces mesures ne corrige complètement les failles. Seule la mise à jour le fait.
- Bloquer le multipart casse l'envoi de fichiers et l'ajout de médias dans WordPress.
- Le mode maintenance d'un CMS ne protège pas : PHP traite la requête avant l'application.
Pour un site qui ne peut ni être corrigé ni protégé, le CERT-FR comme le CERT-EU envisagent de le couper temporairement.
Et pour un site WordPress en hébergement mutualisé ?
Sur un mutualisé, vous ne contrôlez pas le serveur : c'est l'hébergeur qui applique le correctif du moteur PHP. Votre rôle est de vérifier que cela a bien été fait.
- Regardez la version de PHP utilisée par votre site dans l'espace client de l'hébergeur, et choisissez la branche récente la plus compatible avec votre thème et vos extensions.
- Suivez les communications de l'hébergeur sur PHP2Shell et demandez-lui une confirmation écrite si rien n'est publié.
- Gardez WordPress, le thème et les extensions à jour, mais ne vous y fiez pas : cela ne remplace pas le correctif PHP.
- Faites une sauvegarde complète avant tout changement de version, et testez le site après.
En attendant leurs propres mises à jour, certains hébergeurs mutualisés s'appuient sur des protections provisoires, comme Imunify360 de CloudLinux.
PHP2Shell rappelle une réalité simple : les failles les plus dangereuses ne viennent pas forcément d'attaques sophistiquées. Elles dormaient dans un code vieux de dix ans, et elles ont été trouvées en quelques semaines par un chercheur équipé d'IA. Patcher reste la seule vraie réponse. Les mesures provisoires, les pare-feu, les modes maintenance achètent du temps, pas de la sécurité.