Node.js 22, 24 et 26 : les correctifs de sécurité à déployer maintenant

Le projet Node.js a publié le 29 juillet 2026 des mises à jour de sécurité pour ses trois branches maintenues. Elles corrigent onze vulnérabilités, dont trois classées à sévérité élevée dans HTTP/2 et le Permission Model. Les équipes qui exécutent un serveur Node exposé, utilisent l'isolation par permissions ou construisent leurs applications dans des conteneurs doivent vérifier la version réellement déployée.

Les versions corrigées sont 22.23.2 LTS, 24.18.1 LTS et 26.5.1 Current. Une modification du seul package.json ne suffit pas : Node est le moteur d'exécution, souvent fourni par une image de base, un runner CI, un service managé ou l'hôte lui-même.

La réponse rapide

Les numéros sont des seuils minimaux pour cette série de correctifs. Si une version plus récente de la même branche est disponible au moment du déploiement, il faut préférer celle-ci après validation. Une branche arrivée en fin de vie ne reçoit pas ces garanties et doit être migrée vers une branche maintenue.

Trois vulnérabilités élevées à examiner en premier

La première vulnérabilité importante, CVE-2026-56846, concerne la gestion mémoire des en-têtes HTTP/2. Des en-têtes conservés peuvent contourner la limite maxSessionMemory, ce qui permet à un client distant de faire croître la consommation mémoire jusqu'à provoquer une indisponibilité. Elle affecte les branches 22 et 24.

Le risque est particulièrement pertinent pour un service Node qui termine lui-même les connexions HTTP/2 et reste directement joignable depuis Internet. Un proxy inverse peut réduire l'exposition s'il termine HTTP/2 et impose ses propres limites, mais cette architecture doit être vérifiée : certains proxys transmettent encore la connexion ou laissent un chemin réseau alternatif vers l'application.

CVE-2026-56848 est un use-after-free dans l'envoi HTTP/2 réentrant. Une séquence spécifique peut réutiliser une zone mémoire après sa libération et conduire à un crash ou à un comportement indéfini. Les branches 22, 24 et 26 sont concernées. La présence d'un frontal ne constitue pas une preuve d'immunité si le backend accepte HTTP/2.

La troisième faille élevée, CVE-2026-58043, touche le Permission Model. Une confusion autour de préfixes de chemins interprétés avec une logique de type radix peut accorder un accès plus large que l'autorisation de système de fichiers prévue. Elle affecte les trois branches. Les applications qui utilisent --permission, --allow-fs-read ou --allow-fs-write pour isoler du code doivent la traiter comme une rupture de leur frontière de sécurité.

TLS et mTLS comportent deux pièges distincts

CVE-2026-56850, classée moyenne, concerne la réutilisation des identités dans un agent HTTPS utilisant plusieurs certificats PFX pour le mTLS. Une connexion peut réemployer une identité client qui ne correspond pas à celle attendue pour la requête suivante. Dans une architecture où le certificat détermine le locataire, le partenaire ou le niveau d'accès, cette confusion peut avoir un impact d'autorisation supérieur à ce que suggère le mot « moyen ».

CVE-2026-58040 concerne la reprise de session TLS. Dans certaines conditions, la réutilisation d'une session peut contourner une nouvelle vérification du nom d'hôte. Le risque dépend de la manière dont les connexions, les agents et les destinations sont mutualisés. Les services qui contactent plusieurs domaines avec un pool commun ou des paramètres TLS personnalisés doivent revoir leurs tests.

Ces failles illustrent une règle utile : la sévérité publiée est un point de départ, pas la mesure exacte du risque dans chaque système. Une vulnérabilité moyenne placée sur une frontière d'identité critique peut être prioritaire sur une vulnérabilité élevée inaccessible dans l'architecture réelle.

DNS, SQLite et zlib peuvent provoquer une indisponibilité

Plusieurs correctifs moyens concernent des erreurs capables de faire tomber un processus :

• CVE-2026-58042 peut provoquer un arrêt lors d'un dns.resolveAny() recevant plus de 256 enregistrements A ;
• CVE-2026-58045 exploite une longueur falsifiée sur un TypedArray transmis aux API synchrones de zlib et peut conduire à un crash ;
• CVE-2026-58041 touche SQLTagStore dans node:sqlite, où un itérateur obsolète peut réexécuter une écriture de manière inattendue.

La faille SQLite ne concerne que les branches 24 et 26. Les deux autres touchent les trois branches corrigées. Leur exploitabilité dépend de la capacité d'une donnée non fiable à atteindre l'API vulnérable. Une application qui résout des domaines fournis par ses utilisateurs, décompresse des contenus externes ou expose une couche d'accès SQLite doit vérifier ce chemin explicitement.

Un crash reproductible reste un incident de sécurité lorsqu'un acteur distant peut le déclencher. Les redémarrages automatiques limitent la durée d'une panne individuelle, mais un attaquant peut répéter la requête, vider les files de traitement et augmenter le coût de l'infrastructure.

Les vulnérabilités faibles ne sont pas toutes négligeables

Deux problèmes classés faibles permettent à trace_events et à process.report d'écrire en dehors des chemins autorisés par le Permission Model. Ils ne donnent pas nécessairement un accès complet au système, mais contredisent la promesse d'une liste de destinations contrôlée. Dans une plateforme qui exécute du code tiers, un rapport peut écraser ou créer un fichier dans un emplacement non prévu.

Une autre faiblesse se situe dans l'analyseur HTTP : certains en-têtes tronqués peuvent créer une divergence d'interprétation et contribuer à une désynchronisation de requêtes lorsqu'un serveur Node sert de proxy de transfert. Le scénario est plus spécialisé qu'un serveur web classique, mais les passerelles et outils internes construits sur Node doivent l'étudier.

Les versions de dépendances embarquées, notamment Undici et llhttp, ont également été actualisées dans les publications. Une équipe doit lire les notes de sa branche plutôt que de supposer que les onze CVE résument tous les changements de comportement.

Trouver toutes les copies de Node réellement exécutées

L'inventaire est souvent plus difficile que la mise à jour. Un dépôt peut déclarer Node 24 dans .nvmrc alors que le conteneur de production utilise encore une ancienne image 22. Un runner GitLab, une fonction serverless, un job de migration ou un outil de génération statique peut embarquer sa propre version.

La vérification doit couvrir :

1. l'image finale de chaque service, avec node --version exécuté dans le conteneur ;
2. les images de construction, car un script malveillant peut s'exécuter pendant npm install ;
3. les runners CI et les conteneurs de jobs ;
4. les tâches planifiées, workers et commandes d'administration ;
5. les fonctions serverless et runtimes gérés ;
6. les postes ou serveurs qui lancent des outils Node en production ;
7. les images en cache dans le registre susceptibles d'être redéployées.

Un scanner de conteneur peut retrouver le paquet vulnérable, mais il ne prouve pas quel binaire est lancé ni quelles options sont actives. À l'inverse, node --version confirme le moteur courant sans révéler toutes les copies dormantes. Les deux vues sont complémentaires.

Mettre à jour une image sans conserver l'ancien digest

Modifier FROM node:24-bookworm-slim puis reconstruire ne garantit pas toujours un changement si un cache ou un miroir fournit l'ancien digest. Il faut tirer explicitement la base récente, reconstruire sans réutiliser la couche concernée lorsque nécessaire, puis inspecter le résultat.

Avec une image épinglée par digest, l'opération doit être volontaire : remplacer le digest par celui d'une version corrigée, reconstruire, signer ou attester l'image selon la politique du projet, puis mettre à jour le manifeste de déploiement. L'épinglage protège contre les changements invisibles, mais impose de renouveler la référence lors d'un correctif.

Le lockfile npm ne fixe pas la version de Node. Des champs engines, packageManager, .nvmrc ou .tool-versions documentent et contrôlent partiellement l'environnement de développement ; le Dockerfile ou la configuration de la plateforme détermine le runtime livré.

Un déploiement progressif en sept étapes

Un correctif de version patch est conçu pour limiter les incompatibilités, mais il mérite toujours un déploiement contrôlé :

1. inventorier les services et classer d'abord ceux exposés en HTTP/2 ou utilisant le Permission Model ;
2. reconstruire avec 22.23.2, 24.18.1, 26.5.1 ou une version ultérieure maintenue ;
3. lancer les tests unitaires, d'intégration, TLS, proxy et charge ;
4. vérifier les modules natifs et la compatibilité de l'image système ;
5. déployer sur une petite part des instances ;
6. surveiller erreurs, mémoire, latence, redémarrages et échecs TLS ;
7. généraliser, puis supprimer les anciennes images des chemins de redéploiement.

Le retour arrière doit viser une image connue et préparée, mais restaurer une version vulnérable ne peut être qu'une mesure temporaire. Si un problème applicatif apparaît, isoler le changement, corriger ou désactiver la fonction affectée est préférable à un séjour prolongé sur l'ancien runtime.

Vérifier après le déploiement

Le succès de la pipeline n'est pas la preuve finale. Il faut interroger le processus réellement lancé. Une route de diagnostic interne, un inventaire d'observabilité ou une commande dans le conteneur peut exposer process.version sans rendre cette information publique à Internet.

Les équipes doivent également confirmer que toutes les répliques utilisent le nouveau digest et qu'aucun ancien pod n'attend derrière un autoscaler. Un job nocturne rarement démarré peut échapper à l'observation immédiate. Son image doit être mise à jour avant sa prochaine exécution.

Pour HTTP/2, surveiller la mémoire par session, les fermetures anormales et les redémarrages. Pour TLS et mTLS, exécuter des tests avec plusieurs noms d'hôte et plusieurs certificats clients. Pour le Permission Model, ajouter des tests négatifs prouvant qu'un chemin voisin de celui autorisé reste interdit.

La checklist opérationnelle

• relever la version dans chaque runtime, pas seulement dans le dépôt ;
• passer au minimum à 22.23.2, 24.18.1 ou 26.5.1 ;
• privilégier une branche LTS maintenue pour la production ;
• reconstruire les images à partir d'une base effectivement actualisée ;
• tester HTTP/2, TLS, mTLS et permissions selon l'exposition du service ;
• déployer progressivement avec des métriques de mémoire et de crash ;
• vérifier le digest et process.version après lancement ;
• mettre à jour aussi CI, workers, cron et fonctions managées ;
• empêcher le redéploiement accidentel d'une ancienne image ;
• planifier la migration de toute branche en fin de vie.

Cette publication ne demande pas une refonte de l'application. Elle demande une discipline d'exploitation : connaître ses runtimes, reconstruire à partir d'une base corrigée et vérifier ce qui tourne réellement. Les failles HTTP/2 offrent les scénarios distants les plus directs, tandis que le Permission Model et mTLS peuvent atteindre des frontières de confiance centrales. Attendre le prochain cycle de dépendances laisserait ces risques ouverts sans bénéfice technique.