Chasser ou être chassé : l'accident qui révèle tout sur le HTTP2Shell

Que s'est-il passé ?

Node.js a publié un correctif pour la vulnérabilité CVE-2026-111497 sur 21 octobre 2026, classée comme « Élevée » : des données Brotli spécialement conçues pourraient écrire au-delà d'un petit tampon à l'intérieur du décodeur et corrompre la mémoire du processus (Node.js (s'ouvre dans un nouvel onglet)). En l'espace d'une journée, Imperva a démontré qu'il était possible d'exécuter du code sur une version officielle de Node.js et a baptisé cette vulnérabilité « Node2Shell » (Imperva (s'ouvre dans un nouvel onglet)). C'est alors que la lunette s'est ouverte. Le bogue se trouve dans la bibliothèque Brotli de Google elle-même, dans les versions 1,0,3 à 1,2,0, et Aikido a démontré que les clients HTTP Python courants la chargent automatiquement (Aikido (s'ouvre dans un nouvel onglet)). Ce nom est devenu « HTTP2Shell ».

La fiche CVE de Google lui attribue un score de 9,2 selon le CVSS 4,0 (fiche CVE (s'ouvre dans un nouvel onglet)), et à la date 24 octobre du , aucune exploitation n'avait été confirmée dans la nature (Strobes (s'ouvre dans un nouvel onglet)). Il en résultait donc une faille rendue publique, un correctif, mais aucune idée précise de l'endroit où le code vulnérable s'exécute.

Comment s'est déroulée la première journée ?

Tanium Guardian a redéfini le champ d'application de son intervention autour de l'appellation plus large « HTTP2Shell » tard dans la soirée 23 octobre (heure américaine) et a mis en place une cellule de crise la même heure. Les équipes de terrain ont reçu une note d'information interne dans l'heure qui a suivi, et une opération de recherche menée pendant la nuit a permis de recenser tous les produits connus pour intégrer ce décodeur, ainsi que les versions corrigées et les versions piégées.

Dès le lendemain matin, les chercheurs de HuntIQ avaient mis en place deux serveurs Node.js délibérément vulnérables dans un laboratoire isolé, l'un à l'intérieur d'un conteneur et l'autre installé directement sur l'hôte, puis avaient lancé une démonstration publique de faisabilité sur les deux. Dans le cas du conteneur, l'exploit a permis l'exécution de code lors de la plupart des essais, chacun n'ayant abouti qu'après une série de tentatives infructueuses. Par rapport à l'installation sur l'hôte de la même version de Node.js, cela n'a fait que provoquer des pannes du service.

C'est lors de la première étape que le code de l'attaquant apparaît. Cette faille n'a pas entraîné le lancement d'un shell par Node.js. Il a purement et simplement remplacé le processus Node.js ; par conséquent, une recherche qui attendrait que « node lance un shell » ne donnerait aucun résultat. La deuxième leçon était encore plus frappante : chaque tentative infructueuse bloque le service, et le redémarrage qui le remet en marche permet justement à l'attaquant de réessayer. Sur le conteneur de test, le runtime s'est relancé à plusieurs reprises en l'espace de quelques minutes. Cette tendance est détectée par Tanium Threat Response bien après les faits.

Les chasseurs ont intégré ces deux conclusions aux travaux déjà en cours. La commande Atlas a été testée à maintes reprises sur les hôtes de laboratoire compromis jusqu’à ce qu’elle détecte de manière fiable un environnement d’exécution Node.js à l’intérieur d’un conteneur et une copie non packagée dans le répertoire /opt, les deux emplacements que l’inventaire des paquets ne prend jamais en compte. Sur 22:40 UTC on 24 octobre, environ 21 heures après la réévaluation, Tanium a publié l'article « HTTP2Shell : Identifier et corriger les copies vulnérables de Brotli avec Tanium », accompagné de cette invite, des questions manuelles qui s'y rapportent et d'une recherche du schéma « plantage puis redémarrage ».

Pourquoi trouver Brotli a été le plus difficile

Brotli n'apparaît pratiquement jamais dans un inventaire de logiciels, car il est intégré à d'autres éléments : moteurs d'exécution de langages, environnements Python, applications de bureau, serveurs proxy et images de conteneurs. Même une version corrigée de Node.js continue d'indiquer son ancien numéro de version Brotli, ce qui fait que la vérification évidente donne un résultat erroné. Chaque exemplaire est mis à jour par son propriétaire ; cela signifie que la première question n'est pas « avons-nous appliqué les correctifs ? », mais « qui est propriétaire de chaque exemplaire ? »

Tanium peut regrouper chacune de ces copies dans une seule liste. L'inventaire des paquets recense ce qui a été installé, l'historique des processus recense ce qui s'exécute dans les conteneurs, et la SBOM de Tanium analyse le contenu des applications et des couches d'image : la bibliothèque Brotli fournie avec une application, le service Express 5 qui décode par défaut les corps de requêtes Brotli, l'ancien décodeur intégré à une image que le correctif de l'hôte ne modifie jamais. Ce qu’a apporté HuntIQ, c’est une connaissance de première main de cette attaque. Les « chasseurs » avaient observé le système planter puis redémarrer, ce qui permettait aux clients de savoir quels serveurs corriger en priorité et à quoi prêter attention sur ceux qu’ils ne pouvaient pas corriger.

• Découvrez comment garder une longueur d'avance sur la prochaine menace émergente grâce à Tanium Security Operations et HuntIQ
• Read the full technical breakdown: HuntIQ Tradecraft: Hunting HTTP2Shell with Tanium (opens in a new tab)
• Découvrez nos travaux de recherche : HTTP2Shell : Même faille, même Node.js, résultat différent (s'ouvre dans un nouvel onglet)