Le 21 octobre, PHP a publié d'un coup quatre versions de sécurité : 8.5.12, 8.4.27, 8.3.36 et 8.2.35, qui corrigent les vulnérabilités CVE-2026-109618 et CVE-2026-109619, toutes deux notées 9,2 selon le CVSS v4.0. Un attaquant distant non authentifié peut les exploiter, et le pire scénario est l'exécution de code à distance. Dans son avis, le projet indique qu'il n'existe aucune mesure d'atténuation temporaire complète ; la mise à jour est la seule correction réellement définitive.
C'est la société de sécurité cloud Wiz qui a découvert cet ensemble de failles et qui a baptisé l'affaire PHP2Shell. Pendant sa chasse aux failles, l'équipe de recherche de Wiz a utilisé son propre outil Wiz Atlas, ainsi que Gemini 4 Argon de Google et GPT-5.6 Sol d'OpenAI.
Le problème se trouve dans le moteur lui-même
Derrière les deux CVE se cachent quatre défauts au total : un use-after-free dans le désérialiseur de progression des envois, la lecture à distance de la mémoire du processus, un use-after-free dans la trace d'appels des erreurs fatales et une confusion de types (type confusion) dans OPcache. La racine commune tient à la façon dont PHP traite les erreurs fatales, en particulier celles provoquées par un épuisement de la mémoire.
Lorsqu'une requête s'interrompt de manière anormale, des données corrompues subsistent dans l'état interne ; le même processus worker, en traitant la requête suivante, réutilise cet état périmé, d'où des fuites ou une corruption de mémoire. Même sans exécuter de code, un attaquant peut lire mots de passe, jetons et clés d'API dans la mémoire du processus.
La faille se situe dans le moteur de PHP et n'a rien à voir avec le niveau de sécurité de l'application qui tourne par-dessus. Wiz a démontré l'exploitation sur les dernières images de conteneur de WordPress, Drupal et Joomla ; même une page qui n'affiche que Hello World peut être touchée, et la fuite de mémoire fonctionne même si l'application n'a jamais appelé session_start(). Le périmètre remonte jusqu'à PHP 5.4 : chaque version publiée au cours de la dernière décennie tombe sous le coup d'au moins un des problèmes.
Où l'IA a mis la main à la pâte
La chronologie de Wiz : la première faille a été découverte le 19 août, signalée à l'équipe de sécurité de PHP le 24 août, confirmée par PHP le 21 septembre, date à laquelle a commencé la préparation du correctif coordonné, puis rendue publique le 21 octobre. Entre le signalement et la mise en ligne du correctif, il s'est écoulé près de deux mois, dont l'essentiel a été consacré à la correction et à la coordination.
Selon Wiz, Argon est intervenu dans la découverte des failles, l'écriture des exploits, la détection des attaques et la vérification des correctifs ; les grands modèles ont aidé les chercheurs à adapter le code d'exploitation à différentes versions de PHP, configurations et organisations de la mémoire, et, en cas d'échec, à analyser la cause puis à itérer. Les mots exacts de Wiz :
"Frontier AI models substantially reduced that barrier, turning a longstanding flaw into an exploit."
(Les modèles de pointe ont considérablement abaissé cette barrière, transformant une faille ancienne en exploit exploitable.)
Wiz affirme qu'un seul chercheur a accompli en une semaine ce qui demandait autrefois plusieurs mois aux meilleures équipes. OpenAI a également publié un article sur cette divulgation coordonnée ; d'après des articles publics, l'entreprise a aussi mis à disposition une compétence Codex pour aider les sites à vérifier s'ils sont concernés, mais les scénarios précis qu'elle couvre ne peuvent pas, pour l'instant, être vérifiés un par un.
Le casse-tête des vieux sites en Chine
En Chine, un grand nombre de petits et moyens sites, de sites d'entreprise et de forums tournent sous PHP, souvent dans des environnements installés en un clic depuis un panneau d'hébergement, et il n'est pas rare que la version soit restée en 7.x. D'après la liste officielle des versions, les correctifs de cette fois ne couvrent que quatre branches, de la 8.2 à la 8.5 ; la 7.x n'est plus prise en charge depuis longtemps et n'obtiendra pas de correctif officiel, et la 8.2 n'est elle-même maintenue que jusqu'au 31 décembre de cette année.
Pour les sites qui n'ont pas encore migré, Wiz énumère plusieurs signaux à surveiller : des requêtes multipart anormales suivies d'une erreur de dépassement de mémoire, des erreurs HTTP 500 à répétition, des cookies PHPSESSID anormalement volumineux ou mal formés, et des redémarrages anormaux et fréquents des processus worker PHP. Cloudflare, Fastly, Google et d'autres fournisseurs ont déjà déployé des règles de protection, si bien que les sites placés derrière un CDN peuvent en bloquer une partie, mais la conclusion officielle ne change pas : l'affaire n'est réglée qu'une fois le correctif appliqué.
Sources : avis de sécurité officiel de PHP, blog de recherche de Wiz, CocoLoop, avis de sécurité d'OpenAI ; ont été vérifiés les numéros des versions corrigées, les identifiants CVE, les notes CVSS v4.0 et le périmètre des versions concernées.