- Accueil
- Test HTTP2Shell
Votre site est-il exposé à HTTP2Shell ?
Une faille critique du décodeur Brotli (CVE-2026-111497, CVSS 9.2), surnommée HTTP2Shell ou Node2Shell, permet de faire planter un serveur, voire d’y exécuter du code, avec des données compressées piégées. Saisissez l’adresse de votre site : nous repérons la technologie qu’il annonce et, si sa version est visible, la comparons aux versions corrigées.
Contrôle passif : une seule visite de la page d’accueil, comme un navigateur. Aucune donnée piégée n’est envoyée.
Brotli se cache souvent dans les dépendances
Ce test ne voit que la technologie annoncée par la page d’accueil. Nos audits cherchent les copies vulnérables là où elles se trouvent vraiment et vous disent quoi corriger, dans l’ordre.
Analyse de code
Repère les dépendances vulnérables de votre application (paquets npm et Python, modules Go), sans envoyer le code.
1 à 3 KreditsTest d’intrusion non destructif
Identifie la technologie réelle même quand elle est masquée, puis teste les failles connues de votre site.
5 KreditsAudit de surface et SSL/TLS
Certificat, protocoles, en-têtes et informations publiques exposées, avec une note de A+ à F.
GratuitHTTP2Shell en bref
HTTP2Shell (CVE-2026-111497) est une écriture hors limites dans le décodeur C de Brotli, la bibliothèque de compression de Google, versions 1.0.3 à 1.2.0. Malgré son nom, le protocole HTTP/2 n’est pas en cause. Elle circule aussi sous les noms Node2Shell, Python2Shell et Broccoli2Shell.
Il faut qu’un programme décompresse un flux Brotli fourni par quelqu’un d’autre. Côté serveur : un corps de requête envoyé avec Content-Encoding: br (Express 5 le décode par défaut). Côté client : une réponse compressée lue par fetch() de Node.js, Bun, requests, aiohttp, httpx ou curl. Les polices WOFF2, les images JPEG XL et les fichiers Parquet passent aussi par Brotli.
Selon l’application, l’effet va du plantage du service à l’exécution de code sans authentification. Node.js, Bun, Python, Go, Envoy, Istio et .NET ont publié des correctifs.
Aucun test à distance ne peut prouver la faille sans risquer de faire planter le serveur : ce test lit seulement ce que le site annonce. Le vrai contrôle se fait sur le serveur, en relevant les versions installées.
Comment se protéger
- 1
Relever les versions installées
Sur chaque serveur et image Docker. Ne vous fiez pas à process.versions.brotli, qui affiche encore 1.2.0 après le correctif : seule la version de Node.js compte.
node -v bun --version pip show brotli brotlicffi dpkg -l 'libbrotli*' - 2
Mettre à jour
Node.js 22.23.4, 24.22.1 ou 26.12.1 (les versions 18, 20, 23 et 25 ne recevront pas de correctif), Bun 1.4.4 puis recompiler les binaires, brotli 1.2.1 et brotlicffi 1.2.1.0 pour Python, andybalholm/brotli v1.2.7 pour Go, Envoy 1.36.12, 1.37.8, 1.38.6, 1.39.3 ou 1.40.0, et le paquet libbrotli de votre distribution.
- 3
En attendant : refuser le Brotli entrant
Rejetez les requêtes compressées en Brotli avant qu’elles n’atteignent l’application, et coupez la décompression automatique des appels sortants quand c’est possible. Pour fetch() de Node.js, seule la mise à jour protège.
if ($http_content_encoding ~* "br") { return 415; }
Questions fréquentes
Le test est-il vraiment gratuit ?
Oui, sans compte et sans limite autre qu’un nombre raisonnable de vérifications par quart d’heure.
Le test peut-il casser mon site ?
Non. Nous faisons une seule visite de la page d’accueil et lisons les en-têtes, comme un navigateur. Aucune donnée compressée piégée n’est envoyée.
Pourquoi le test ne peut-il pas être certain ?
La seule preuve directe serait d’envoyer un flux Brotli piégé, ce qui peut faire planter le serveur. Nous nous en tenons à ce que le site annonce : la technologie, et sa version quand elle est visible.
Mon site est en PHP ou WordPress, suis-je concerné ?
Le site lui-même rarement, mais les outils qui tournent à côté peuvent l’être : scripts Node.js, robots en Python, proxy Envoy ou bibliothèques qui lisent des polices ou des images. Relevez les versions sur le serveur.