PHP2Shell : comment l'IA a réduit le délai de correction de quelques jours à quelques heures

Qu'est-ce qui, à cette période de l'année, semble favoriser l'émergence d'incidents cyber généralisés et insidieux juste avant les fêtes ? Alors que les professionnels de la sécurité commençaient à peine à oublier les cauchemars liés à Log4J/Log4Shell, voilà qu'une série de failles critiques dans PHP provoque des perturbations massives.

Le 21 octobre, des centaines de sites web ont été mis hors ligne, non pas par des attaquants munis d'exploits, mais de manière proactive par des gouvernements, des entreprises et des organisations afin d'empêcher l'exploitation de ces sites pendant que leurs équipes techniques examinaient et appliquaient les correctifs. La cause : deux failles critiques dans PHP, le langage qui propulse environ 70 % des sites web. Connues sous le nom de PHP2Shell, CVE-2026-109618 et CVE-2026-109619 pourraient permettre à un attaquant non authentifié d'exécuter du code à distance (RCE) sur un serveur, sous certaines conditions.

Les bugs eux-mêmes se situent dans le code C sous-jacent de PHP. S'il est fascinant de se plonger dans les détails techniques de cet incident, l'information majeure est que ce bug de dépassement de mémoire (OOM) n'est pas nouveau : il a été signalé pour la première fois en 2004, puis en 2019, et à nouveau en 2024. Et le point le plus marquant est sans doute de comprendre pourquoi, à l'été 2026, après avoir été ignoré pendant 12 ans, ce même bug OOM est soudainement devenu la priorité absolue pour toute l'équipe de sécurité de la PHP Foundation.

Alors, que s'est-il passé ? L'IA est entrée en jeu.

L'IA a réduit le délai entre la découverte d'un bug et son exploitation

Ces bugs ne sont pas simples à exploiter. Enchaîner ces failles pour créer un vecteur d'attaque fonctionnel exige une compréhension approfondie de la manière dont PHP alloue et réutilise la mémoire entre les requêtes. Les chercheurs en sécurité chevronnés savent que la partie la plus difficile consiste souvent à prouver l'impact : un bug inaccessible ne peut être exploité, et un bug inexploitable ne génère pas assez d'urgence pour justifier une correction, dans un monde où les équipes techniques disposent de ressources limitées et de listes de tâches déjà trop longues.

Ces bugs sont restés sans réponse pendant si longtemps parce que personne ne parvenait à les exploiter. Et comme le correctif était complexe et nécessitait des compromis difficiles entre la rétrocompatibilité, le risque de déni de service (DoS) et des changements impossibles à coordonner avec des extensions tierces, les efforts pour corriger le bug en 2024 ont stagné. Ce scénario semblera familier à toute équipe triant des vulnérabilités : un problème théorique nécessitant une correction coûteuse a tendance à passer après des problèmes ayant un impact clair et prouvé.

Jusqu'à cet été, lorsque le projet PHP a été intégré au programme « Patch the Planet » d'OpenAI. De nouvelles séries d'audits de sécurité assistés par IA sur PHP ont non seulement révélé les bugs, mais ont également permis de créer les preuves de concept (PoC) nécessaires pour prioriser les correctifs. La chronologie de Calif montre moins de 2 semaines entre la découverte d'une voie d'accès au bug et la transmission d'une preuve de concept fonctionnelle à la PHP Foundation. Dans son rapport, Wiz souligne explicitement ce qui a fait la différence : « avec des modèles d'IA de pointe et les bons outils, un seul chercheur a accompli en une semaine ce qui aurait auparavant nécessité des mois de travail pour une équipe de classe mondiale. »

En résumé, à quoi ressemble cette vulnérabilité

Lorsqu'une requête PHP manque de mémoire, PHP interrompt immédiatement le traitement. Cet arrêt brutal entraîne l'omission d'une étape de nettoyage de la mémoire, créant ainsi une vulnérabilité de corruption de mémoire de type « Use After Free ». Au pire moment, PHP peut laisser derrière lui des données internes partiellement initialisées et les traiter ensuite comme valides, corrompant ainsi la mémoire, ou maintenir un état interne pointant vers la mémoire d'une requête précédente.

Transformer ces deux bugs en une attaque fonctionnelle était complexe. Cela nécessitait :

• De provoquer une erreur de dépassement de mémoire à un moment précis, en utilisant une petite requête avec des champs de formulaire profondément imbriqués qui force PHP à allouer beaucoup plus de mémoire que la taille de la requête (Calif)
• De faire en sorte que les données contrôlées par l'attaquant atterrissent dans la mémoire libérée, afin que PHP les lise comme ses propres structures internes (Calif)
• Dans certains cas, d'utiliser une seconde faille pour divulguer le contenu de la mémoire et déterminer l'emplacement des éléments, ce qui neutralise la randomisation des adresses (Wiz)

Si vous souhaitez comprendre les détails techniques de cet exploit, consultez notre démonstration publique PHP2Shell qui explique étape par étape son fonctionnement : [JOUER MAINTENANT]

Un nouveau monde : observer les tentatives d'exploitation en temps réel

Si seulement l'IA n'aidait que les chercheurs en sécurité et les équipes techniques... L'incident PHP2Shell est la première fois que nous constatons réellement le changement radical dans la vitesse à laquelle les attaquants peuvent transformer des divulgations et des correctifs en exploits. Comme des organisations telles qu'AWS et Cloudflare ont été informées à l'avance, elles ont pu surveiller les tentatives d'exploitation dans la nature auprès de leur clientèle. Et puisque PHP est utilisé par environ 70 % des sites web, la surface d'attaque de PHP2Shell est immense.

• Cloudflare a observé des milliers de tentatives d'exploitation de PHP2Shell dans les 10 heures précédant l'annonce publique. Moins de 24 heures après l'annonce, ils suivaient des millions de tentatives d'exploitation.
• Amazon Threat Intelligence a identifié une tentative d'exploitation de PHP2Shell datant du 17 octobre, soit quatre jours avant la divulgation publique. Quelques heures après la publication du correctif, AWS a confirmé avoir observé « de larges tentatives d'exploitation dans la nature ».

Cela indique que les équipes ne peuvent plus compter sur des délais de correction et d'atténuation de 30 jours, ni même de 7 jours. Pour les vulnérabilités critiques, l'utilisation de l'IA a réduit ces délais à quelques heures.

Les points à retenir

Pour les équipes techniques et de sécurité, deux hypothèses doivent être réexaminées.

« Aucune vulnérabilité connue » est une assurance bien moins solide qu'auparavant, car les outils d'IA ont considérablement réduit le coût de création d'exploits. Les anciennes découvertes jugées théoriques méritent d'être réexaminées. Le code est devenu bon marché, et les exploits le sont donc aussi.

Un correctif qui prend des semaines à être déployé fait désormais face à des attaques qui se comptent en heures, ce qui modifie le calcul du retour sur investissement. La prévention proactive devient rapidement la meilleure stratégie d'atténuation des risques. Si vos équipes utilisent des applications basées sur d'anciennes versions de PHP sans correctifs, vous pourriez rencontrer de sérieuses difficultés lors de la mise à jour. Votre dette technique vient de se transformer en un problème de sécurité critique, et cette tendance ne fera que s'accentuer à mesure que les attaquants utilisant l'IA gagneront en efficacité. PHP étant au cœur d'une grande partie de l'infrastructure serveur d'Internet, le déploiement des correctifs s'annonce comme une tâche colossale. Étant donné que cela ne concerne pas seulement les applications web, mais aussi les équipements et pratiquement tous les systèmes et produits exposés à Internet, les équipes de sécurité risquent de faire face à un casse-tête durable. Il est impératif qu'elles restent vigilantes et prêtes non seulement à gérer les vulnérabilités critiques connues, mais aussi à adopter une approche axée sur la sécurité dans chaque aspect du développement logiciel, qu'il soit humain ou généré par IA. [JOUER AU DÉFI] [PARLER À UN EXPERT]