Le 21 octobre 2026, à 14 h UTC, le projet PHP a publié quatre versions corrigées de son langage et une phrase rare : « il n'existe aucune mesure de contournement complète, la mise à jour est le seul choix sûr ». Dans les heures qui ont suivi, des ministères européens ont mis des sites hors ligne, la NSA a publié un avertissement, Cloudflare a compté des millions de tentatives d'attaque. Et une manchette s'est installée partout : l'intelligence artificielle a trouvé une faille qui menace 70 % d'Internet.
De là à lire que « l'IA a créé le problème », il n'y a qu'un pas, et beaucoup l'ont franchi. Ce décodage reprend sept affirmations qui circulent depuis le 20 octobre et les confronte aux sources primaires : les deux avis de sécurité officiels, le billet de la PHP Foundation, l'analyse de Wiz Research, le billet de Cloudflare, l'alerte du CERT-FR. Verdict par verdict.
PHP2Shell, l'essentiel en six lignes
Deux failles, pas une. CVE-2026-109618 et CVE-2026-109619, notées 9,2 sur 10, permettent d'exécuter du code sur un serveur sans mot de passe. Corrigées le 21 octobre 2026 dans PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
Quatorze ans d'ancienneté. Le code fautif remonte à PHP 5.4, sortie en mars 2012. Il a été écrit par des humains, bien avant que les modèles d'IA existent sous leur forme actuelle.
Un premier signal en 2024. Un développeur du cœur de PHP a aperçu le problème pendant l'audit externe de Quarkslab. Aucun moyen d'attaque concret n'a été trouvé à l'époque, et la correction a calé par manque de ressources.
L'IA a trouvé et prouvé. À l'été 2026, trois équipes (Calif, OpenAI, Wiz) ont repéré les failles avec des modèles d'IA et démontré qu'elles étaient exploitables sur WordPress, Drupal et Joomla.
Verdict : l'IA n'a pas créé la faille, elle a rendu visible et exploitable un défaut vieux de quatorze ans. Le vrai problème est en amont : un logiciel qui sert sept sites sur dix et dont la sécurité repose sur une poignée de personnes.
Ce qui s'est passé, dans l'ordre
Les dates ci-dessous viennent du billet de la PHP Foundation du 21 octobre, de l'analyse de Wiz Research et du suivi horodaté de la firme Sfeir. Elles ne concordent pas toujours avec les récits de presse, qui mélangent souvent la date de découverte et la date de signalement.
- Mars 2012 Sortie de PHP 5.4.0, la plus ancienne version où les chercheurs retrouvent le chemin de code vulnérable.
- 2024 Premier audit de sécurité externe de PHP depuis des années, mené par Quarkslab, organisé par OSTIF et financé par l'agence allemande Sovereign Tech Agency. En corrigeant un point soulevé par l'audit, un développeur du cœur de PHP aperçoit les premiers signes du problème de mémoire. Un exploit est jugé possible en théorie, aucun vecteur concret n'est trouvé.
- Début 2026 Le programme Alpha-Omega passe le code de PHP au crible avec le modèle Claude Mythos d'Anthropic, selon la PHP Foundation. En mai, la fondation crée une équipe de sécurité de l'écosystème.
- 30 juillet 2026 La firme Calif commence un audit de PHP dans le cadre du programme Patch the Planet d'OpenAI, avec le modèle GPT-5.6 Sol.
- 11 août 2026 Calif signale à PHP une exécution de code à distance inconditionnelle, de même cause racine que le problème aperçu en 2024. OpenAI signale la même cause racine de son côté. La correction devient la priorité numéro un.
- 19 au 24 août 2026 Wiz Research trouve la première faille le 19, confirme une prise de contrôle de Drupal le 20 et de WordPress le 21, envoie ses rapports le 24.
- 18 septembre 2026 OpenAI signale des vecteurs d'attaque supplémentaires. Le 21, PHP accuse réception des rapports de Wiz et coordonne la correction.
- 20 octobre 2026 Les identifiants CVE fuient en ligne vers 15 h UTC, avec une fausse note de 10 sur 10. PHP publie sa préannonce plus tôt que prévu et avance la sortie du 22 au 21 octobre.
- 21 octobre 2026 Cloudflare active ses protections à 3 h 02 UTC. À 7 h 41, l'éditeur Chainguard rompt l'embargo en publiant des images contenant le correctif. À 14 h, PHP 8.5.12, 8.4.27, 8.3.36 et 8.2.35 sortent. Dans la soirée, Cloudflare compte des millions de tentatives.
Sept affirmations au crible
1. « L'IA a créé la faille PHP »
Le code vulnérable existe depuis PHP 5.4.0, publiée en mars 2012. Il a été écrit, relu et maintenu par des développeurs humains pendant quatorze ans. Les deux avis officiels décrivent des défauts d'architecture classiques : une sortie brutale du programme quand la mémoire manque (un appel longjmp() qui laisse la mémoire d'une requête à moitié initialisée) et un pointeur d'état global qu'un processus garde d'une requête à l'autre sans le remettre à zéro. Rien de tout cela n'a été généré par un modèle. Wiz écrit noir sur blanc que « le code vulnérable était là depuis plus d'une décennie ».
Ce qui est nouveau, c'est la découverte. Confondre les deux, c'est reprocher au thermomètre la fièvre.
2. « L'IA a découvert la faille »
Vrai, avec deux précisions. D'abord, ce sont des équipes humaines qui ont cherché, choisi les cibles et rédigé les rapports : Calif avec GPT-5.6 Sol, Wiz avec son outil Wiz Atlas, Gemini 4 Argon et GPT-5.6 Sol, OpenAI de son côté. Les modèles ont fait le travail qu'un humain seul ne pouvait plus faire à cette échelle. Wiz parle d'un enchaînement d'exploitation « à la limite de ce que des chercheurs humains pouvaient pratiquement accomplir » et d'un seul chercheur qui a bouclé en une semaine ce qui aurait pris des mois à une équipe de haut niveau.
Ensuite, le tout premier signal n'est pas venu d'une IA : un développeur du cœur de PHP avait repéré le problème de mémoire en 2024, sans réussir à en faire une attaque. L'IA a transformé un soupçon de 2024 en démonstration de 2026.
3. « La faille date de 2004 »
Cette date circule dans quelques articles, probablement parce que PHP 5 est sorti en 2004. Aucune source primaire ne la soutient. Wiz et Calif, qui ont analysé le code, remontent à PHP 5.4.0, c'est-à-dire mars 2012. Le président d'OpenAI, Greg Brockman, parle de « quatorze ans », ce qui donne le même point de départ. Le CERT-FR liste bien toutes les branches 5.x comme touchées, mais par prudence : ces versions ne sont plus analysées ni corrigées depuis longtemps.
La bonne formulation est « depuis 2012, soit plus de dix ans ». Le fond de l'argument tient : le défaut a traversé quatre générations majeures de PHP sans que personne ne le voie.
4. « 70 % d'Internet est en danger »
Le chiffre vient du titre du billet de Wiz et il repose sur la part de marché de PHP mesurée par W3Techs : 70,2 % des sites web dont le langage serveur est connu, au 8 septembre 2026. Trois nuances. « Sites web » n'est pas « Internet » : les applications mobiles, les services bancaires, les plateformes vidéo tournent en grande partie sur d'autres technologies. Un site PHP mis à jour le 21 octobre n'est plus en danger. Et une partie des sites ne sont pas joignables par le chemin d'attaque décrit.
Reste un noyau dur bien réel : Censys compte environ 2,6 millions d'hôtes qui annoncent PHP, dont 1,5 million sur une version qui ne recevra jamais de correctif du projet. Ceux-là sont le vrai danger, et ils le resteront des mois.
5. « Des millions de sites ont déjà été piratés »
Des millions de tentatives, oui. Matthew Prince, patron de Cloudflare, a décrit des dizaines de milliers de tentatives en 45 minutes, des centaines de milliers en deux heures, des millions au soir du 21 octobre. Amazon Web Services a parlé d'une exploitation « large » et a vu des tentatives avant même la divulgation publique.
Des intrusions réussies, c'est autre chose. Au 21 octobre à 16 h 30 UTC, la PHP Foundation ne connaissait aucun exploit fonctionnel au-delà des démonstrations qui circulaient, Patchstack ne voyait que des sondes et le catalogue des failles exploitées de la CISA ne listait aucun des deux identifiants. La firme Sansec, elle, avait reproduit une exécution de code sur Magento 2.4.9 et dix autres applications, et s'attendait à une exploitation massive maintenant que la méthode est publique. Au moment d'écrire, la bonne lecture est : attaques en cours, bilan inconnu, fenêtre qui se referme pour les sites qui patchent et qui s'ouvre pour les autres.
6. « C'est l'IA qui attaque »
Les millions de tentatives comptées par Cloudflare sont lancées par des scripts, comme à chaque faille médiatisée depuis vingt ans. Ce qui change, c'est la vitesse : la méthode d'exploitation est devenue publique en même temps que le correctif, et Cloudflare a vu les attaquants faire muter leurs charges pour contourner les filtres dans les heures suivantes. Les modèles d'IA abaissent le coût de ce travail d'adaptation pour tout le monde. La PHP Foundation le dit sans détour : « les outils trouvent désormais les bogues plus vite que jamais, pour les défenseurs comme pour les attaquants ». L'IA n'est pas l'attaquant, elle est l'outil des deux camps.
7. « Sans l'IA, on aurait été tranquilles »
La faille était là. Un défaut exploitable à distance, sans mot de passe, dans le logiciel qui sert sept sites sur dix, finit toujours par être trouvé. La question n'est pas si, mais par qui. OpenAI résume sa version ainsi : « à notre connaissance, l'IA de frontière a trouvé ces vulnérabilités avant les attaquants ». C'est une affirmation d'intéressé, impossible à vérifier, mais l'alternative est pire : un acteur criminel ou étatique qui trouve la même chose en silence et l'exploite pendant des années.
Et le vrai raté n'est pas technologique. La PHP Foundation reconnaît que le délai entre le signal de 2024 et la correction de 2026 a été « un échec structurel, causé à la fois par le processus de décision de l'équipe de sécurité et par son manque de ressources ». L'IA n'a pas créé ce manque de ressources. Elle l'a rendu impossible à ignorer.
Le vrai problème : sept sites sur dix reposent sur une équipe minuscule
Lisez le billet de la PHP Foundation du 21 octobre comme un aveu. L'audit de 2024, premier audit externe depuis des années, avait été limité aux composants les plus critiques faute de budget. Il a trouvé 27 problèmes, dont 17 touchant la sécurité, et tous ont été corrigés. Mais le soupçon né pendant ces corrections est resté en suspens pendant deux ans : les approches de correction se contredisaient, l'équipe fonctionnait par consensus, et très peu de personnes connaissaient assez le moteur pour trancher. Deux ans, pour le logiciel derrière WordPress, Drupal, Joomla, Magento et une bonne part du commerce en ligne.
La fondation annonce des changements : décisions à la majorité, intervention plus rapide de la direction, et surtout un appel aux entreprises, aux hébergeurs, aux distributions et aux gouvernements pour financer des ingénieurs qui connaissent le code en profondeur. Le financement de l'audit de 2024 venait d'une agence publique allemande. C'est à ce niveau que se joue la suite, pas dans les modèles d'IA.
Ce que ça change pour vous
Si vous ne gérez aucun site
Rien à installer, rien à mettre à jour chez vous : la faille vit sur les serveurs. Le risque est indirect. Wiz a montré qu'une des failles peut faire fuir des morceaux de mémoire du serveur dans un simple cookie, et donc des mots de passe, des jetons de session ou des clés d'accès appartenant à d'autres visiteurs. Si un service que vous utilisez vous annonce un incident, prenez-le au sérieux. Les réflexes sont ceux de toute brèche : un mot de passe différent par service, l'authentification à deux facteurs, et de la méfiance devant les courriels qui vous pressent d'agir, car les vagues d'hameçonnage suivent toujours ce genre d'actualité.
Si vous gérez un site, petit ou grand
Vérifiez la version de PHP qui sert votre site. Les versions sûres sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35, ou plus récentes. Si vous êtes chez un hébergeur mutualisé, c'est lui qui tient PHP : demandez-lui par écrit quelle version tourne et depuis quand. Si la réponse commence par 7 ou par 8.0 ou 8.1, la seule issue est de migrer vers une version maintenue, ou de compter sur les correctifs rétroportés de votre distribution Linux. Les mesures de contournement publiées par PHP (limiter la mémoire, bloquer les envois de fichiers, désactiver le suivi des téléversements de session) réduisent le risque sans l'éliminer, et PHP le dit lui-même.
L'IA n'a pas créé la faille. Elle a mis fin à quatorze ans de silence.
Mythe : l'IA aurait fabriqué le problème, la faille daterait de 2004, des millions de sites seraient déjà tombés, et sans ces modèles nous serions tranquilles.
Réalité : un défaut d'architecture écrit par des humains en 2012, aperçu par un humain en 2024, démontré avec des modèles d'IA en 2026, corrigé le 21 octobre, attaqué dans l'heure. Les chiffres spectaculaires (70 %, des millions) sont vrais mais mesurent autre chose que ce que les titres laissent croire.
La leçon n'est pas « méfiez-vous de l'IA ». C'est « regardez qui finance la sécurité des logiciels sur lesquels tout le monde s'appuie ». Quand sept sites sur dix dépendent d'une fondation qui qualifie elle-même son fonctionnement d'échec structurel, le thermomètre n'est pas le problème.
FAQ
Qu'est-ce que PHP2Shell ?
L'IA a-t-elle créé la faille PHP ?
La faille existe-t-elle depuis 2004 ou depuis 2012 ?
Qui a découvert les failles ?
Des sites ont-ils déjà été piratés ?
Suis-je concerné si je ne gère aucun site ?
Que doit faire la personne qui gère un site ?
- PHP.net, avis de sécurité du 21 octobre 2026 : versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35
- Avis officiel GHSA-w8hw-w9fx-j79w, CVE-2026-109618 (exécution de code via corruption en manque de mémoire)
- Avis officiel GHSA-6wmf-4rv5-p3rp, CVE-2026-109619 (exécution de code via état global périmé)
- PHP Foundation, « Today's PHP Security Release, and How We're Strengthening PHP Security », 21 octobre 2026
- PHP Foundation, résultats de l'audit de sécurité Quarkslab (OSTIF, Sovereign Tech Agency), 10 avril 2025
- Wiz Research, « PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet », 21 octobre 2026
- Cloudflare, « Cloudflare deploys protections against php2shell vulnerability », 21 octobre 2026
- Sfeir, fiche PHP2Shell : chronologie horodatée, versions, mesures de contournement, état d'exploitation
- Fortune, 21 octobre 2026 : déclarations de Cloudflare, d'AWS et de Greg Brockman
- Al Jazeera, 22 octobre 2026 : avertissement de la NSA, sites gouvernementaux hors ligne en Europe
- Calcalist/CTech, 21 octobre 2026 : chiffres Censys (2,6 M d'hôtes, 1,5 M sans correctif)
- ActuIA, 22 octobre 2026 : ANSSI, ministère de l'Intérieur, alerte CERTFR-2026-ALE-014
- W3Techs, part de marché de PHP parmi les sites dont le langage serveur est connu
- Clubic, 21 octobre 2026 : couverture en français
Note. Cet article décrit la situation telle que documentée par les sources ci-dessus au 22 octobre 2026. Le bilan des attaques évolue d'heure en heure ; les versions corrigées et les mesures officielles sont celles publiées par le projet PHP. Dernière mise à jour : 22 octobre 2026.