HTTP2Shell n’est pas une faille HTTP/2, et c’est ce qui inquiète

Votre équipe dispose sans doute d’une liste des frameworks dont elle dépend. A-t-elle une liste des décompresseurs ? HTTP2Shell est l’un des noms désormais associés à une faille d’exécution de code à distance qui touche Node.js et, selon certaines informations, des bibliothèques Python. Malgré son nom, le protocole n’est pas en cause. C’est un décodeur de compression.

Le bogue se trouve dans le décompresseur, pas dans le protocole

Comme l’explique Brandefense, il s’agit d’une seule faille, CVE-2026-111497, dans le décodeur Brotli livré avec Node.js. Elle a d’abord été appelée Node2Shell, puis, depuis la fin de journée du 23 octobre (UTC), également HTTP2Shell. Node.js l’a corrigée le 21 octobre 2026 dans les versions 22.23.4, 24.22.1 et 26.12.1. La fiche CVE lui attribue 9,2 sur l’échelle CVSS 4.0. L’avis de sécurité attribue le signalement à OpenAI Codex Security.

Selon Aikido, la même faille Brotli touche de nombreuses bibliothèques et applications qui utilisent HTTP avec Brotli ou brotlicffi installé. L’exécution de code à distance sur l’image officielle de Node.js 24.22.0 est, pour l’instant, ce que les chercheurs ont rapporté. Aikido la présente comme un signalement et non comme son propre test, et ajoute que l’exploit ne fonctionnait pas à chaque fois. Un code de preuve de concept public ferait, selon les informations disponibles, planter Node.js non corrigé, mais aucune exécution de code à distance fonctionnelle n’a été montrée dans du code public. À notre avis, cette distinction change le ton avec lequel décrire la faille. Elle ne change pas la vitesse à laquelle il faut corriger.

Le mauvais nom désigne la mauvaise couche

L’appellation HTTP2Shell se comprend. La faille se manifeste sur le chemin HTTP, et le nom est accrocheur. Mais il oriente vers la mauvaise couche. Nul ne devrait chercher un réglage HTTP/2 à désactiver.

Le pas-à-pas de Brandefense, qui reprend l’explication de Vercel, montre à quel point l’exposition est ordinaire. Node.js ne décode pas Brotli de lui-même. Une application est exposée lorsque son propre code, ou une bibliothèque qu’elle utilise, décompresse des données Brotli contrôlées par un attaquant. Le chercheur Ron Masas a écrit sur X que, sur un environnement d’exécution vulnérable, « app.use(express.json) suffit ». Brandefense indique que cela correspond à ce que fait le code source d’Express 5. Une requête JSON avec un encodage de contenu Brotli est décodée avant l’exécution du code de vos routes.

C’est là le point inconfortable. Dans beaucoup d’équipes, nous le soupçonnons, personne n’a écrit de fonction Brotli et personne n’en a relu. L’exposition est arrivée comme comportement par défaut d’un composant que vous avez bel et bien choisi. Et Brandefense note que d’autres middlewares, frameworks, reverse proxies et votre propre code peuvent aussi décoder Brotli. Autant d’endroits à vérifier.

Corriger doit relever de l’infrastructure, pas d’un ticket de sprint

La chronologie fait l’argument. Node.js a publié les correctifs à 10 h 38 UTC le 21 octobre. D’après Brandefense, le premier dépôt GitHub consacré à la CVE est apparu environ cinq heures plus tard, et en fin de journée du 23 octobre, une recherche en renvoyait 25. À notre avis, les défenseurs n’ont aucun délai de grâce dès lors que les correctifs peuvent être comparés à l’ancien code.

Le même jour, PHP a publié ses propres correctifs pour les failles distinctes PHP2Shell. L’équipe de sécurité de l’université de Toronto prévient qu’une exploitation massive est attendue rapidement et que Cloudflare avait déjà signalé des attaques précoces. Nous ne voulons pas fusionner deux bogues sans lien en une seule histoire. Mais deux failles critiques d’environnements d’exécution qui arrivent ensemble, voilà à quoi ressemble une mauvaise semaine quand tant de choses reposent sur une poignée d’environnements partagés.

Il y a une seconde leçon, sur les logiciels en fin de vie. Brandefense cite Vercel, selon qui Node.js 20 « ne recevra pas ce correctif ». Les équipes restées sur un environnement non pris en charge n’ont pas un correctif de retard. Elles n’ont aucun correctif à appliquer. C’est une décision budgétaire prise il y a des mois qui arrive à échéance en un week-end.

Wiz soutient, dans son analyse de PHP2Shell, que les modèles d’IA de pointe lui ont permis de développer et d’adapter des exploits fonctionnels en quelques heures. Nous y verrions une affirmation à prendre au sérieux, pas un fait établi. Si elle se confirme, le vieux réconfort selon lequel une faille serait trop complexe pour être exploitée s’affaiblit.

Le travail de lundi: inventorier, mettre à jour, désigner un responsable

Notre recommandation est simple. Vérifiez vos versions avec node --version et repérez chaque endroit où votre code ou une dépendance décompresse du Brotli venu de l’extérieur. Passez aux versions corrigées et quittez Node.js 20. N’exécutez pas de code de preuve de concept issu de GitHub en dehors d’un laboratoire isolé, car du code d’exploit provenant de comptes inconnus peut cacher un logiciel malveillant.

Le changement le plus important est organisationnel. Les mises à jour d’environnements d’exécution et de bibliothèques ne devraient pas attendre dans un backlog derrière le travail sur les fonctionnalités. Elles doivent avoir un responsable, un inventaire et une échéance dans la semaine. Une faille de ce genre ne sera pas la dernière, et nous pensons que les équipes qui la traiteront comme de la maintenance courante d’infrastructure seront celles qui remarqueront à peine la suivante.