PHP2Shell : deux failles critiques dans le cœur de PHP permettent une exécution de code à distance

Le 21 octobre 2026, l’équipe PHP a publié des mises à jour d’urgence pour corriger « PHP2Shell », deux vulnérabilités critiques nichées dans le moteur même de PHP. Elles permettent à un attaquant non authentifié d’exécuter du code à distance sur un serveur web, avant même que le code de l’application ne s’exécute. Découvertes par Wiz Research avec l’aide de modèles d’IA, elles touchent la quasi-totalité des versions de PHP publiées depuis une décennie. Amazon a observé une tentative d’exploitation quatre jours avant la divulgation publique.

Ce qui s’est passé

Le nom « PHP2Shell » désigne un ensemble de failles de sécurité mémoire signalées par Wiz Research au PHP Security Team le 24 août 2026. Après un correctif coordonné avec les distributions Linux et les éditeurs de support étendu (LTS), PHP a publié ses versions corrigées et deux avis de sécurité le 21 octobre 2026. Selon Wiz, chaque version de PHP publiée au cours des dix dernières années contient au moins l’un de ces défauts, et certains remontent jusqu’à PHP 5.4.

Le contexte rend l’affaire particulièrement sensible : PHP fait tourner une très large part du web, de WordPress à Drupal en passant par Joomla. Or la vulnérabilité ne dépend d’aucune application. Wiz souligne qu’une simple page « Hello World » sur une version affectée peut suffire à exposer le serveur.

Analyse technique

Toutes les variantes ont la même origine : une mauvaise gestion des erreurs fatales, en particulier des erreurs de mémoire insuffisante (OOM), pendant le traitement d’une requête. Une erreur fatale peut laisser derrière elle un état interne corrompu, qu’une requête suivante traitée par le même worker va réutiliser.

CVE-2026-109618 — RCE via corruption lors d’un OOM

PHP utilise longjmp() pour sortir du contexte courant lors d’une erreur OOM. Si cela se produit alors que la mémoire de la requête n’est que partiellement initialisée, la phase d’arrêt peut lire ou exploiter un état invalide. L’avis officiel indique que l’attaque a été validée en HTTP contre mod_php avec les limites par défaut. Le correctif supprime ce chemin longjmp() au profit d’un OOM « souple » différé et d’un arrêt immédiat via _exit() au-delà d’un seuil plus élevé.

CVE-2026-109619 — RCE via un état global périmé

Les workers PHP conservent des états globaux (erreurs, session, objets, extensions) qui peuvent pointer vers la mémoire d’une requête précédente. Si une erreur fatale (OOM ou délai dépassé) interrompt la requête avant leur réinitialisation, la mémoire est libérée mais la référence subsiste : un use-after-free (CWE-416) exploitable par la requête suivante. L’avis confirme l’impact via le chemin des backtraces d’erreur fatale de PHP 8.5 (mod_php) et via la progression d’upload de session (mod_php et PHP-FPM).

Quatre bogues, deux CVE

Wiz décrit quatre bogues regroupés sous ces deux identifiants. Ils ont permis des démonstrations d’exécution de code non authentifiée sur les images officielles wordpress:latest, drupal:latest et joomla:latest, ainsi qu’une fuite de mémoire du worker restituée dans un cookie PHPSESSID, y compris quand l’application n’appelle jamais session_start().

Le rôle de l’IA

Wiz indique avoir utilisé des modèles d’IA de pointe pour la découverte, le développement d’exploits et la validation des correctifs. Selon l’éditeur, un seul chercheur a réalisé en une semaine environ un travail qui aurait demandé des mois à une équipe de haut niveau. Amazon tire la même leçon côté défense : l’analyse assistée par IA rend beaucoup moins coûteuse la transformation d’un correctif ou d’un avis en exploit fonctionnel.

Exploitation dans la nature

Amazon Threat Intelligence rapporte qu’une tentative d’exploitation a visé son réseau de honeypots MadPot le 17 octobre 2026, quatre jours avant la divulgation, depuis une adresse IP liée à un service commercial d’anonymisation. La façon dont l’acteur a obtenu ces informations pendant l’embargo reste inconnue. Le 21 octobre, entre 02:00 et 08:00 UTC, d’autres tentatives aux charges et infrastructures variées suggèrent plusieurs acteurs. Après la publication, de nouvelles preuves de concept sont apparues en quelques heures et ont été utilisées presque immédiatement.

Les requêtes observées sont des POST multipart contenant la chaîne PHP_SESSION_UPLOAD_PROGRESS. Amazon a publié six adresses IP observées, en précisant qu’elles appartiennent à une infrastructure d’anonymisation partagée : elles doivent servir de pistes d’investigation, pas de liste de blocage.

Qui est concerné

Toute organisation qui exécute PHP exposé au web : sites WordPress, Drupal ou Joomla, intranets, applications métiers, back-offices. Le risque est maximal pour Apache avec mod_php, mais PHP-FPM, php-cgi, FrankenPHP et LiteSpeed sont également concernés. Les versions 8.1 et antérieures ne sont plus maintenues par le projet ; des rétroportages minimaux existent pour PHP 7.4, 8.0 et 8.1 pour ceux qui compilent depuis les sources, et certaines distributions ou éditeurs LTS proposent des paquets corrigés.

Le danger le plus durable est la « longue traîne » : installations oubliées, appliances et équipements embarqués qui intègrent PHP sans que leurs exploitants le sachent. Le NCSC britannique demande de mettre hors ligne tout système qui ne peut être corrigé ou protégé rapidement.

Lecture MITRE ATT&CK

Les sources ne fournissent pas de correspondance ATT&CK. Le tableau ci-dessous est une lecture indicative de Defensy, fondée sur les comportements décrits par Amazon.

Recommandations

1. ImmédiatMettre à jour PHP en commençant par l’exposé

   Passez en 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou appliquez le paquet corrigé de votre distribution. Priorisez les serveurs accessibles depuis Internet. Aucune configuration seule ne corrige complètement les deux CVE.

2. ImmédiatMesures temporaires si le correctif attend

   Activez les règles WAF de votre fournisseur (Cloudflare en propose à tous ses clients). Envisagez session.upload_progress.enabled=0 et, sur PHP 8.5, fatal_error_backtraces=0, ou le blocage des uploads multipart après évaluation de l’impact. À défaut, mettez le système hors ligne.

3. ImmédiatInventorier toutes les instances PHP

   Serveurs web, conteneurs, images de base, appliances et services tiers. Utilisez un outil de test comme php2shell-scanner (Searchlight Cyber) sur les hôtes que vous êtes autorisé à tester.

4. Court termeRechercher des traces de compromission depuis le 17 octobre

   Dans les journaux web : POST contenant PHP_SESSION_UPLOAD_PROGRESS, uploads multipart inhabituels suivis d’erreurs de limite mémoire, rafales de HTTP 500, cookies PHPSESSID anormalement longs. Sur l’hôte : processus enfants inattendus du worker PHP, fichiers modifiés, web shells.

5. Court termeSuivre les avis des éditeurs tiers

   Firewalls, passerelles, CMS hébergés : surveillez les bulletins (Palo Alto Networks, Fortinet, Cisco et autres) et appliquez leurs correctifs dès disponibilité.

6. Moyen termeRaccourcir les délais de correctif critique

   Pour les vulnérabilités critiques exposées, mesurez le délai de correction en heures, pas en jours. Développez des détections comportementales qui ne dépendent pas d’une signature de CVE.