PHP2Shell : le bug à l'origine de l'une des deux failles était connu depuis 2024

Mercredi 21 octobre, PHP a corrigé deux failles critiques surnommées PHP2Shell, qui mettaient en danger une énorme partie du web.

Dans son bilan de l'affaire, la fondation PHP reconnaît que ses propres développeurs avaient repéré dès 2024 le problème de mémoire à l'origine de l'une d'elles.

Faute de choisir entre plusieurs correctifs, l'équipe de sécurité de PHP a piétiné pendant des mois. Il a fallu que, cet été, des chercheurs aidés par l'IA tirent de ce bug de quoi exécuter du code à distance pour que ce problème devienne enfin une priorité.

De son côté, Amazon a détecté une première tentative d'attaque dès le samedi 17 octobre, soit quatre jours avant la sortie des correctifs. Elle visait l'un de ses honeypots, de faux serveurs exposés sur Internet pour attirer les attaquants.

Jusqu'à votre mise à jour, ces failles permettaient d'exécuter du code à distance, sans authentification, sur toute installation de PHP qui sert des pages web. Un attaquant a néanmoins pu s'en servir sur votre serveur, et le correctif ne fait pas disparaître ce qu'il aurait pu y laisser.

Si vous avez mis PHP à jour mercredi, le travail n'est donc pas tout à fait fini : Amazon conseille de chercher aussi des traces d'attaque d'avant l'annonce.

Un problème de mémoire repéré en 2024

En 2024, PHP a eu droit à son premier audit de sécurité externe depuis des années, mené par la société française Quarkslab.

En corrigeant l'un des points signalés, un développeur du langage est tombé sur les premiers signes du problème de mémoire à l'origine de la première faille, CVE-2026-109618.

Ce bug se déclenche quand une requête pousse PHP au-delà de sa limite de mémoire : il abandonne son travail en plein milieu, puis, au moment de faire le ménage, relit des données internes restées à moitié préparées comme si elles étaient valides.

Un attaquant peut alors s'arranger pour que ces restes contiennent ce qu'il veut, jusqu'à faire exécuter une commande au serveur.

La seconde faille, CVE-2026-109619, joue sur des restes du même genre dans les workers, ces processus que PHP réutilise d'une requête à l'autre. Elle passe notamment par le suivi de progression des envois de fichiers.

En 2024, on ne connaissait encore aucun exploit pour le bug de mémoire. L'équipe de sécurité de PHP a bien préparé plusieurs correctifs, mais chacun avait son revers : casser la compatibilité, rendre les serveurs plus faciles à faire tomber ou obliger à modifier beaucoup d'extensions tierces.

Habituée à décider par consensus, avec peu de développeurs qui maîtrisent le moteur, l'équipe n'a pas réussi à trancher, et le chantier a stagné. La fondation parle elle-même d'une défaillance structurelle.

Si vous avez déjà maintenu du vieux code, vous connaissez ce genre de dilemme, où chaque correctif casse quelque chose ailleurs. Sauf qu'ici, le code en question fait tourner près de 70 % des sites web. 💀

La main dans le pot de miel

La tentative du 17 octobre identifiée par Amazon est tombée dans MadPot, son réseau de honeypots utilisé pour observer les méthodes des attaquants.

Son auteur passait par un service d'anonymisation du genre VPN. Amazon voit dans cette tentative l'œuvre d'un acteur malveillant, sans savoir comment il a pu se renseigner sur des failles encore supposées secrètes, et un porte-parole évoque un cas isolé.

Le mercredi 21, entre 4h et 10h du matin, bien avant la sortie des correctifs à 16h, Amazon a vu passer des exploits venus de plusieurs groupes, à en juger par la variété du code envoyé.

Pour des failles censées rester secrètes, ça faisait pas mal de monde dans la confidence.

Depuis la sortie des correctifs, les tentatives d'attaque se multiplient un peu partout sur Internet, sans qu'Amazon sache encore combien ont réussi chez de vraies victimes, en dehors de ses honeypots.

Trois accrocs à l'embargo

Les failles devaient rester secrètes jusqu'au jeudi 22 octobre à 16h. Ce délai, c'est l'embargo : il laisse aux distributions Linux et à quelques fournisseurs, prévenus à l'avance, le temps de préparer leurs paquets, pour que tout le monde puisse mettre à jour dès l'annonce.

Mardi 20 octobre vers 17h, les deux failles ont fuité sur les réseaux sociaux, sans détail technique. PHP a alors avancé en urgence d'une journée la sortie des correctifs, au mercredi 16h.

Dans la foulée, Calif, l'une des sociétés qui avaient signalé les failles, a publié par erreur une vidéo de son exploit en action (bravo champion). Selon la fondation PHP, les copies de cette vidéo ont accéléré l'écriture d'exploits.

Mercredi à 9h41, plus de six heures avant l'heure prévue, Chainguard, qui fournit des images de conteneurs, a publié ses images de PHP corrigées. Comme les autres distributeurs, il avait reçu le correctif à l'avance.

Il suffisait alors de comparer les binaires de ces images aux anciens pour repérer ce que le correctif changeait, et donc où se cachaient les failles. La fondation reproche à Chainguard d'avoir balayé des semaines de coordination.

Pour Amazon, l'embargo reste le bon modèle, mais il ne protège que jusqu'à ce que quelqu'un d'autre trouve le même bug.

Avec l'IA, transformer un correctif en exploit qui fonctionne coûte de moins en moins cher, et les attaquants peuvent agir dans les heures qui suivent l'annonce d'une faille.

Sur un serveur exposé à Internet, Amazon conseille donc de corriger une faille critique en quelques heures, et non plus en quelques jours.

Mettre à jour, puis fouiller vos journaux

Si ce n'est pas déjà fait, la priorité reste de mettre PHP à jour : aucun réglage de PHP ne suffit à se protéger des deux failles, rappelle Amazon.

En attendant, le CERT-FR conseille de bloquer les envois de fichiers par formulaire. Le plus radical consiste à couper le site, comme l'a fait mercredi le ministère de l'Intérieur pour plusieurs sites institutionnels, à la demande de l'ANSSI.

Reste ensuite à fouiller vos journaux. Mais encore faut-il savoir quoi y chercher.

Selon CrowdStrike, l'attaque ne laisse presque rien : le serveur répond normalement, le worker ne plante pas, et les journaux de l'application restent vides puisque aucune ligne de son code ne s'exécute.

La seule trace est l'erreur fatale de dépassement de mémoire que provoque l'attaque, dans le journal d'erreurs du serveur web (le genre de ligne qu'on a l'habitude d'ignorer). Chez CrowdStrike, elle ressemblait à ceci :

PHP Fatal error:  Allowed memory size of 16777216 bytes exhausted (tried to allocate 3670048 bytes) in Unknown on line 0

Les chiffres dépendent de votre configuration. L'indice à repérer, c'est la fin, in Unknown on line 0 : elle signifie qu'aucun fichier PHP n'était en cours d'exécution.

Pour la seconde faille, Amazon conseille de chercher les envois de formulaire qui contiennent PHP_SESSION_UPLOAD_PROGRESS, le champ qui déclenche le suivi de progression des envois de fichiers.

Et si vous comptez tester vos serveurs avec un exploit trouvé sur GitHub, prudence : JFrog, l'éditeur d'Artifactory, y a repéré de faux exploits, dont un qui remplace votre fond d'écran par une image NSFW.

L'IA trouve les bugs, pas les correctifs

Le 30 juillet, Calif a commencé un audit de PHP dans le cadre de Patch the Planet, le programme d'OpenAI pour corriger les failles des logiciels libres avec l'IA. Le 11 août, l'un des chercheurs de Calif a signalé une faille d'exécution de code à distance due au problème de 2024.

OpenAI est tombé sur la même cause de son côté, et Wiz, filiale de Google, a trouvé d'autres façons de l'exploiter. Trois équipes sur la même piste en quelques semaines, c'est exactement ce scénario qui pose problème Amazon.

Le chercheur de Calif s'est fait aider par l'IA, mais c'est lui qui l'a orientée, en partant d'une vieille faille de PHP de 2004. Aucun modèle ne déterre tous les bugs avec de simples prompts, du moins pour l'instant, écrit-il.

La recherche assistée par IA multiplie aussi les signalements : depuis le 1er juillet, l'équipe de sécurité de PHP a publié 15 CVE et écarté plus de 100 faux rapports, entre erreurs, doublons et bugs impossibles à reproduire.

Pour la fondation, les outils trouvent les bugs plus vite que jamais, mais aucun ne sait décider correctement de la manière de corriger un vieux choix de conception du moteur, ni évaluer pleinement ce qu'un correctif va casser.

Il faut pour cela des ingénieurs qui comprennent en détail le fonctionnement du moteur de PHP, et ils sont trop peu nombreux : le travail de sécurité sur PHP repose encore sur une poignée de développeurs payés par la fondation et un peu d'aide bénévole.

Pour mettre PHP à jour, la marche à suivre est détaillée dans notre guide publié mercredi, et les versions corrigées (8.5.12, 8.4.27, 8.3.36 et 8.2.35) sont disponibles sur php.net.

Si votre boîte repose sur le langage, la fondation est toujours à la recherche de sponsors.