PHP-Touch3LL : le jour où le web s'est éteint

Hier, 21 octobre 2026, j'ai vécu un truc que je pensais réservé aux films. Le site des impôts, les préfectures, Météo-France, la CNIL, le gouvernement finlandais, le Port de Rotterdam… tout ça coupé volontairement. Pas à cause d'un hack massif, mais par précaution. Et la cause tient en trois lettres : PHP.

Je vous explique ce qui s'est passé, simplement, et surtout ce que j'en retiens en tant qu'étudiant en dev et builder.

PHP, le moteur caché du web

PHP, c'est un langage né en 1994. Rasmus Lerdorf l'a bricolé pour compter les visites sur son CV en ligne. Trente ans plus tard, il fait tourner environ 69 % des sites dont on connaît le langage serveur : WordPress, Wikipédia, PrestaShop, plein de sites publics.

La meilleure image que j'ai trouvée : les sites, c'est la carrosserie. WordPress, Wikipédia, impots.gouv, ils ont tous un look différent. Mais sous le capot, c'est le même moteur. Si le moteur lâche, toutes les voitures s'arrêtent, peu importe qu'elles soient belles ou bien construites.

En France, l'ANSSI compte plus de 600 000 serveurs PHP exposés. Dans le monde, Palo Alto Networks en recense 22,6 millions. Autant dire que PHP est un point de défaillance unique pour une énorme partie d'Internet.

La faille, expliquée sans jargon

La faille s'appelle PHP-Touch3LL, notée 9,2/10 en gravité. En réalité ce sont deux bugs qui se combinent.

Le premier (CVE-2026-109618) : PHP donne à chaque requête une quantité de mémoire limitée. Si une requête dépasse, elle est coupée net. Le souci, c'est que si la coupure arrive au mauvais moment, par exemple pendant la lecture d'un fichier envoyé via un formulaire, les données restent à moitié préparées. Et au moment du nettoyage, PHP peut les traiter comme si elles étaient valides.

Le second (CVE-2026-109619) : un serveur PHP utilise des « workers » qui servent les visiteurs les uns après les autres. Normalement, chaque worker fait le ménage entre deux visiteurs. Là, un morceau de la requête précédente peut survivre en mémoire.

Imaginez une femme de chambre interrompue en plein ménage. Elle marque quand même la chambre comme prête, et le client suivant trouve les clés et les papiers du précédent. Pire : un attaquant qui choisit le moment de l'interruption peut choisir ce qui reste dans la chambre.

Résultat possible : exécuter du code à distance sur le serveur sans mot de passe, ou voler des mots de passe, des clés et des données d'autres utilisateurs.

Et le plus vicieux : tout ça se passe dans le moteur PHP, avant même que le site ne s'exécute. Mettre son WordPress en maintenance ne sert à rien, la requête malveillante a déjà été lue. Les chercheurs ont montré que même une page « Hello World » était vulnérable.

Une faille connue depuis… 2004

Ce qui me choque le plus, c'est que ce n'est pas vraiment une surprise :

• 2004 : Stefan Esser repère déjà un problème de gestion mémoire dans le traitement des requêtes.
• 2012 : PHP 5.4 sort, et le chemin d'attaque le plus ancien remonte à cette version.
• 2019 : un bug « inoffensif » de requêtes trop longues est signalé. Aucune suite.
• 2024 : un audit de Quarkslab pointe encore la fragilité mémoire, mais sans preuve d'exploitation concrète, la correction est repoussée.
• 2024 à 2026 : l'équipe sécurité de PHP, qui fonctionne au consensus, n'arrive pas à se mettre d'accord sur le bon correctif.

Plus de vingt ans de dette technique. Et c'est là qu'arrive l'IA.

L'IA a tout accéléré

Cet été, la startup Chalif participe au programme « Patch the Planet » d'OpenAI. Un seul chercheur repart des travaux d'Esser, questionne une IA sur comment provoquer un dépassement mémoire à un endroit précis… et en quelques jours, il prend le contrôle d'un site WordPress. Avec des modèles grand public.

Fin août, Wiz trouve la même faille de son côté. Leur constat : un chercheur seul, avec les bons modèles, a fait en une semaine ce qui aurait pris des mois à une équipe d'élite.

La chronologie d'une fuite en cascade

Le plan, c'était un correctif propre le jeudi 22 octobre. Ça ne s'est pas passé comme prévu :

• 20 oct., 17h : un message anonyme sur Hacker News, repris sur X avec une note fausse de 10/10. Le secret saute.
• 20 oct., 21h30 : PHP avance le correctif au 21.
• 21 oct., 5h : Cloudflare déploie des filtres d'urgence, même pour les comptes gratuits.
• 21 oct., 9h41 : l'éditeur Changard publie ses paquets corrigés trop tôt. En comparant l'ancien et le nouveau code, n'importe qui (et n'importe quelle IA) peut localiser la faille en quelques minutes.
• 21 oct., ~15h30 : sortie officielle des versions corrigées.
• 21 oct., 15h45 : la NSA publie un message limpide : si vous ne pouvez pas mettre à jour, coupez.
• 21 oct., ~16h : Chalif laisse fuiter par erreur une vidéo de démonstration.
• 21 oct., 16h19 : WatchTower détecte les premières vraies attaques.

Le soir même, la PHP Foundation a reconnu un « échec structurel » : trop peu de moyens, un processus de décision trop lent, et la sécurité de tout le web PHP qui repose sur une poignée de devs et quelques bénévoles.

Le grand éteignage

Toutes les agences (ANSSI, NSA, NCSC, CERT-EU…) ont dit la même chose : pas de mise à jour testée tout de suite, alors on débranche. L'analogie du serrurier résume bien : si le fabricant annonce que ta serrure s'ouvre en deux secondes et que le serrurier n'est pas encore passé, tu fermes la boutique.

En France : Météo-France fermé à 16h40, toutes les préfectures en maintenance, impots.gouv, plusieurs ministères, la CNIL, Les Échos. À l'international : Finlande, Parlement néerlandais, Rotterdam, Munich, des hôpitaux européens, une partie de Wikimedia, et même Steam quelques heures. Au Japon, la Première ministre a demandé publiquement à toutes les organisations de vérifier leur PHP.

Et Node.js dans tout ça ?

Moi, je build surtout en JavaScript et TypeScript. Alors forcément, ma première réaction a été : « ouf, pas mon stack ». Sauf que le même jour, le 21 octobre, Node.js a publié sa propre vague de correctifs de sécurité.

Pas de lien avec PHP-Touch3LL, c'est une sortie de sécurité séparée. Mais elle n'est pas anodine :

• 10 failles corrigées, dont 4 notées « haute » gravité, sur toutes les versions supportées (26.x, 24.x et 22.x).
• La plus sérieuse (CVE-2026-111497) : une écriture hors limites dans le décodeur Brotli, le format de compression utilisé partout sur le web. Node.js indique qu'elle peut permettre l'exécution de code à distance. Même famille de problème que PHP : de la mémoire écrite là où elle ne devrait pas.
• Trois failles permettent de contourner la vérification du nom d'hôte des certificats TLS quand une adresse IP est écrite de façon « bizarre » (chiffres pleine largeur, formes IPv4 non canoniques…). En clair : un serveur pourrait se faire passer pour un autre.
• Une faille moins spectaculaire mais vicieuse : crypto.randomUUID() et randomInt() pouvaient renvoyer les mêmes valeurs à chaque démarrage pour les applis construites à partir d'un snapshot ou en exécutable unique (SEA). Des identifiants « aléatoires » qui ne le sont plus.
• Le reste touche le DNS, le keep-alive HTTP, le lecteur ZIP et le Permission Model, plus des mises à jour de dépendances (OpenSSL, Undici, c-ares, SQLite, certificats racines).

Les versions corrigées : v26.12.1, v24.22.1 et v22.23.4. Et comme toujours, les versions en fin de vie sont touchées et ne seront pas corrigées.

Différence majeure avec PHP : personne n'a eu besoin de débrancher quoi que ce soit. Le processus a fonctionné comme prévu : signalement, correctif, publication coordonnée. Mais ça m'a rappelé que mon stack n'est pas une forteresse. Lui aussi repose sur des briques maintenues par une petite équipe, et lui aussi doit être mis à jour.

Non, la panne Orange n'avait rien à voir

Le même jour, le réseau mobile Orange (et Sosh) est tombé dès 11h20, pendant presque 10 heures, avec des appels d'urgence perturbés. Sur les réseaux, ça a vite parlé de cyberguerre.

Sauf que non. Orange a confirmé une panne matérielle sur un équipement du cœur de réseau. Zéro lien avec PHP. Juste une coïncidence, dans une semaine déjà chargée (la veille, un datacenter Google à Londres avait planté Revolut et des banques britanniques). Petite leçon au passage : deux pannes en même temps, ça ne veut pas dire une seule cause. Et deux annonces de sécurité le même jour (PHP et Node.js), non plus.

Ce que j'en retiens

Les experts comparent ça à Heartbleed (2014) et Log4Shell (2021). La différence ici, c'est que la faille a été trouvée par des défenseurs, gérée en secret, et c'est une série de fuites qui a tout précipité. Mais c'est aussi la première grosse crise de l'ère IA.

Trois trucs me restent en tête :

1. Les communs numériques sont fragiles. Le web génère des centaines de milliards, et il repose sur des briques open source maintenues par quelques personnes sous-financées. PHP comme Node.js. Ça me parle beaucoup, parce que moi aussi je build sur de l'open source tous les jours.
2. L'IA change le rapport de force. Trouver une faille et en faire une vraie attaque, ça prend maintenant des jours, pas des mois. Ça marche dans les deux sens, mais les attaquants n'ont besoin de réussir qu'une fois.
3. Les sites oubliés sont le vrai problème. Les grosses orgas ont coupé et patché dans la journée. Mais des millions de petits sites jamais mis à jour vont rester vulnérables pendant des mois. Leurs propriétaires sont dans la course sans même le savoir.

Et concrètement, toi, tu fais quoi ?

• Si tu as un site en PHP (WordPress inclus, même un vieux blog) : mets à jour PHP maintenant, pas juste ton CMS. Chez un hébergeur mutualisé, vérifie qu'il l'a fait.
• Si tu as un serveur Node.js : passe en v26.12.1, v24.22.1 ou v22.23.4 selon ta version. Pense aussi à tes images Docker et à ta CI, qui embarquent souvent une version figée. Et si tu es encore sur une version en fin de vie, c'est le moment de migrer.
• Si tu peux, passe derrière un WAF comme Cloudflare, ça a servi de première barrière.
• Fais l'inventaire de ce qui tourne réellement sur tes serveurs. Tu ne peux pas protéger ce que tu ne sais pas avoir.
• Et si ta boîte vit de l'open source, pensez à financer les projets dont vous dépendez. Hier a montré ce que ça coûte de ne pas le faire.

À l'heure où j'écris, aucune intrusion réussie via PHP-Touch3LL n'a été confirmée publiquement, et les services reviennent petit à petit. Mais je suis convaincu d'une chose : ce n'était pas la dernière crise de ce genre. Avec l'IA, la prochaine viendra plus vite.

Sources

1. 01Node.js Security Releases: October 21, 2026Node.js / 21 octobre 2026