PHP2Shell : derrière le « 70 % d'Internet » de Wiz, quatre failles démontrées sous deux CVE

Le 21 octobre 2026, PHP a publié un correctif pour deux failles critiques du moteur du langage. Wiz a titré son billet : « AI uncovers critical RCE vulnerabilities affecting 70% of the Internet ». Le chiffre a circulé seul, souvent sans le contexte.

Le texte de Wiz est plus précis que son titre. Il détaille quatre cas exploitables, regroupés sous deux CVE, avec des démonstrations sur WordPress, Drupal et Joomla. Les « 70 % » apparaissent ailleurs, dans une phrase qui décrit la part de PHP sur le web. Ce n'est pas une mesure des serveurs vulnérables.

Cette différence compte pour qui doit prioriser ses correctifs. Elle compte aussi pour juger ce que l'épisode révèle des outils d'IA de recherche de failles. Nous séparons ici ce qui est démontré de ce qui relève de l'estimation.

Nous avons croisé le billet de Wiz avec trois autres sources : Tech Insider, Brandefense et TuxCare. La page d'OpenAI sur la divulgation coordonnée renvoyait une erreur 404 lors de notre consultation. Nous ne lui attribuons donc rien qu'elle ne nous ait pas permis de lire.

Ce que dit le titre de Wiz, et ce que dit son texte

Le titre de Wiz associe trois éléments : l'IA, l'exécution de code à distance et « 70 % d'Internet ». Le résumé du billet précise la formule. Wiz écrit que PHP est « un langage généraliste qui alimente 70 % de tous les sites web du monde ». Le chiffre décrit la place de PHP, pas la proportion de sites exploitables.

Tech Insider reprend la même statistique. Le média écrit que PHP traite le code côté serveur d'environ 70 % des sites et applications web, « selon des chiffres cités dans la divulgation ». Aucune des sources ne fournit de mesure indépendante de cette part. Elle reste une estimation d'usage, reprise d'un texte à l'autre.

Le lien avec l'exposition réelle est plus ténu qu'il n'y paraît. Wiz affirme que chaque version de PHP publiée depuis dix ans est touchée par au moins l'une des failles, jusqu'à la 5.4. Mais une version touchée n'est pas un site exploitable. Cela dépend de la version exacte, de la façon dont PHP est exécuté et du correctif appliqué.

Un nom qui ne désigne pas la même chose partout

Le nom « PHP2Shell » est lui-même flottant. Wiz l'emploie pour le script d'exploitation qui combine les failles. Brandefense, citant Sansec, indique que c'est le nom d'un outil vu sur une capture d'écran qui avait fuité, attribué à Calif.IO. Tech Insider écrit que les deux vulnérabilités sont « collectivement surnommées PHP2Shell par au moins l'une d'elles », ce qui laisse entendre qu'une seule porterait ce nom.

Pour la suite, nous parlons de deux CVE : CVE-2026-109618 et CVE-2026-109619.

Ce qui est démontré : deux CVE, quatre cas

Wiz explique que toutes les failles sont des problèmes de sûreté mémoire. Elles viennent de la façon dont PHP gère les erreurs fatales en traitant une requête, en particulier les erreurs de mémoire insuffisante. Un état interne corrompu peut subsister après l'interruption d'une requête. Une requête ou un worker ultérieur le réutilise, ce qui provoque une divulgation ou une corruption de mémoire.

Voici le tableau de Wiz, reformulé.

Identifiant	Défaut	Ce que Wiz a démontré
CVE-2026-109618	Use-after-free dans le désérialiseur de progression d'envoi	Exécution de code avant authentification sur WordPress, Drupal et Joomla
CVE-2026-109618	Divulgation de mémoire du processus à distance	Divulgation de la mémoire des workers PHP, indépendante de l'application
CVE-2026-109619	Use-after-free dans la trace d'une erreur fatale	Exécution de code avant authentification sur Drupal
CVE-2026-109619	Confusion de type dans OPcache	Exécution de code avant authentification sur WordPress

Cela fait quatre cas exploitables. Wiz reconnaît d'ailleurs que son billet « ne couvre que quatre instances » et qu'il existe d'autres variantes, suivies ou non. Selon Wiz, le correctif de l'équipe PHP traite le problème à la racine et élimine toutes les variantes de la version corrigée.

Ce que les démonstrations prouvent

Wiz a combiné les failles dans un seul script, php2shell. L'éditeur affirme avoir obtenu une exécution de code à distance sans authentification sur les images de conteneur wordpress:latest, drupal:latest et joomla:latest, dans leur état au moment des tests. Ces CMS servent de cibles représentatives. Selon Wiz, l'exploitation ne dépend pas du CMS, puisque le code vulnérable est dans PHP.

Il s'agit de démonstrations de laboratoire, publiées par l'éditeur lui-même. Les sources que nous avons lues ne contiennent pas de reproduction indépendante de ces exploits sur des serveurs en production.

Une description qui varie selon les sources

Les sources ne découpent pas les failles de la même façon. Dans le tableau de Wiz, le défaut de progression d'envoi relève de CVE-2026-109618. TuxCare, qui s'appuie sur les avis de PHP, décrit CVE-2026-109618 comme une corruption liée aux erreurs de mémoire insuffisante, qui passe par longjmp() pour abandonner la requête.

TuxCare place la progression d'envoi du côté de CVE-2026-109619, un use-after-free qui traverse plusieurs requêtes. Les deux billets décrivent le même schéma général, mais ils ne rattachent pas le composant au même identifiant. Pour une correspondance exacte, il faudra se reporter aux avis officiels de PHP.

Photo : Chris Ried sur Unsplash

Versions touchées et correctifs

Wiz indique que PHP a publié son correctif le 21 octobre 2026 et que presque toutes les versions sont concernées. TuxCare précise les numéros : PHP a corrigé les failles dans les versions 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tech Insider ne cite que la 8.5.12.

Brandefense, dont l'article a été écrit avant la publication, rappelait que PHP n'avait encore indiqué ni versions touchées ni versions corrigées. Ce billet permet de mesurer l'écart entre l'avant et l'après : l'incertitude sur les branches a disparu avec la sortie du correctif.

Les branches abandonnées restent sans correctif amont

TuxCare souligne que les avis de PHP couvrent les quatre branches maintenues, mais que l'outil ayant fuité prétend fonctionner jusqu'à la 5.4.0. Les branches 8.1, 8.0, 7.x et 5.x ne reçoivent rien de php.net. Mallory aurait compté environ 884 000 hôtes exposés à Internet qui annoncent l'une de ces versions, selon TuxCare.

TuxCare vend un service de support pour ces versions abandonnées. L'éditeur a donc un intérêt commercial à mettre ce chiffre en avant. Il décrit la situation mais ne doit pas être pris comme une mesure neutre.

Le mode d'exécution change la gravité

Selon TuxCare, la façon d'exécuter PHP compte. Apache avec mod_php est le pire cas pour les deux failles. PHP-FPM tue un processus enfant quand l'initialisation de la requête échoue, ce qui bloque la séquence d'erreur mémoire la plus directe. PHP le considère pourtant comme vulnérable. L'équipe a confirmé une exécution de code complète contre mod_php avec les limites par défaut, et validé un chemin contre PHP-FPM.

Une même version de PHP peut donc être plus ou moins facile à exploiter selon la configuration. Un chiffre global ne rend pas compte de cela.

Exposition réelle : ce que les chiffres mesurent

Tech Insider cite Censys. Environ 1,5 million des 2,6 millions d'hôtes que Censys surveille exécutaient encore une version non corrigée dans les heures qui ont suivi la publication du correctif. Le média en tire un écart de près de 60 %.

Le dénominateur est celui des hôtes surveillés par Censys, pas celui d'Internet ni celui des sites PHP. Le chiffre mesure le retard de correction après une publication. Il ne mesure ni la part de sites exploitables ni la part de sites compromis.

Trois chiffres circulent donc sous un même titre : 70 % pour l'usage de PHP, près de 60 % de retard sur un échantillon Censys, 884 000 hôtes sous des branches abandonnées. Chacun répond à une question différente. Aucun ne dit combien de serveurs sont réellement vulnérables, et aucun n'est indépendamment vérifié dans nos sources.

Le score de gravité

L'équipe de sécurité de PHP note les deux failles 9,2 en CVSS v4.0, selon Brandefense et TuxCare. Wiz parle d'une gravité allant jusqu'à 9,2. TuxCare précise qu'un score de 10,0 avait circulé avec la fuite, mais qu'il n'a jamais été celui de PHP.

Ce détail illustre le problème. Entre la rumeur et l'avis officiel, les chiffres ont bougé. Mieux vaut s'en tenir aux avis publiés.

Exploitation en cours ? Ce qui est confirmé

La chronologie est confuse. Selon Brandefense, un message de Hacker News signalait le 20 octobre deux divulgations PHP à venir, avant d'être retiré. PHP a alors annoncé une publication pour le 21 octobre à 14 h UTC. TuxCare raconte que la fuite a fait perdre un jour à l'embargo.

Sur l'exploitation, les sources divergent. Brandefense, avant la publication, ne relevait aucune exploitation observée : Huntress n'en voyait pas chez ses clients et aucune des deux CVE n'figurait dans le catalogue KEV de la CISA. Sansec, cité par le même article, prévoyait des attaques de masse dans les quinze minutes suivant la publication. Brandefense précise que c'est une prévision, pas une mesure.

TuxCare rapporte que le directeur technique de Cloudflare, Dane Knecht, a signalé des tentatives d'attaque précoces à 7 h 43 UTC le 21 octobre, avant la publication. On ignore combien ont réussi. Tech Insider écrit qu'un rapport évoque une exploitation déjà commencée, sans confirmation indépendante.

On peut donc retenir des tentatives signalées par un acteur de poids, sans mesure de leur succès.

Les mesures avant correction

Les sources s'accordent sur un point : seule la mise à jour règle le problème. TuxCare cite Gina Banyard, de l'équipe cœur de PHP, qui affirme que le correctif est la seule atténuation. Désactiver la progression d'envoi bloque le chemin de session démontré, mais pas les autres chemins du cycle de vie. Après la mise à jour, il faut redémarrer chaque worker PHP, car l'ancien code continue de répondre tant que le processus existe.

Wiz remercie Automattic, Akamai, AWS, Cloudflare, Fastly, Google, Imperva, Microsoft et Vercel pour des mesures d'atténuation prêtes à l'emploi destinées aux clients qui ne peuvent pas corriger tout de suite.

Photo : Agence Olloweb sur Unsplash

Ce que l'épisode dit des outils d'IA de recherche de failles

Le titre de Wiz met l'IA en avant. Le texte précise son rôle : les modèles de pointe ont rendu pratique la construction de l'exploit. Wiz explique qu'il fallait chaîner plusieurs failles et s'adapter à la disposition mémoire de chaque cible, par des tests et du débogage répétés. L'éditeur affirme avoir développé et adapté des exploits fonctionnels sur plusieurs applications « en quelques heures ».

Wiz ajoute que démontrer l'exploitabilité exigeait une chaîne d'étapes « à la limite de ce que des chercheurs humains pouvaient réaliser ». Ce sont des affirmations de l'éditeur, sans mesure indépendante dans nos sources. L'éditeur juge aussi ces failles parmi les plus graves de PHP, voire « de l'histoire du logiciel ». C'est une appréciation, pas un constat.

Qui a trouvé quoi

Selon Tech Insider, qui cite OpenAI, Calif a identifié la faille en juillet 2026 avec l'aide d'un modèle d'OpenAI. Le média précise qu'OpenAI n'a pas nommé le modèle dans les comptes rendus publics, et refuse de deviner. Wiz aurait trouvé des vulnérabilités dans PHP de son côté, avant de rejoindre l'effort coordonné. Wiz remercie l'équipe PHP, Calif et OpenAI pour la découverte, la coordination et la vérification du correctif.

Tech Insider mentionne aussi un programme d'OpenAI qui ouvre ses modèles à des entreprises de cybersécurité pour la recherche de vulnérabilités. Il le décrit comme faisant « apparemment » partie de la genèse de PHP2Shell, ce qui reste à confirmer.

La page d'OpenAI : ce que nous n'avons pas pu lire

Wiz renvoie vers un billet d'OpenAI sur la divulgation coordonnée de vulnérabilités critiques. Lors de notre consultation, cette page affichait une erreur 404. Nous ne pouvons donc pas rapporter ce que l'entreprise y dit de son rôle, de ses outils ou du calendrier. Les éléments sur OpenAI ci-dessus viennent de Wiz et de Tech Insider, pas du billet d'OpenAI lui-même.

Ce qu'on peut en conclure, et ce qu'on ne peut pas

L'épisode montre qu'au moins deux équipes ont trouvé des failles dans la même base de code en quelques mois, avec l'IA. Il ne dit pas combien de failles l'IA a trouvées seule, ni ce qu'un chercheur expérimenté aurait mis de temps à y parvenir. Nos sources ne donnent aucune comparaison chiffrée entre approche humaine et approche assistée.

La vraie question, posée par Wiz, est celle de la complexité comme barrière. Si le temps et l'expertise nécessaires baissent, une faille difficile à exploiter devient plus dangereuse en pratique. C'est une hypothèse que l'épisode illustre, pas une loi démontrée. Pour une lecture comparable d'un rapport dont les titres vont plus vite que les mesures, voyez notre analyse du rapport d'Anthropic sur l'IA auto-réplicante. Côté développeurs, notre comparatif Cursor et GitHub Copilot et notre test d'OpenAI Codex Micro replacent ces assistants dans le quotidien du code.

Points clés à retenir

• Le « 70 % » du titre de Wiz décrit la place de PHP sur le web, pas la part de serveurs vulnérables.
• Wiz démontre quatre cas exploitables, regroupés sous CVE-2026-109618 et CVE-2026-109619.
• Les démonstrations portent sur des images de conteneur WordPress, Drupal et Joomla. Elles émanent de l'éditeur, sans reproduction indépendante dans nos sources.
• PHP a publié les correctifs le 21 octobre. D'après TuxCare : 8.5.12, 8.4.27, 8.3.36 et 8.2.35.
• Les branches 8.1 et antérieures n'ont pas de correctif amont. Mallory compterait environ 884 000 hôtes concernés, chiffre repris par un vendeur de support.
• Le chiffre Censys (1,5 million sur 2,6 millions d'hôtes surveillés) mesure un retard de correction, pas une exposition globale.
• La gravité retenue par PHP est 9,2 en CVSS v4.0. Le 10,0 de la rumeur n'était pas le sien.
• Les tentatives d'attaque sont signalées par Cloudflare, mais leur succès n'est pas établi.
• Le billet d'OpenAI était inaccessible (404) lors de notre consultation.

FAQ

PHP2Shell touche-t-il vraiment 70 % d'Internet ?

Pas au sens où le titre le suggère. Le texte de Wiz dit que PHP alimente 70 % des sites web du monde. Il ne dit pas que 70 % des sites sont vulnérables. Les sources ne contiennent aucune mesure indépendante de la part de serveurs exploitables.

Combien de failles Wiz a-t-il réellement démontrées ?

Quatre cas exploitables, regroupés sous deux CVE : CVE-2026-109618 et CVE-2026-109619. Wiz précise qu'il existe d'autres variantes, suivies ou non, que le correctif de PHP élimine selon lui.

Quelles versions de PHP faut-il installer ?

D'après TuxCare, les versions corrigées sont 8.5.12, 8.4.27, 8.3.36 et 8.2.35. Tech Insider cite la 8.5.12. Après la mise à jour, il faut redémarrer tous les workers PHP. Vérifiez les numéros dans les avis officiels de PHP.

Que faire si j'utilise PHP 7 ou 8.1 ?

PHP ne publie pas de correctif pour ces branches. Les options citées par les sources : migrer vers une branche maintenue, appliquer un correctif rétroporté par votre distribution ou votre hébergeur, ou retirer le serveur d'Internet. TuxCare propose aussi des builds payants pour les versions abandonnées.

Désactiver la progression d'envoi suffit-il ?

Non. Selon TuxCare, cela bloque le chemin de session démontré mais pas les autres chemins du cycle de vie. Les avis de PHP désignent la mise à jour comme seule mesure complète ou fiable.

L'IA a-t-elle trouvé ces failles toute seule ?

Les sources ne le disent pas. Calif a utilisé un modèle d'OpenAI pour assister ses chercheurs en juillet, selon OpenAI rapporté par Tech Insider. Wiz affirme que des modèles de pointe ont rendu la construction de l'exploit praticable en quelques heures. La part respective de l'humain et de l'IA n'est pas chiffrée.

Conclusion

Le billet de Wiz établit des faits solides : deux CVE, quatre cas démontrés, un correctif publié le 21 octobre, des branches abandonnées sans correctif amont. Le « 70 % » du titre décrit l'ampleur de l'écosystème PHP, pas celle de la vulnérabilité. Et sur le rôle exact de l'IA, une partie des preuves reste à lire, puisque la page d'OpenAI était inaccessible.

Pour les équipes techniques, la marche à suivre est simple : inventorier chaque installation PHP, corriger les branches maintenues, traiter à part les branches abandonnées, puis redémarrer les workers.

Retrouvez nos autres analyses dans la catégorie Code et développement et, pour une autre lecture critique de chiffres annoncés, notre article sur le rapport d'Anthropic sur l'IA auto-réplicante.

---

Sources : PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet · Coordinated disclosure of critical vulnerabilities page inaccessible, erreur 404 · AI Finds PHP2Shell Flaw Hitting 70% of the Web 2026 · PHP2Shell: Two Critical PHP Flaws Reported as RCE, CVE-2026-109618 and CVE-2026-109619 · TuxCare Patches php2shell for the PHP Versions Upstream Left Behind

Photo de couverture : Albert Stoynov sur Unsplash