PHP2Shell : le trou est dans PHP, pas dans votre thème WordPress

Le 21 octobre 2026, l’équipe de sécurité PHP publie deux avis. Pas un plugin oublié. Pas un thème pirate. Le moteur. Deux identifiants — CVE-2026-109618 et CVE-2026-109619 — notés CVSSv4 9.2 par PHP elle-même. Le surnom qui circule, php2shell, dit le résultat : une requête HTTP, pas de mot de passe, et le worker PHP peut exécuter du code. Ou lire la mémoire du process.

Les chiffres, avant le vocabulaire.

Les chiffres, avec les sources

W3Techs, octobre 2026 : PHP est utilisé par 69,2 % des sites dont le langage serveur est connu. WordPress est sur 39,5 % de tous les sites du web (58,3 % des CMS recensés). Drupal, Joomla, Laravel, Magento, PrestaShop, MediaWiki : même pile. Wiz, qui a participé à la recherche, parle d’un moteur qui « porte 70 % d’internet ». L’ordre de grandeur est le même. Ce n’est pas un CMS de niche.

Côté exposition brute, ce sont des estimations, pas un recensement : un chercheur (Silas Cutler) avance plus de 1,3 million d’hôtes internet potentiellement concernés ; un décompte Shodan cité par Tenable dépasse 1,9 million d’hôtes PHP visibles. Ça ne veut pas dire 1,9 million de compromissions. Ça veut dire que la surface est large, et qu’elle n’attend pas votre prochain comité.

La CISA pousse le patch le jour de l’avis, et inscrit les deux CVE à son catalogue KEV le 26 octobre 2026 — les failles dont l’exploitation en conditions réelles est considérée comme établie. Amazon Threat Intelligence a vu une tentative sur son réseau de leurres dès le 17 octobre, quatre jours avant l’avis public. Ensuite, « de larges tentatives d’exploitation ». Cloudflare parlait déjà d’attaques émergentes le 21, avec un WAF en stopgap.

Le coût, si ça passe : le Cost of a Data Breach 2025 d’IBM (Ponemon) met la moyenne mondiale à 4,44 millions de dollars. La France y figure autour de 3,73 millions. L’exploitation d’une vulnérabilité, dans le même rapport, n’est pas un scénario cheap : 4,24 millions en moyenne. Ce n’est pas le prix d’un WordPress. C’est le prix d’une enquête, d’un arrêt, d’un avocat, d’un run à reconstruire.

• 69,2 % des sites au langage serveur connu tournent en PHP (W3Techs, oct. 2026).
• 9,2 CVSSv4, les deux CVE, note de l’équipe de sécurité PHP — pas un 10.0 fuité par erreur.
• 17 oct. première tentative vue par Amazon TI, avant l’avis du 21.
• 4,44 M$ coût moyen d’une fuite, IBM 2025. La France : ~3,73 M$.

Ce que c’est (et ce que ce n’est pas)

Calif et Wiz décrivent deux défauts dans le runtime, anciens — le chemin incriminé remonte au moins à PHP 5.4. L’un (109618) apparaît quand une allocation dépasse memory_limit : le nettoyage traite comme valides des structures à moitié nées. L’autre (109619) est un état périmé entre deux requêtes du même worker : de la mémoire libérée, encore pointée, plus tard relue. PHP confirme, pour 109619, une divulgation mémoire en plus de l’exécution de code.

Ça vise tout ce qui sert du HTTP en PHP : mod_php, PHP-FPM, php-cgi, FrankenPHP, LiteSpeed. PHP juge le risque le plus haut sur mod_php. Les chercheurs ont montré l’exécution de code, sans authentification, sur des images à jour de WordPress, Drupal et Joomla. Trail of Bits a ensuite confirmé des exploits fonctionnels contre des PHP 8.2 à 8.5 non patchés, y compris MediaWiki, Symfony, Laravel, phpBB. Le CMS n’est pas le bug. Il est le décor.

Les versions corrigées, avis PHP du 21 octobre 2026 : 8.5.12, 8.4.27, 8.3.36, 8.2.35. En dessous (8.1, 8.0, 7.x), plus de release officielle ; des backports source minimaux existent pour 7.4–8.1, à faire coller par l’éditeur de la distro. Windows a eu un second train de builds (Brotli bundlé, autre CVE). Les paquets Debian, Ubuntu, RHEL : lire l’avis du vendeur, pas seulement php.net.

L’impact, concrètement

Sans compte, sans plugin vulnérable, un site PHP internet peut servir de point d’entrée. Le process tourne souvent en www-data ou apache. Ce n’est pas « root » le premier jour. C’est déjà :

• lire des secrets qui traînent en mémoire (jetons, mots de passe de BDD, clés d’API) — Wiz a montré ce volet sans aller jusqu’à l’exécution ;
• poser un implant dans le répertoire web, d’où le nom php2shell ;
• chiffrer, exfiltrer, ou rebondir vers le MySQL, le SMTP, le partage de fichiers que l’appli a le droit de voir ;
• dans des cas rapportés par la presse sécu (Dream Research, 26–28 octobre), enchaîner avec une autre faille système pour viser les privilèges root — y compris sur du matériel exposé. On n’en fait pas une recette ici. On en retient l’idée : le premier shell n’est pas la fin du film.

Pour une ETI, le métier s’arrête quand le front boutique, le Moodle, le PrestaShop ou l’intranet WordPress ne répond plus — ou, pire, répond encore et sert autre chose. Le NHS England a classé la menace haute dès le 21, en rappelant WordPress, Drupal, Joomla comme exemples d’intégration, pas comme exceptions.

Un diagnostic utile, là, ne consiste pas à « pentest le thème ». Il consiste à savoir quelle version PHP sert vraiment en face d’internet, qui la patch, et ce qu’on restaure si on coupe.

Comment une attaque peut se dérouler

Pas un mode d’emploi. Un enchaînement, tel que les avis publics le décrivent.

1. Cible. Un hôte qui parle HTTP et PHP, souvent depuis des années, parfois derrière un hébergeur mutualisé. L’attaquant n’a pas besoin d’un login wp-admin. Il n’a pas besoin que votre plugin soit pourri. Il a besoin que le binaire PHP soit dans la fenêtre d’avant le 21 octobre — ou une branche morte.

2. Contact. Une ou plusieurs requêtes HTTP, non authentifiées. Sur mod_php, PHP dit que ça peut se déclencher avant le code applicatif. Autrement dit : le index.php de WordPress n’a pas encore tranché. Le worker, si.

3. État interne. Selon la CVE, soit une condition mémoire (limite atteinte, structures à moitié initialisées), soit un reste d’une requête précédente dans le même process. Ce n’est pas « un fichier PHP mal uploadé ». C’est le ramasse-miettes du moteur qui se trompe.

4. Résultat. Exécution sous l’identité du worker, ou lecture de ce qui trainait en RAM. Ensuite, dans les observations publiques : un interpréteur lancé depuis le process PHP, des outils téléchargés, parfois un second étage. La CISA demande explicitement de surveiller les workers PHP qui lancent un shell ou téléchargent des outils.

5. Après. Si personne ne regarde les process ni les fichiers de la racine web, l’incident dure. IBM le répète d’une année sur l’autre : le coût suit le temps de détection et de confinement, plus que le nom de la CVE.

Deux précautions, pour les équipes : les « PoC » qui circulent après une fuite d’identifiants CVE sont souvent malveillants pour celui qui les lance. L’équipe PHP a d’ailleurs écrit n’avoir pas vu d’exploit fonctionnel au moment de la publication ; d’autres labos, plus tard, ont confirmé que des chaînes marchaient contre les versions d’avant le patch. Ce n’est pas une invitation à les collectionner. C’est une raison de partir du principe que la fenêtre est ouverte depuis au moins le 17 octobre.

Ce qu’il faut faire (défensif)

Patch. Redémarrage. Inventaire. La CISA est sèche : identifier PHP partout — y compris quand il est noyé dans un produit (firewall, NAS, console d’admin) — et prioriser ce qui fait face à internet. Un WAF aide le temps du train de patch. Il n’est pas le correctif.

Vérifier la version servie, pas celle du laptop du prestataire. phpinfo en prod n’est pas une stratégie ; un en-tête, un paquet, un ticket hébergeur, si.

Les branches mortes (8.1, 7.4 encore visibles chez des éditeurs) : migrer ou appliquer le backport du vendeur. Rester sur une EOL en 2026, ce n’est plus de la dette, c’est un choix.

La sécurité 100 % n’existe pas

On patchera PHP2Shell. Il y en aura une autre. Le moteur a des décennies ; la recherche, désormais, s’appuie aussi sur des modèles pour aller plus loin dans des chaînes que personne n’avait le temps de finir à la main — Calif et Wiz le disent eux-mêmes. Croire qu’un score de scan à jour égale un SI intouchable, c’est exactement le réflexe que ces deux CVE cassent : l’application était « saine ». Le runtime, non.

Donc on ne « se repose » pas sur l’absence de faille. On se repose sur trois choses, un peu moins glamour qu’un bouclier.

Le PRA. Sauvegardes hors du même disque, restaurées pour de vrai dans les douze derniers mois, avec un délai dit à la direction. Qui coupe le DNS. Qui prévient les clients. Un PrestaShop ou un WP restauré en quatre heures, ce n’est pas de la magie : c’est un exercice. Sans ça, le patch du vendredi soir est un espoir.

La détection rapide. Journaux web, process (PHP qui n’a rien à faire d’un interpréteur enfant), intégrité de la racine, sorties réseau inhabituelles. La CISA a déjà écrit la signature métier : worker qui lance un shell, worker qui télécharge. Si personne ne lit ça le week-end, l’attaquant a deux jours d’avance — et IBM vous facture la moyenne.

La veille sur les projets, pas seulement sur « le CMS ». Version PHP du socle, du conteneur, de l’image Docker copiée il y a 18 mois, du module d’un éditeur métier qui embarque sa propre lib. Abonnement aux avis PHP, aux paquets distro, au KEV CISA. Un run SRE un peu sérieux tient ça sans vingt outils. Une TMA qui ne regarde jamais le runtime, elle, vend du cosmétique.

Chez IT Empower, on ne promet pas l’invulnérabilité. On promet un état des lieux : quelle pile, quelle version, quelle sauvegarde, qui est réveillé à 2 h. Si la liste n’existe pas, elle sort d’un diagnostic au forfait. Le livrable n’est pas « vous êtes sûrs ». C’est : voilà ce qui casse, voilà ce qu’on restaure, voilà ce qu’on surveille jusqu’au prochain avis.

PHP2Shell n’invente pas la leçon. Il la facture à ceux qui croyaient que le thème et les plugins suffisaient.