Faille Node.js et Brotli (Node2Shell) : comment vérifier votre site

État au 1er novembre 2026. Le projet Node.js a publié le 21 octobre des correctifs de sécurité, dont celui de la faille CVE-2026-111497, appelée Node2Shell. L’erreur se trouve dans Brotli, la bibliothèque de décompression de données compressées que Node.js embarque. Le 27 octobre, l’agence américaine CISA a ajouté cette faille à son catalogue des failles exploitées lors d’attaques.

Pas de panique : la plupart des sites de petites entreprises fonctionnent sur WordPress ou comme de simples fichiers HTML, et n’ont pas Node.js sur le serveur. Si en revanche votre site, votre boutique ou votre espace client fonctionne sur Next.js, Nuxt ou Express, vérifiez-le dès aujourd’hui. Dans ce guide, je montre comment déterminer en quelques minutes si la faille vous concerne, quelles versions contiennent le correctif et ce qu’il faut écrire à l’hébergeur ou au prestataire du site.

Ce qui s’est passé

Brotli est une méthode de compression de données, un peu comme l’archivage de fichiers en ZIP, mise au point par Google et utilisée partout sur internet. Dans la bibliothèque Brotli, des versions 1.0.3 à 1.2.0, il y a une erreur : des données compressées spécialement préparées peuvent, lors de la décompression, s’écrire en dehors de l’emplacement mémoire que le programme leur avait réservé. Les conséquences possibles sont un plantage de l’application, une fuite de données de la mémoire du serveur et, dans le pire des cas, l’exécution du code d’un tiers avec les droits de votre application.

Les dates essentielles :

• 21 octobre 2026 : Node.js et Google ont publié les correctifs (Brotli 1.0.10, 1.1.1 et 1.2.1).
• Du 23 au 26 octobre 2026 : Debian (DSA-6582-1) et Ubuntu (USN-8956-1) ont publié des paquets corrigés de la bibliothèque, et le 25 octobre Microsoft a publié, hors du calendrier habituel, des correctifs pour .NET.
• 27 octobre 2026 : la CISA a ajouté la faille au catalogue Known Exploited Vulnerabilities, c’est-à-dire des failles exploitées dans la pratique.

Sur le début des attaques, les sources divergent. Selon des informations du 22 octobre, aucune attaque n’était encore connue. Des sociétés qui surveillent le trafic réseau décrivent des scans et des premières tentatives entre le 25 et le 27 octobre, et la CISA n’a pas donné de détails. Une partie des tentatives observées ont échoué, mais même une tentative échouée peut mettre une application hors service. Considérez donc cette mise à jour comme urgente.

Qui est concerné par la faille de Node.js

La faille touche les programmes qui décompressent des données Brotli reçues d’un tiers. Concrètement :

• les sites, boutiques et applications fonctionnant sur un serveur avec Node.js : Next.js, Nuxt, Express et d’autres. Node.js intègre Brotli ; ce qui compte, c’est donc la version de Node.js lui-même, et non celle des paquets npm ;
• les applications qui acceptent des requêtes compressées : par exemple, Express 5 (via body-parser 2.x) décompresse par défaut le contenu des requêtes compressé en Brotli ;
• les applications qui récupèrent des données sur des serveurs tiers : le fetch() intégré, les intégrations, le téléchargement d’images depuis d’autres adresses. Vercel cite ici par exemple l’optimisation d’images dans un Next.js hébergé par vos soins ;
• d’autres programmes avec la bibliothèque Brotli : .NET 8, 9 et 10 (Microsoft précise que la décompression Brotli n’y est pas activée par défaut), Bun, Envoy et les paquets système libbrotli sous Linux.

Ceux que la faille ne concerne pas directement :

• les sites statiques, c’est-à-dire de simples fichiers HTML prêts à l’emploi, par exemple issus d’un créateur de sites ou d’un Next.js exporté en fichiers. Node.js ne fonctionne alors que sur l’ordinateur où le site est construit, et non sur le serveur ;
• WordPress et les autres sites en PHP, car ils ne fonctionnent pas sur Node.js. Le serveur peut toutefois disposer de la bibliothèque système Brotli : la mise à jour du système reste donc nécessaire. C’est le travail de l’hébergeur.

Une précision, car c’est une question fréquente : la compression Brotli, avec laquelle le serveur compresse les pages envoyées aux navigateurs, n’est pas cette faille. L’erreur concerne la décompression de données venant de tiers. Ne désactivez pas la compression : le site ralentirait, sans que cela règle le problème.

Quelles versions de Node.js contiennent le correctif

État au 1er novembre 2026 selon l’annonce de Node.js du 21 octobre et la liste des versions de Node.js :

Les lignes qui ne sont plus prises en charge sont vulnérables et ne recevront pas de correctif. Node.js écrit sans détour que les versions arrivées en fin de support sont toujours touchées par les failles des publications de sécurité suivantes. Après le 21 octobre, d’autres versions sont déjà sorties : 24.22.2 (27 octobre) et 26.13.0 (28 octobre, version à partir de laquelle la ligne 26.x a le statut LTS). Elles contiennent le même correctif ; avant de mettre à jour, vérifiez de toute façon la dernière version sur nodejs.org.

La même publication corrige encore neuf autres erreurs, notamment dans la vérification des certificats TLS. Une seule mise à jour règle tout.

Comment vérifier si votre site est exposé

Sans développeur : 5 minutes

1. Le code du site. Ouvrez le site dans le navigateur, appuyez sur Ctrl+U (code source), puis sur Ctrl+F et saisissez _next. S’il y a des résultats, le site est construit avec Next.js. Pour Nuxt, cherchez _nuxt. Cela ne dit pas encore si Node.js tourne sur le serveur, mais cela indique qu’il vaut la peine de poser la question.
2. Les en-têtes. Appuyez sur F12, allez dans l’onglet Réseau (Network), actualisez la page et cliquez sur la première ligne. Dans les en-têtes de la réponse, cherchez x-powered-by. La valeur Next.js ou Express signifie Node.js sur le serveur. L’absence de cet en-tête ne prouve rien, car de nombreux prestataires le masquent.
3. Le panneau de l’hébergeur. Si le site est sur Vercel, la version de Node.js apparaît dans les paramètres du projet. Dans les panneaux d’hébergement qui gèrent les applications Node.js, la version est généralement indiquée à côté de l’application.
4. Demandez au prestataire. C’est le plus rapide et le plus sûr. Vous trouverez plus bas un message prêt à l’emploi.

Pour la personne qui déploie

Vérifiez la version partout où le code s’exécute : sur le serveur, dans chaque conteneur, dans l’environnement de test et dans le CI.

# version de Node.js
node -v

# version de Node.js dans l’image Docker
docker run --rm <image> node -v

# Debian et Ubuntu : version de la bibliothèque système Brotli
dpkg -l | grep -i brotli

Trois pièges :

• Les images Docker construites avant le 21 octobre ont l’ancienne version tant que vous ne les reconstruisez pas à partir de la nouvelle image de base.
• Node.js issu des paquets système peut utiliser la bibliothèque système libbrotli. Comparez sa version avec le suivi de sécurité de Debian ou l’avis Ubuntu USN-8956-1.
• Un processus en cours d’exécution utilise l’ancienne version tant que vous ne le relancez pas.

Que faire aujourd’hui

1. Déterminez si vous avez Node.js sur le serveur (section précédente). Sinon, passez au point 6.
2. Faites une sauvegarde du code, de la base et de la configuration. Je décris comment bien la faire dans le guide sur la sauvegarde d’un site et la règle 3-2-1.
3. Mettez à jour Node.js vers la version du tableau, au sein de la même ligne. Une telle mise à jour n’exige généralement pas de modifications du code.
4. Relancez l’application ou déployez-la de nouveau, et reconstruisez les images Docker. Sur Vercel, pour les projets en 22.x et 24.x, un nouveau déploiement suffit.
5. Sur Node.js 20.x ou une autre ligne qui n’est plus prise en charge, n’attendez pas de correctif, car il n’y en aura pas. Passez à 22.x, 24.x ou 26.x : d’abord sur une copie de test, puis sur le site, dans les jours qui viennent.
6. Interrogez l’hébergeur sur la mise à jour des paquets système Brotli, même si vous avez WordPress.

Si la mise à jour doit attendre quelques jours, des sociétés de sécurité (notamment Aikido et ELLIO) conseillent de rejeter temporairement les requêtes entrantes compressées en Brotli (en-tête Content-Encoding: br) sur le serveur proxy, le pare-feu ou dans l’application elle-même. Ce n’est qu’une protection provisoire : elle ne protège pas contre les données récupérées sur des serveurs tiers et ne remplace pas la mise à jour. Le 21 octobre, Vercel a activé pour tous les projets des règles de pare-feu contre cette faille, mais précise lui-même qu’elles ne remplacent pas la mise à jour de Node.js.

Après la mise à jour, demandez qu’on passe en revue les journaux depuis le 21 octobre : l’application n’a-t-elle pas redémarré anormalement souvent, et n’y a-t-il pas de fichiers, de processus ou de comptes inconnus ? Au moindre doute, signalez l’incident à CERT Polska (l’équipe nationale polonaise de réponse aux incidents informatiques).

Quoi confier à l’hébergeur ou au prestataire du site

Qui met à jour Node.js dépend de l’endroit où fonctionne le site :

Message prêt à copier :

Bonjour, Le 21 octobre, Node.js a publié des correctifs de sécurité, dont celui de la faille CVE-2026-111497 (Node2Shell, Brotli). Pourriez-vous m’indiquer :

1. Notre site ou notre application fonctionne-t-il sur un serveur avec Node.js et, si oui, dans quelle version ?
2. Node.js a-t-il été mis à jour vers la version 22.23.4, 24.22.1, 26.12.1 ou plus récente, et l’application a-t-elle été relancée ?
3. Les paquets système Brotli ont-ils été mis à jour sur le serveur ?
4. Les journaux depuis le 21 octobre montrent-ils quelque chose d’inquiétant ? Merci, et dans l’attente d’une réponse sous 2 jours ouvrés.

Si le prestataire ne répond pas ou si personne ne s’occupe des mises à jour du site, c’est le signe qu’il faut remettre de l’ordre. Je peux reprendre la maintenance du site et, si vous préférez qu’il fonctionne sur un serveur dont je m’occupe moi-même, je fournis aussi le domaine et l’hébergement (à partir de 390 PLN/an HT, serveur en Pologne ou dans l’UE).

Versions non prises en charge : une leçon pour l’avenir

Node.js 20.x n’a pas reçu de correctif, car son support est déjà terminé. C’est le même mécanisme que pour PHP : j’ai récemment écrit sur la fin du support de PHP 8.2, qui tombe le 31 décembre 2026. Une version qui n’est plus prise en charge fonctionne normalement jusqu’au jour où une faille apparaît. Au lieu d’une simple mise à jour, vous attend alors un déménagement vers une version plus récente, sous la pression du temps.

Une fois par trimestre, vérifiez donc trois choses :

• sur quelle version de Node.js ou de PHP fonctionne le site et jusqu’à quand cette version est prise en charge,
• qui a l’obligation de faire les mises à jour dans le contrat et en combien de temps il réagit aux failles urgentes,
• si la sauvegarde peut vraiment être restaurée.

Dans les jours qui viennent, dans la série « Failles et vulnérabilités », je décrirai notamment les correctifs d’octobre dans Next.js et React, et qui est responsable des mises à jour : l’hébergeur, le prestataire ou le chef d’entreprise.

En résumé

Node2Shell est une faille sérieuse, mais pour la plupart des entreprises, la correction est simple : mettre à jour Node.js vers la version 22.23.4, 24.22.1, 26.12.1 ou plus récente et relancer l’application. Les sites sous Node.js 20.x et sous d’autres lignes qui ne sont plus prises en charge ont le plus de travail, car il faut passer à une ligne plus récente. Si vous ne savez pas sur quoi fonctionne votre site, envoyez dès aujourd’hui au prestataire le message de ce guide.

Si personne ne s’occupe des mises à jour de votre site, écrivez-moi. Dans le cadre de la maintenance technique, je surveille le site, je fais des sauvegardes et j’installe les mises à jour de sécurité. Trois forfaits au choix : Veille à partir de 149 PLN/mois HT (mises à jour urgentes sous 2 jours), Standard à partir de 349 PLN/mois HT (réaction sous 1 jour ouvré) et Pro à partir de 749 PLN/mois HT (réaction sous 4 heures). Un audit de sécurité (à partir de 990 PLN HT) montrera ce qui doit encore être amélioré. Je réponds sous 24 heures, et tout nouveau client bénéficie de 20 % de remise sur sa première commande.