Vulnérabilité Brotli de Node.js (CVE-2026-111497) : nous utilisions une version affectée, corrigée, sans trace d'exploitation

Ce matin, nous expliquions que LFW.com n'était pas concerné par le problème de sécurité PHP, car aucun PHP ne tourne sur nos serveurs.

Celui-ci nous concernait : notre serveur utilisait une version affectée. LFW.com tourne sous Node.js, et le projet Node.js a publié des correctifs de sécurité aujourd'hui à 6 h 38 (heure de l'Est des États-Unis). Nous avons mis notre serveur à jour à 13 h 24 le jour même.

Ce que Node.js a corrigé

La version corrige dix vulnérabilités dans les branches 26.x, 24.x et 22.x. Quatre sont de gravité élevée. Celle qui compte le plus pour nous :

• CVE-2026-111497, le décodeur Brotli. Brotli est une méthode courante de compression du trafic web. Une faille dans la façon dont Node.js le décompresse peut écrire au-delà de la fin d'un bloc de mémoire. Le projet Node.js indique qu'elle permet l'exécution de code à distance : faire tourner le code de quelqu'un d'autre sur votre serveur.

À 14 h (heure de l'Est des États-Unis) le 21 octobre, ni le projet Node.js ni la presse spécialisée ne signalent d'attaques réelles ni d'exploit public.

Passez en 22.23.4, 24.22.1 ou 26.12.1. Node.js précise que les versions en fin de vie sont toujours concernées et ne reçoivent pas de correctif : passez-les à une version maintenue.

Comment la faille nous concernait

L'essentiel de LFW.com est fait de pages générées à l'avance. Mais le serveur fait aussi des tâches qui consistent à récupérer les sites web d'autres personnes :

• l'audit gratuit, qui charge n'importe quel site saisi par un visiteur ;
• notre surveillance, qui vérifie des sites selon un calendrier.

Quand Node.js récupère une page, il décompresse Brotli automatiquement. Un site malveillant pourrait donc répondre à l'une de ces requêtes avec des données compressées conçues pour corrompre la mémoire de notre serveur. Dans le pire des cas, l'attaquant peut alors exécuter ses propres commandes sur notre serveur : lire ce qu'il stocke, installer une porte dérobée ou s'en servir pour attaquer d'autres sites. L'audit gratuit est la partie la plus exposée, car c'est un inconnu qui choisit l'adresse.

Ce que nous avons fait, et quand

La chronologie, en heure de l'Est des États-Unis :

• 6 h 38 : le projet Node.js a publié les versions corrigées.
• 13 h 24 : nous avons mis Node.js à jour en 22.23.4 sur notre serveur et redémarré le site.
• Juste après : nous avons cherché sur le serveur des signes que quelqu'un avait utilisé la faille pendant qu'elle était ouverte.

Cela a laissé environ six heures trois quarts entre la divulgation publique et notre mise à jour. Nous aurions préféré que ce soit plus court.

Comment nous avons vérifié que personne ne l'a exploitée

Nous avons commencé par ce que notre serveur a réellement récupéré pendant ces heures :

• Aucun audit gratuit n'a été lancé. Personne n'a demandé au serveur de charger un site extérieur de son choix.
• Aucune analyse de site n'a été lancée.
• La surveillance n'a vérifié que nos propres sites.

Les traces que laisse habituellement une attaque

Nous les avons ensuite cherchées sur le serveur :

• Aucun plantage. Une tentative ratée de corrompre la mémoire fait généralement planter le programme. Les journaux du serveur web de la semaine écoulée ne montrent ni plantage, ni erreur de mémoire, ni redémarrage forcé.
• Rien de plus en cours d'exécution. Le compte du service n'exécute que le serveur web et le moteur de recherche, sans programme parasite lancé par l'un ou l'autre.
• Rien de nouveau sur le disque. Aucun script ni programme nouveau dans les dossiers temporaires, et aucun changement des tâches planifiées ou des réglages des services en dehors de notre propre déploiement.
• Aucune nouvelle porte d'entrée. Les connexions au serveur des 30 derniers jours ne viennent que de nos deux clés, et la liste des clés autorisées n'a pas changé depuis septembre.

Le trafic web

Enfin, nous avons lu chaque requête entre la publication et la mise à jour :

• Moins de trafic que la veille, et aucune erreur du serveur.
• Chaque requête est passée par Cloudflare. Notre pare-feu n'accepte le trafic web que de Cloudflare, donc rien n'a atteint le serveur directement.
• Environ 200 sondages de routine, le bruit de fond que reçoit tout site public. La plupart cherchaient des fichiers PHP sur un serveur sans PHP. Chacun a reçu une réponse « introuvable » ou « non autorisé ».

Ces vérifications trouvent les signes habituels d'une attaque. Elles ne peuvent pas prouver qu'il ne s'est rien passé, et nous ne le prétendons pas. Nous n'avons rien trouvé.

Où Cloudflare aide, et où il n'aide pas

Notre trafic passe par le proxy de Cloudflare, qui filtre les requêtes avant qu'elles n'atteignent notre serveur. C'est une vraie protection pour ce qui entre.

Mais la voie principale de cette faille allait dans l'autre sens : notre serveur qui lit les réponses d'autres sites. Cloudflare ne se trouve pas dans cette direction, c'est donc la mise à jour qui l'a corrigée.

Nos propres postes de travail

Nos postes de travail utilisent aussi Node.js. Ils ne sont pas exposés à internet, donc le risque était plus faible. Par précaution, nous les avons aussi mis à jour en priorité vers des versions corrigées.

Le reste de la version

Les autres correctifs méritent votre attention si vous utilisez Node.js :

• Deux contournements de la vérification du nom dans les certificats TLS (CVE-2026-105483 et CVE-2026-106069), tous deux de gravité élevée. La vérification du certificat permet à un programme de savoir qu'il parle au bon serveur.
• Une faille qui tronque les noms DNS (CVE-2026-105482), de gravité élevée : les noms contenant un caractère NUL caché sont coupés.
• Des valeurs aléatoires répétées dans les instantanés (CVE-2026-106074), de gravité moyenne. Les applications empaquetées en exécutable unique ou en instantané de démarrage pouvaient répéter les mêmes identifiants « aléatoires » dans chaque processus.
• Des certificats racine mis à jour. La version met aussi à jour les certificats intégrés à Node.js après la compromission d'une autorité de certification intermédiaire d'eMudhra.

La liste complète figure dans l'avis de Node.js.

Ce qu'il faut vérifier chez vous

Si votre site ou vos outils tournent sous Node.js :

• Passez en 22.23.4, 24.22.1 ou 26.12.1. Vos outils de compilation comptent aussi.
• Commencez par tout ce qui récupère du contenu extérieur : vérificateurs de liens, proxys d'images, lecteurs de flux, webhooks, scrapers. C'est ce que la faille Brotli atteint.
• Recompilez tout ce qui est empaqueté en exécutable unique ou en instantané. Mettre Node.js à jour sur le serveur ne met pas à jour une copie intégrée à un programme.
• Hébergement géré ? Consultez la page d'état de votre hébergeur. Beaucoup mettent Node.js à jour pour vous.

Si vous voulez un coup de main

Nous vous aidons volontiers sur chacun de ces points, qu'il s'agisse de trouver ce qui tourne sous Node.js ou de vérifier un serveur après une mise à jour. Écrivez-nous.