php2shell : la faille qui menace environ 70 % du web, expliquée simplement

PHP fait tourner environ 70 % des sites dont on connaît le langage serveur (W3Techs, cité par Tenable et Infosecurity Magazine), dont WordPress, Drupal, Joomla ou Magento. Le 21 octobre 2026, le projet PHP a publié un avis de sécurité critique : deux vulnérabilités, CVE-2026-109618 et CVE-2026-109619, surnommées php2shell, notées 9,2 sur 10 (CVSS v4.0). Elles permettent d'exécuter du code sur un serveur sans aucun mot de passe.

En clair : que se passe-t-il ?

Un serveur PHP traite les visites avec des « workers » qui réutilisent la même mémoire d'une requête à l'autre. Les deux failles viennent de la façon dont PHP gère les erreurs graves, surtout le manque de mémoire. Dans le premier cas, PHP est interrompu alors que les données de la requête ne sont qu'à moitié préparées, et le nettoyage les traite comme si elles étaient valides. Dans le second, un reste de la requête précédente survit après la libération de sa mémoire, et la requête suivante, sur le même worker, s'en sert. Un attaquant peut exploiter ces erreurs pour faire exécuter ses propres commandes au serveur, avec les droits du worker web.

Wiz Research, qui a trouvé les failles, détaille quatre bugs distincts :

Les failles sont dans PHP lui-même, pas dans les applications : d'après Wiz, même une application « Hello World » sur une version touchée peut être vulnérable. L'exécution de code à distance sans authentification a été démontrée contre les dernières images conteneur de WordPress, Drupal et Joomla.

Qui est touché ?

Toutes les installations PHP qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP et LiteSpeed. mod_php est le plus exposé : une démonstration montre qu'une seule requête peut déclencher l'attaque avant l'exécution du moindre code de l'application (Rapid7, PHP). Les versions concernées remontent jusqu'à PHP 5.4, selon Wiz et Google Cloud. Silas Cutler estime à plus de 1,3 million le nombre d'hôtes exposés potentiellement vulnérables, sur plus de 1,9 million d'hôtes PHP visibles sur Shodan (chiffres rapportés par Tenable).

Les conséquences se voient déjà. Selon Patchstack, les services néerlandais DigiD et MijnOverheid ont été mis hors ligne par précaution, et plusieurs services japonais sont passés en maintenance d'urgence. Un abus mémoire peut aussi servir à voler des mots de passe et des clés sans exécuter de code, ce qui oblige à renouveler les secrets d'un serveur suspect.

La chronologie

La date de divulgation était prévue le 21 octobre à 14 h GMT. Un utilisateur de Hacker News a publié les identifiants le 20 octobre, avec une note de gravité de 10 qui sera ramenée à 9,2 dans l'avis officiel (Infosecurity Magazine). Amazon ignore comment l'auteur de la tentative du 17 octobre a obtenu ces informations alors que les failles étaient sous embargo.

Exploitation : ce qui est établi, ce qui ne l'est pas

Amazon estime que php2shell est exploitée à grande échelle et recommande d'enquêter à partir du 17 octobre. Cloudflare et watchTowr signalent des attaques, y compris des tentatives de contournement de ses protections. En revanche, l'équipe PHP n'avait trouvé aucun exploit fonctionnel à la publication, la télémétrie de Patchstack ne montrait que des sondages sans preuve d'intrusion au moment de sa mise à jour, et les codes de démonstration qui circulent ne sont pas vérifiés. Wiz explique que l'IA a beaucoup simplifié la mise au point de la chaîne d'attaque, qui demandait auparavant un travail complexe.

Les versions corrigées

Les paquets des distributions Linux peuvent garder un numéro plus ancien à cause des rétroportages : vérifie l'avis de ton fournisseur, et vérifie aussi que le PHP qui sert réellement les pages est celui que tu as mis à jour (php -v peut afficher une autre installation, avertit Qualys).

Que faire ?

Mettre à jour reste le seul remède complet. La CISA demande d'inventorier tous les systèmes PHP, y compris dans les conteneurs et les logiciels qui embarquent PHP, de traiter d'abord ceux exposés à Internet, et de mettre hors ligne ceux qu'on ne peut pas corriger. Le NCSC britannique donne la même consigne. Si une mise à jour immédiate est impossible, PHP propose des réglages provisoires qui réduisent l'exposition sans rendre le système sûr :

Il ne faut pas utiliser RLIMIT_AS ni RLIMIT_DATA, qui peuvent déclencher justement l'allocation vulnérable. Les règles WAF de Cloudflare ne sont qu'un palliatif, utile seulement si le serveur n'accepte du trafic que par Cloudflare.

Signes d'une tentative selon Wiz et Patchstack : des requêtes multipart inhabituelles suivies d'erreurs de limite mémoire ou de réponses HTTP 500, des cookies PHPSESSID anormalement gros ou mal formés, et des workers PHP qui redémarrent sans explication. Sur un serveur suspect, il faut le considérer comme compromis et renouveler les identifiants qu'il détient.

Sources

Avis officiel de PHP, alerte CISA, alerte NCSC, Wiz Research, Rapid7, Qualys, Google Cloud, Patchstack, Tenable, Help Net Security, Infosecurity Magazine.

Visuels : Wiz Research.