PHP2Shell : deux failles PHP critiques, un embargo qui a fuité, et ce que l'on sait réellement de l'exploitation
PHP a livré des correctifs d'urgence pour deux failles critiques d'exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, appelées PHP2Shell.
PHP a livré des correctifs d'urgence pour deux failles critiques d'exécution de code à distance, CVE-2026-109618 et CVE-2026-109619, appelées PHP2Shell. La version a été publiée le 21 octobre 2026. L'épisode explique les deux bogues de mémoire en termes simples, pourquoi un indice d'un audit de 2024 a attendu un correctif, comment l'embargo a été divulgué, et quelles sources disent quoi sur l'exploitation. Il couvre également la publication d'un correctif critique le même jour par GitLab et une ordonnance de pénalité de 25 milliards de dollars contre Meta au Nouveau-Mexique.
Lire l'édition écrite (anglais) ↗
Ce que couvre cette vidéo
- Les deux failles sont évaluées à 9.2 sur CVSS v4.0 par l'équipe PHP. Les versions corrigées sont PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12 ; PHP 7.4, 8.0 et 8.1 n'ont reçu que des correctifs source. PHP affirme que la mise à jour est la seule atténuation complète.
- La première faille provient du fait que PHP laisse une requête à moitié construite lorsqu'il manque de mémoire au mauvais moment. La seconde provient d'un pointeur résiduel vers la mémoire d'une requête que la requête suivante dans le même worker peut utiliser. Sur Apache avec mod_php, le premier chemin s'exécute avant le code de l'application.
- Un développeur principal de PHP a trouvé les premiers signes du problème de mémoire lors d'un audit en 2024. La Fondation PHP affirme que les correctifs concurrents avaient des compromis et qu'une équipe de sécurité basée sur le consensus a eu du mal à choisir, ce qu'elle qualifie d'échec structurel.
- La Fondation indique que les identifiants CVE ont fuité le 20 octobre, Calif a publié par erreur une vidéo de preuve de concept, et Chainguard a publié des images construites avec le correctif plus de six heures avant la publication. Le PDG de Chainguard affirme que des personnes étaient déjà touchées et qu'il a trouvé les bogues de manière indépendante.
- Les sources ne sont pas d'accord sur l'exploitation. Amazon a enregistré une tentative le 17 octobre et a déclaré plus tard que PHP2Shell était largement exploité. watchTowr a signalé une exploitation en cours. CISA n'avait pas observé d'exploitation au moment de la publication, et l'équipe PHP n'a trouvé aucun exploit fonctionnel lors de la publication. De nombreux scripts de preuve de concept publics sont signalés comme ne fonctionnant pas.
- Vérifiez tous les emplacements où PHP s'exécute, y compris les copies à l'intérieur d'autres logiciels, mettez à jour, redémarrez les workers et examinez les journaux jusqu'au 17 octobre.
Questions et réponses
Quelles sont les deux vulnérabilités PHP2Shell ?
PHP2Shell désigne deux failles PHP critiques, CVE-2026-109618 et CVE-2026-109619, toutes deux évaluées à 9.2 par l'équipe PHP. La première laisse une requête à moitié construite lorsque PHP manque de mémoire au mauvais moment, et le nettoyage lui fait alors confiance. La seconde laisse un pointeur vers la mémoire d'une requête que la requête suivante dans le même worker peut utiliser. Les deux peuvent mener à l'exécution de code sans connexion.
Quelles versions de PHP ont un correctif pour PHP2Shell, et qu'en est-il des versions non prises en charge ?
Le projet PHP a publié des correctifs dans les versions 8.2.35, 8.3.36, 8.4.27 et 8.5.12 le 21 octobre. Pour les versions 7.4, 8.0 et 8.1, il n'a publié que des correctifs source, et BleepingComputer rapporte que les distributions et les fournisseurs de support à long terme peuvent fournir des correctifs rétroportés. PHP affirme qu'il n'y a pas de solution de contournement complète, donc la mise à jour ou la demande d'un paquet corrigé à un fournisseur est le seul choix sûr.
Pourquoi un bogue de mémoire PHP connu a-t-il pris jusqu'en octobre 2026 pour être corrigé ?
La Fondation PHP déclare qu'un développeur principal a trouvé les premiers signes du problème de mémoire lors d'un audit de sécurité en 2024, mais aucune voie d'exploitation n'était connue et chaque correctif candidat avait des compromis tels que des ruptures de compatibilité. L'équipe de sécurité décide par consensus et a eu du mal à choisir, ce que la Fondation appelle un échec structurel causé par son processus de décision et son manque de ressources.
PHP2Shell est-il exploité, et est-il facile à exploiter ?
Les sources divergent. Amazon a enregistré une tentative d'exploitation le 17 octobre et a ensuite déclaré que PHP2Shell était largement exploité, et watchTowr a signalé une exploitation en cours. CISA n'avait pas observé d'exploitation au moment de la publication, et l'équipe PHP n'a vu aucun exploit fonctionnel lors de la publication. watchTowr affirme que la plupart des scripts d'exploit publics plantent ou ne font rien, et VulnCheck a constaté que l'exécution de code ne fonctionne que dans certaines configurations.
Quel a été le verdict de The Daily Diff sur PHP2Shell ?
Le verdict de The Daily Diff était SHIP IT : déployez la mise à jour PHP ce soir, car la nouvelle version est le seul correctif complet. CISA conseille d'inventorier chaque système exécutant PHP, y compris les copies à l'intérieur d'autres logiciels, d'appliquer le correctif et de mettre les systèmes PHP hors ligne s'ils ne peuvent pas être mis à jour. Amazon conseille d'examiner les journaux jusqu'au 17 octobre, date à laquelle il a vu la première tentative.
Transcription traduite
Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.
Qui a tenté PHP2Shell quatre jours à l'avance ?
0:00 Un embargo de sécurité est censé garder un bogue secret jusqu'à ce que le correctif soit publié. Amazon a enregistré une tentative contre le bogue critique de PHP quatre jours à l'avance. Dans cette vidéo, qui l'a trouvé ? Comment l'embargo a-t-il fuité ? Et à quel point c'est grave, vraiment ? Et l'entreprise blâmée pour la fuite a une défense que je n'attendais pas. J'y reviendrai. Nous sommes le jeudi 22 octobre, et voici The Daily Diff.
0:21 PHP est un langage de script qui construit des pages web sur le serveur juste avant qu'elles ne vous parviennent. Il a plus de trente ans et, selon une estimation, il fait fonctionner environ soixante-dix pour cent des sites web, y compris WordPress et le logiciel qui est derrière Wikipédia. Les développeurs adorent s'en moquer, généralement depuis une page que PHP leur sert. Son entretien est une organisation à but non lucratif avec environ treize ingénieurs.
Quels sont les deux bogues PHP2Shell ?
0:41 Mercredi, PHP a publié des correctifs d'urgence pour deux failles critiques qui permettent à un étranger d'exécuter du code sur un serveur sans connexion. Ensemble, elles sont appelées PHP2Shell, et elles remontent à PHP cinq point quatre. Voici le premier bogue en termes simples. PHP alloue un budget mémoire à chaque requête. Si une requête atteint cette limite au mauvais moment, PHP s'échappe en hâte et laisse la requête à moitié construite. Alors l'étape de nettoyage fait confiance à la chose à moitié construite.
1:07 Le deuxième bogue est un résidu. Une erreur fatale peut laisser une note pointant vers la mémoire qui appartenait à la dernière requête. Le même worker gère la requête suivante et suit la note. À ce moment-là, quelqu'un d'autre vit à cette adresse. Sur Apache avec mod PHP, les dégâts se produisent avant que votre propre code ne s'exécute, donc votre page de connexion n'a jamais son mot à dire. Wiz dit que même un script "hello world" est exposé. Le correctif supprime la sortie d'urgence de PHP en cas de manque de mémoire.
1:32 Au lieu de s'interrompre en milieu de requête, PHP s'arrête désormais poliment au prochain point sûr. Le plus étrange est l'ancienneté du premier indice.
Pourquoi un bogue connu a-t-il attendu deux ans ?
1:39 En 2024, un audit de sécurité externe a conduit un développeur principal de PHP aux premiers signes du problème de mémoire. Aucun exploit n'était connu, et chaque correctif cassait quelque chose. Une équipe qui décide par consensus n'a pas pu choisir, alors le bogue a attendu. Puis en août, des découvreurs sont arrivés en quelques jours.
Qui a trouvé PHP2Shell, et comment ?
1:56 Ryan Austin, chercheur chez Calif, l'a trouvé le 1er août, travaillant dans le cadre du programme Patch the Planet d'OpenAI. OpenAI a signalé la même cause profonde de manière indépendante. Wiz a trouvé des variantes quelques semaines plus tard avec les modèles Gemini et GPT. Austin dit qu'il a utilisé des modèles que tout le monde peut obtenir, plus une théorie sur l'endroit où les anciens bogues de PHP se cachent. OpenAI affirme que l'IA de pointe était la clé. Le bogue était resté caché pendant plus d'une décennie. La publication était prévue pour jeudi.
Comment l'embargo PHP2Shell a-t-il fuité ?
2:21 Mardi, les deux numéros CVE ont commencé à circuler en ligne, avec une heure de publication erronée et un score erroné de dix. PHP a avancé la publication d'un jour. Ce soir-là, Calif a accidentellement publié une vidéo de sa preuve de concept fonctionnant, et des copies ont survécu à la suppression. Mercredi matin, plus de six heures avant la publication, Chainguard a publié des images construites contenant le correctif. PHP dit que n'importe quel attaquant pouvait étudier ce correctif pendant que tout le monde attendait.
2:46 Un correctif est aussi un diff, et les attaquants lisent les diffs.
PHP2Shell est-il exploité, et par qui ?
2:50 Alors qui est réellement touché ? Le pot de miel d'Amazon a enregistré une tentative le 17 octobre et a déclaré plus tard que PHP2Shell est largement exploité. watchTowr signale une exploitation en cours. Cisa a déclaré n'en avoir observé aucune lors de sa publication, et l'équipe de PHP n'a vu aucun exploit fonctionnel lors de la publication. Le PDG de Cloudflare a déclaré avoir vu des milliers de tentatives dans les dix heures précédant l' annonce, et des millions le jeudi matin.
3:13 Amazon est prudent sur un point. Il ne sait pas si ses premières tentatives auraient fonctionné sur un système réel. Une tentative n'est qu'un coup à la porte. Alors à quel point est-ce grave, vraiment ? watchTowr dit que les exploits publics qui circulent plantent ou ne font rien la plupart du temps. VulnCheck dit que l'exécution de code fonctionne dans certaines configurations, et aucun des exploits publics ne contourne la randomisation de la mémoire sur les serveurs x86 standard. Le chercheur Elias Taylor dit que ce n'est pas aussi facile que Log4Shell.
3:40 Tout le monde dit quand même de corriger. Les gouvernements n'ont pas attendu le verdict.
Qu'est-ce que les gouvernements ont mis hors ligne ?
3:44 La NSA a dit aux organisations qui ne pouvaient pas patcher de mettre les systèmes PHP hors ligne, et le National Cyber Security Centre du Royaume-Uni a donné des conseils similaires. Des sites néerlandais, y compris le service national d'identité numérique, ont été mis hors ligne, ainsi qu'un site de la police de Paris. Wikimedia a mis plusieurs systèmes hors service par précaution. Palo Alto Networks a recensé plus de vingt-deux millions d'instances exposées. Et un professeur australien a fait la remarque la plus pertinente. Les sites dont il faut s'inquiéter sont ceux qui ne sont pas hors service aujourd'hui.
Quelles versions de PHP reçoivent un correctif ?
4:11 Des correctifs existent pour PHP huit point deux à huit point cinq. Pour sept point quatre, huit point zéro et huit point un, PHP n'a publié que des correctifs source. Les versions plus anciennes ne reçoivent rien du projet PHP, alors demandez à votre distribution. Les solutions de contournement réduisent les risques, mais PHP dit que la mise à jour est le seul correctif complet. C'est la même leçon que l'épisode eMudhra d'hier,
Que faire à propos de PHP2Shell ce soir ?
4:32 car un correctif existant n'est pas la même chose que le processus en cours d'exécution l'ayant. Trouvez tous les PHP dans votre pile, même les copies cachées à l'intérieur d'autres logiciels. Mettez à jour, redémarrez les workers, et vérifiez les logs jusqu'au dix-sept octobre. Le même jour, GitLab a publié un correctif critique,
Quoi d'autre a publié un correctif RCE critique aujourd'hui ?
4:47 dix-neuf point cinq point un. Un dépassement d'entier dans son compilateur d'expressions régulières permet à un utilisateur non authentifié d'exécuter du code sur le serveur, et il obtient un score de dix sur dix. GitLab dot com est déjà patché. Les installations auto-gérées nécessitent la mise à jour.
Pourquoi Meta a-t-il été condamné à payer 25 milliards de dollars ?
5:01 Pendant ce temps, au Nouveau-Mexique, un juge a ordonné à Meta de payer vingt-cinq milliards de dollars d'amendes pour l'affaire Cambridge Analytica. Le jury a compté plus de quarante-trois millions de violations à hauteur de cinq mille dollars chacune, ce qui a représenté environ deux cent vingt milliards avant que le juge ne le réduise. Meta dit qu'il gagnera en appel. Maintenant la défense que j'ai promise.
Quelle est la défense de Chainguard pour le correctif précoce ?
5:19 Le PDG de Chainguard a déclaré à The Register qu'il avait trouvé les mêmes bogues lui-même un vendredi soir, après avoir appris que quelque chose se préparait chez PHP, avec une invite de base pour trouver de mauvaises vulnérabilités. Il dit qu'il a publié tôt parce que des gens étaient déjà touchés. Si vous préférez lire ceci plutôt que de m'entendre le dire, le diff arrive dans votre boîte de réception tous les matins, gratuitement sur the daily diff dot dev, lien ci-dessous. Donc le verdict d'aujourd'hui est SHIP IT.
Qu'est-ce qui reçoit le tampon SHIP IT ?
5:39 Déployez la mise à jour PHP ce soir, car le nouveau numéro de version est le seul correctif complet. Et c'est le diff pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.
Sources
- Today's PHP Security Release, and How We're Strengthening PHP SecurityThe PHP Foundation
- RCE via OOM corruption (GHSA-w8hw-w9fx-j79w)PHP security advisory
- RCE via stale global state (GHSA-6wmf-4rv5-p3rp)PHP security advisory
- Upcoming Critical PHP Security Releasephp.net
- php2shellCalif
- PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the InternetWiz Research
- Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPotAWS Security Blog
- Critical Vulnerabilities in PHP Require Immediate PatchingCISA
- Flaw in PHP computer language leads to shutdown of websites around worldThe Guardian
- What is PHP, and how bad is the computer language flaw causing website shutdowns globally?The Guardian
- PHP2Shell Exploitation Started Days Before PatchesSecurityWeek
- PHP2Shell: Responding to CVE-2026-109618 and CVE-2026-109619Tanium
- There isn't an easy exploit for this PHP vulnerabilityElias Taylor
- PHP blames supply chain security biz Chainguard for putting entire web at riskThe Register
- PHP2Shell: 22M exposed servers at risk as emergency patches releasedTechTarget
- PHP ships emergency patches for critical PHP2Shell flawsBleepingComputer
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13GitLab
- Meta ordered to pay $25 billion penalty in New Mexico Cambridge Analytica caseCNBC
- Tell HN: 2x PHP RCE CVEs with CVSS 10.0 IncomingHacker News



