PHP2Shell : pourquoi des sites web du monde entier ont été coupés

Ce qu’est PHP2Shell

PHP2Shell regroupe deux vulnérabilités critiques du langage PHP : CVE-2026-109618 et CVE-2026-109619. Les deux permettent à un attaquant non authentifié d’exécuter son propre code sur un serveur qui fait tourner PHP — autrement dit, d’en prendre le contrôle. Elles portent toutes deux une cote de gravité de 9,2 sur 10, soit la catégorie « critique ».

Ce qui rend l’affaire mondiale, c’est la surface touchée. PHP est le langage serveur le plus répandu du web : il fait tourner près de 70 % des sites. Toutes les installations qui servent des requêtes web sont concernées, et même de vieilles branches non maintenues comme PHP 5 sont affectées.

PHP, en deux minutes

Pour comprendre la faille, il faut distinguer deux choses que le mot « PHP » désigne en même temps. D’abord un langage de programmation. Ensuite un runtime : le moteur qui lit et exécute ce langage, appelé le Zend Engine, et — point crucial — écrit en C.

• Vos fichiers .php contiennent le code source, en texte.
• Le moteur lit ce fichier, le compile en opcodes (un jeu d’instructions interne, pas un .exe) et exécute ces opcodes dans sa machine virtuelle. Rien n’est distribué sous forme de binaire : tout se recompile et s’exécute à la volée, côté serveur.
• Le navigateur ne voit jamais votre code PHP. Il ne reçoit que le résultat de l’exécution : du HTML, ou du JSON pour une API.

Et WordPress dans tout ça ? C’est une application écrite en PHP (un système de gestion de contenu), comme Laravel ou Symfony. PHP est le moteur ; WordPress est la voiture construite autour. C’est pour cela qu’une faille dans PHP touche mécaniquement une immense part du web, WordPress compris.

Le parcours d’une requête, et où frappe la faille

Voici le trajet complet, du dépôt de code jusqu’à l’affichage dans le navigateur. Le point marqué en rouge est l’endroit exact où PHP2Shell opère.

Le point important se lit directement sur le schéma : la faille n’est ni dans la page web, ni dans le code de l’application (ce n’est pas un bogue de WordPress ni d’un développeur). Elle est dans le moteur PHP, à l’étape où l’interpréteur traite la requête, avant même que votre code n’ait son mot à dire.

Comment la faille fonctionne

Ce ne sont pas des failles applicatives classiques (ni injection SQL, ni XSS) : ce sont des bogues de corruption mémoire dans le moteur, le genre de problème qui existe parce que le cœur de PHP est écrit en C, où la mémoire se gère à la main.

• CVE-2026-109618 — corruption par manque de mémoire. Elle se déclenche quand PHP épuise sa mémoire en plein milieu de la préparation d’une requête, laissant des structures internes à moitié construites que le code de nettoyage traite ensuite comme valides.
• CVE-2026-109619 — état résiduel entre requêtes. Un état interne survit à la mémoire de la requête qu’il désignait ; la requête suivante, traitée par le même processus PHP, peut alors agir sur ces données périmées. Typique des serveurs PHP persistants.

Le scénario le plus dangereux est Apache mod_php, où PHP est embarqué directement dans le serveur web : l’attaque peut réussir avant même que le code de l’application ne s’exécute.

Pourquoi tant de sites ont fermé

Trois facteurs se sont combinés en une tempête parfaite :

• Une fuite avant la divulgation. Les détails ont circulé publiquement avant la date prévue. PHP a dû avancer ses correctifs de 24 heures, mais du code d’exploitation était déjà apparu en ligne.
• Une exploitation immédiate. Des tentatives d’attaque réelles ont été observées dès la publication, et par millions en moins de deux jours.
• Aucun contournement fiable. PHP a été clair : aucun changement de configuration ne neutralise complètement ces failles. La seule vraie protection est le correctif.

Devant une RCE non authentifiée, déjà exploitée, sans mitigation possible et touchant potentiellement tout serveur PHP, beaucoup d’organisations ont choisi la seule option sûre en attendant de patcher : débrancher. C’est ainsi que des services gouvernementaux (France, Pays-Bas, Finlande, Danemark, notamment) et de grandes entreprises comme Nintendo ont mis des sites hors ligne temporairement.

Quoi faire maintenant

• Mettre à jour PHP vers 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, selon votre branche, puis redémarrer tous les processus PHP pour que le correctif prenne effet.
• Prioriser l’exposé sur Internet, en commençant par les serveurs qui utilisent Apache mod_php.
• Inventorier chaque serveur et application qui exécute PHP — y compris les vieilles installations oubliées.
• Branches 7.4, 8.0 et 8.1 : passer par un paquet de distribution ou LTS, ou les rétroportages minimaux de PHP. 7.3 et antérieures (dont PHP 5) : aucun correctif, il faut migrer.
• Si un système ne peut pas être corrigé tout de suite, restreindre son accès depuis Internet.

Références

• Avis de sécurité PHP (php.net), 21 octobre 2026 — versions corrigées et détails officiels.
• NVD : CVE-2026-109618 et CVE-2026-109619.
• Alerte du NCSC (Royaume-Uni) sur la faille critique affectant PHP.
• Analyse technique et suivi de l’exploitation : watchTowr Labs, Calif.io.