PHP2Shell : l'IA a trouvé la faille avant les attaquants, la course au patch commence

Le mercredi 21 octobre 2026, le projet PHP a publié en urgence les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Elles corrigent deux vulnérabilités du moteur lui-même, CVE-2026-109618 et CVE-2026-109619, qui permettent une exécution de code à distance sans authentification¹. Selon Greg Brockman, président d'OpenAI, le code fautif était là depuis quatorze ans². Des chercheurs équipés de modèles frontier ont montré qu'il était exploitable, puis aidé à le corriger. L'affaire a reçu un nom, PHP2Shell, celui du site de divulgation commun. Pour toute équipe qui exploite du PHP, la priorité est de mettre à jour aujourd'hui.

Ce qui s'est passé

Le 1er août 2026, selon la chronologie publiée par Sansec, Calif identifie plusieurs chemins d'exécution de code dans PHP³. OpenAI précise que Calif travaillait avec GPT-5.6 Sol dans le cadre de son programme Patch the Planet⁴. Calif signale le premier bug à l'équipe de sécurité PHP le 11 août³. De son côté, Wiz Research trouve le problème le 19 août avec son outil Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol, confirme une RCE non authentifiée sur Drupal le 20 août puis sur WordPress le 21, et transmet ses rapports le 24 août ; PHP en accuse réception le 21 septembre⁵. OpenAI indique avoir piloté pendant deux mois une coalition de mainteneurs, de chercheurs et de fournisseurs de sécurité, en lien avec la « Super Intelligence Force » de la Maison Blanche, l'Office of the National Cyber Director (ONCD), la CISA et des partenaires internationaux⁴.

La divulgation coordonnée visait le 22 octobre, selon la FAQ de Tenable⁶. Le calendrier a dérapé le 20 : des détails ont fuité, et une capture d'écran, puis une vidéo d'un outil d'exploitation, ont circulé⁶. Le soir même, PHP publiait un préavis annonçant une release pour le 21 octobre à 14h00 UTC (16h00 à Paris), pour deux vulnérabilités notées 9.2 en CVSS v4.0¹. Le 21, le CERT-EU publiait son avis 2026-018 en relevant que de premières preuves de concept circulaient déjà⁷. Cloudflare a activé des règles WAF pour ses clients à partir de 3h02 UTC, neuf heures avant la divulgation publique, et a observé du trafic d'attaque vers ses clients⁸ ; à 7h43 UTC, son CTO Dane Knecht signalait de premières attaques⁹. Les versions corrigées sont sorties vers 13h30 UTC, en avance sur l'horaire annoncé, selon le CERT-EU⁷. Le CERT-FR a publié dans la journée l'alerte CERTFR-2026-ALE-014¹⁰.

Par précaution, des organisations ont coupé des services avant le correctif. The Record rapporte que des centaines de sites ont été mis hors ligne : plusieurs gouvernements ont fermé certains sites avant la publication du patch, de même que Nintendo et d'autres grandes organisations¹¹.

Deux failles, un même défaut de conception

L'équipe PHP note les deux CVE 9.2 en CVSS v4.0¹. Les deux relèvent de la sécurité mémoire et partagent une racine : la façon dont PHP gère une erreur fatale, un dépassement de mémoire en particulier, au milieu du traitement d'une requête⁵. Pour s'arrêter net quand une requête dépasse memory_limit, PHP saute hors du code en cours (un longjmp) sans dérouler le nettoyage habituel.

CVE-2026-109618 (« RCE via OOM corruption », GHSA-w8hw-w9fx-j79w) exploite ce moment : l'interruption peut survenir alors que des données internes de la requête ne sont qu'à moitié initialisées, par exemple pendant l'analyse d'un envoi multipart, et le nettoyage les traite ensuite comme valides¹.

CVE-2026-109619 (« RCE via stale global state », GHSA-6wmf-4rv5-p3rp) concerne un état interne qui survit à la libération de sa mémoire : la requête suivante traitée par le même worker peut le réutiliser avant sa réinitialisation. Les chemins confirmés par PHP passent par session.upload_progress et, en PHP 8.5, par les backtraces d'erreurs fatales¹.

Une image aide : un employé interrompu en plein classement part sans ranger, et son successeur se fie à des fiches qui pointent vers des tiroirs déjà vidés, puis remplis par quelqu'un d'autre. Si l'attaquant est ce quelqu'un d'autre, il écrit la suite.

Wiz a démontré une RCE avant authentification sur les images Docker officielles wordpress:latest, drupal:latest et joomla:latest, ainsi qu'une fuite de mémoire du worker : des fragments issus d'autres requêtes sont renvoyés dans le cookie PHPSESSID⁵. Sansec rapporte des RCE non authentifiées confirmées sur Magento 2.4.9 et dix autres applications, dont WordPress, Drupal, Joomla, MediaWiki, Nextcloud, phpMyAdmin, Roundcube, Laravel et Symfony³. L'équipe PHP juge le risque le plus élevé sur mod_php, avec un exploit démontré où une requête non authentifiée déclenche l'attaque avant l'exécution de tout code applicatif¹. Une application irréprochable reste donc vulnérable si l'interpréteur l'est.

Qui est concerné

Selon l'advisory PHP, toutes les installations qui servent des requêtes web : PHP-FPM, Apache avec mod_php, php-cgi, FrankenPHP, LiteSpeed¹. Wiz fait remonter l'exposition à PHP 5.4⁵, et le CERT-FR liste les branches 5.x, 6.x, 7.x, 8.0.x et 8.1.x comme affectées, l'éditeur n'en assurant plus le support¹⁰.

Cela touche WordPress, Drupal, Joomla, Magento, MediaWiki, Nextcloud, les applications Laravel ou Symfony, les consoles d'hébergement et une foule d'outils internes³. Wiz et OpenAI reprennent l'estimation d'environ 70 % des sites web⁵⁴ ; selon W3Techs, au 21 octobre 2026, PHP sert 69,3 % des sites dont le langage côté serveur est connu¹². Un autre chiffre inquiète davantage : selon Joviane Jardim (Detectify), cité par The Record, environ la moitié des sites PHP tournent sur des versions plus anciennes que celles qui reçoivent un correctif¹¹. C'est une estimation, mais elle décrit le problème.

L'IA a ouvert une « Defender's Window »

OpenAI emploie l'expression « Defender's Window » : à sa connaissance, l'IA frontier a trouvé ces vulnérabilités avant les attaquants, ce qui a laissé deux mois aux mainteneurs et aux fournisseurs pour préparer correctifs et protections⁴. Anthropic suit une logique voisine avec Project Glasswing, qui réserve l'accès de ses modèles Mythos aux défenseurs et aux éditeurs de logiciels critiques.

Le défaut avait déjà laissé des traces. Selon Greg Brockman, le bug était présent dans PHP depuis quatorze ans ; une version limitée en avait été repérée en 2024 sans être jugée significative, et l'équipe d'OpenAI en a trouvé une version plus complète en septembre². Il manquait la capacité à transformer une anomalie en exploit fiable : enchaîner plusieurs bugs, adapter l'attaque à chaque version, configuration et disposition mémoire, déboguer, recommencer. Wiz résume l'effet des modèles : « a single researcher completed in a week what previously would have taken a world-class team months of work » (un seul chercheur a fait en une semaine ce qui aurait demandé des mois à une équipe de tout premier plan)⁵. Wiz crédite Gemini 4 Argon d'une contribution « invaluable » à la découverte, au développement de l'exploit, à la détection des attaques et à la validation du patch, et classe ces failles « among the most severe vulnerabilities discovered in PHP »⁵.

Calif tient un discours plus mesuré, rapporté par The Next Web : sa découverte initiale s'est faite avec des modèles accessibles à tous, sans harnais particulier, et la connaissance de l'historique de PHP a pesé autant que le modèle¹³. L'IA a accéléré un expert qui savait où chercher.

La même accélération vaut pour l'attaquant. Au 21 octobre en fin d'après-midi, aucune exploitation réussie n'était confirmée. Jake Knott, responsable du renseignement sur les menaces chez watchTowr, observait des tentatives d'exploitation avec des preuves de concept « vibecoded with the help of AI » : « Whilst nobody has been successful to date, we don't expect that will last long » (personne n'a réussi à ce jour, mais nous ne pensons pas que cela dure)¹¹. À 13h57 UTC, Patchstack ne voyait dans sa télémétrie que des attaques de sondage, sans preuve d'intrusion¹⁴ ; à 14h04 UTC, le catalogue KEV de la CISA ne listait aucune des deux CVE¹⁵. Sansec s'attend à une exploitation de masse maintenant que le correctif et les analyses sont publics³ : comparer l'ancien et le nouveau code pour retrouver la faille devient l'affaire de quelques heures. OpenAI écrit que ces bugs sont « among several significant vulnerabilities we've already found and are working to fix », et s'attend à ce que des découvertes similaires « increase sharply in the coming months »⁴.

Ce que cela change pour les équipes

La fenêtre entre divulgation et exploitation se compte en heures. Le cycle mensuel de patch, avec recette complète avant production, ne suffit plus pour les composants exposés à internet. Il faut une procédure d'urgence écrite et répétée, et un inventaire capable de répondre en quelques minutes à la question : où tourne PHP chez nous, et en quelle version ? Les serveurs oubliés sont les plus dangereux.

La dette de versions devient un risque immédiat. PHP 8.1 et les versions antérieures ne sont plus maintenues¹. D'après les statistiques publiques de WordPress.org relevées le 21 octobre 2026, environ 36 % des sites WordPress tournent sur une version de PHP antérieure à 8.2, que le projet ne corrige plus, dont 16 % en PHP 7.4¹⁶. Le projet PHP a publié à titre exceptionnel des backports minimaux pour 7.4, 8.0 et 8.1, à compiler depuis les sources¹ : un dépannage, qui ne remplace pas la migration. PHP 8.2 atteint sa fin de support de sécurité le 31 décembre 2026¹⁷. Chaque application restée sur une branche non supportée sera difficile à corriger à temps la prochaine fois.

Le WAF fait gagner du temps, sans plus. Les règles déployées par Cloudflare, Akamai et d'autres filtrent le trafic qui passe par eux et couvrent les vecteurs connus⁵⁸. Cloudflare les présente lui-même comme une mesure de défense en profondeur⁸, et Dane Knecht écrivait le matin du 21 : « This is a STOPGAP only. Patch as soon as @ThePHPF releases the update » (ce n'est qu'un palliatif, patchez dès la sortie de la mise à jour)⁹.

L'IA doit entrer dans la boucle de défense. Si les attaquants s'en servent pour exploiter vite, les équipes doivent s'en servir pour inventorier, prioriser, tester les montées de version et auditer leur propre code avant que d'autres ne le fassent. C'est le terrain de l'AISecOps, où le modèle qui a trouvé la faille sert aussi à la détecter et à valider le correctif, comme Wiz l'a fait avec Gemini 4 Argon⁵.

À faire aujourd'hui

1. Mettre à jour vers PHP 8.5.12, 8.4.27, 8.3.36 ou 8.2.35, ou installer le paquet corrigé de votre distribution. L'équipe PHP renvoie vers les paquets des distributions et déconseille de compter sur le dépôt bénévole rpms.remirepo.net pour une mise à jour le jour même¹.
2. Redémarrer tous les workers (PHP-FPM, Apache) : un paquet à jour sur disque ne protège pas tant que les anciens processus servent les requêtes.
3. Pour PHP 8.1 et antérieures : isoler les systèmes exposés, comme le recommande le CERT-FR¹⁰, appliquer un correctif d'éditeur ou les backports 7.4, 8.0 et 8.1¹, et planifier la migration.
4. Si la mise à jour est impossible dans l'heure, appliquer les mesures partielles listées par PHP : session.upload_progress.enabled=0 dans php.ini ou la configuration du pool FPM (pas via ini_set() ni .user.ini), puis redémarrage ; sur PHP 8.5, fatal_error_backtraces=0 ; memory_limit=-1 imposé via php_admin_value, avec une limite cgroup comme garde-fou (pas RLIMIT_AS ni RLIMIT_DATA), en sachant qu'un échec d'allocation peut encore atteindre le chemin vulnérable ; un post_max_size bas (8M sans upload, 32M sinon) et des limites de taille et de nombre de parts au niveau du proxy ; supprimer les réglages invalides ou dépréciés appliqués par requête, et corriger les erreurs fatales ou dépassements de délai qu'un attaquant peut provoquer¹. Le CERT-FR suggère de bloquer, ou au minimum de superviser, les requêtes dont le Content-Type est multipart, et précise que ces contournements ne sont pas qualifiés¹⁰. Aucune de ces mesures ne rend une installation sûre.
5. Surveiller les requêtes multipart inhabituelles suivies d'erreurs mémoire ou de séries de réponses 500, les cookies PHPSESSID d'une longueur inhabituelle et les redémarrages inexpliqués de workers. En cas de doute, traiter le serveur comme compromis : renouvellement des secrets et analyse forensique.

Le point de vue de SFEIR

PHP2Shell est le premier incident de cette ampleur où les deux faces de l'IA en sécurité apparaissent le même jour. Des chercheurs équipés de modèles frontier ont trouvé et aidé à corriger un défaut vieux de plus de dix ans avant son exploitation à grande échelle. Les mêmes capacités servent à transformer un correctif public en exploit en quelques heures.

Pour les DSI et les RSSI, la leçon est pragmatique. La complexité d'un bug ne protège plus. La « Defender's Window » existe, et elle se referme à la publication du correctif ; en profitent les organisations qui savent ce qu'elles exploitent, gardent leurs versions dans le support et ont industrialisé le patch d'urgence. C'est le travail que nous menons avec nos clients, inventaire, priorisation et migration des versions obsolètes, avec l'IA dans la boucle. Le correctif est disponible depuis 13h30 UTC : la priorité de cet après-midi est de l'installer.

Ils ont réagi

• Greg Brockman, président et cofondateur d'OpenAI, dans son article X « Towards securing the internet », lié depuis son tweet du 21 octobre : « I believe we're entering a new phase of cybersecurity, where the models are able to find vulnerabilities with internet-scale impact. » (nous entrons dans une nouvelle phase de la cybersécurité, où les modèles trouvent des vulnérabilités à l'échelle d'internet)²
• Dane Knecht, CTO de Cloudflare, à 7h43 UTC, avant la publication du patch : « PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show up. »⁹
• ANSSI, à 13h59 UTC : « Une mise à jour de PHP a été publiée. Elle corrige deux vulnérabilités critiques dont l'exploitation rapide est à craindre. »¹⁸

Sources

1. PHP, archives des annonces 2026 : préavis du 20 octobre (release annoncée le 21 à 14h00 UTC, deux vulnérabilités CVSS v4.0 9.2) et annonce de sécurité du 21 octobre (versions 8.5.12, 8.4.27, 8.3.36, 8.2.35 ; CVE-2026-109618 « RCE via OOM corruption » et CVE-2026-109619 « RCE via stale global state » ; backports 7.4, 8.0, 8.1 ; SAPI concernées ; mitigations ; rpms.remirepo.net) — php.net, 20 et 21 octobre 2026.
2. Greg Brockman (@gdb), tweet du 21 octobre 2026 à 14h58 UTC et article X « Towards securing the internet » qu'il référence (bug présent depuis quatorze ans, version limitée repérée en 2024, version plus complète trouvée en septembre, « new phase of cybersecurity ») — x.com, 21 octobre 2026.
3. Sansec, « PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) » (chronologie : Calif le 1er et le 11 août ; RCE confirmées sur Magento 2.4.9 et dix autres applications ; attaques précoces à 07h43 UTC ; exploitation de masse attendue) — sansec.io, 21 octobre 2026.
4. OpenAI, « Patch the Planet: global response coordination as agents uncover critical vulnerabilities » (Calif et GPT-5.6 Sol, coalition de deux mois, Super Intelligence Force, ONCD, CISA, « Defender's Window », « increase sharply ») — openai.com, 21 octobre 2026.
5. Wiz Research, « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet » (découverte du 19 août avec Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol ; Drupal, WordPress, rapport du 24 août, accusé de réception du 21 septembre ; RCE pré-authentification sur les images Docker officielles ; fuite mémoire dans PHPSESSID ; exposition depuis PHP 5.4 ; 70 % des sites) — wiz.io, 21 octobre 2026.
6. Tenable, « php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ » (date de divulgation initialement prévue le 22 octobre, fuite du 20 octobre) — tenable.com.
7. CERT-EU, Security Advisory 2026-018 « Critical Vulnerabilities in PHP » (correctifs publiés le 21 octobre à 13h30 UTC, preuves de concept en circulation) — cert.europa.eu, 21 octobre 2026.
8. Cloudflare, « Cloudflare deploys protections against php2shell vulnerability » (règles WAF depuis 03h02 UTC, neuf heures avant la divulgation ; trafic d'attaque observé ; « defense-in-depth mitigation » ; divulgateurs Calif.io, Wiz, OpenAI et Quarkslab) — blog.cloudflare.com, 21 octobre 2026.
9. Dane Knecht (@dok2001), CTO de Cloudflare, tweet — x.com, 21 octobre 2026, 07h43 UTC.
10. CERT-FR, alerte CERTFR-2026-ALE-014 « Multiples vulnérabilités dans PHP » (versions 5.x à 8.1.x affectées et hors support ; isolement ; session.upload_progress.enabled = Off ; blocage ou supervision des requêtes multipart ; contournements non qualifiés) — cert.cyber.gouv.fr, 21 octobre 2026.
11. The Record, « Hundreds of websites taken offline as concern grows over two PHP vulnerabilities » (sites gouvernementaux et Nintendo hors ligne ; propos de Jake Knott, watchTowr, et de Joviane Jardim, Detectify) — therecord.media, 21 octobre 2026.
12. W3Techs, « Usage statistics of PHP for websites » (69,3 % des sites dont le langage côté serveur est connu) — w3techs.com, relevé du 21 octobre 2026.
13. The Next Web, « PHP rushes out emergency patches for two critical bugs AI found first » (propos de Calif sur ses outils : source secondaire, la page de Calif n'ayant pu être consultée) — thenextweb.com.
14. Patchstack, « Major security alert: PHP vulnerable to critical RCE, attacks ongoing » (mise à jour de 13h57 UTC : attaques de sondage, aucune preuve d'intrusion) — patchstack.com, 21 octobre 2026.
15. CISA, catalogue Known Exploited Vulnerabilities, version 2026.10.21 publiée à 14h04 UTC (aucune des deux CVE listée) — cisa.gov, 21 octobre 2026.
16. WordPress.org, statistiques publiques des versions de PHP des sites WordPress (7.4 : 16,13 % ; versions antérieures à 8.2 : 36,4 % cumulés) — api.wordpress.org, relevé du 21 octobre 2026 à 16h UTC.
17. PHP, « Supported Versions » (PHP 8.2 : support de sécurité jusqu'au 31 décembre 2026) — php.net, consulté le 21 octobre 2026.
18. ANSSI (@ANSSI_FR), tweet — x.com, 21 octobre 2026, 13h59 UTC.