Le projet Node.js a publié une release de sécurité coordonnée le 18 juin 2026, couvrant d'un coup chaque ligne de release active : v22.23.0 pour la LTS « Jod », v24.17.0 pour la LTS « Krypton » et v26.3.1 pour la ligne Current. Douze CVE atterrissent dans le drop, deux notées High et le reste réparti entre Medium et Low. La release est une security release sur chaque ligne, v26.3.1 recevant en plus le petit lot de patches de fonctionnalités qui suit v26.3.0 (le pool Buffer 64 KiB par défaut, la nouvelle option httpValidation et l'API permission.drop) mais qui n'était pas encore couvert par l'embargo précédent.
La précédente release de sécurité Node.js de cette forme remonte à mars 2026 (voir notre couverture). Le pattern est le même : les correctifs sous embargo s'accumulent, l'embargo tombe, et le projet livre tout le set le même jour sur les trois lignes. Ce qui change cette fois-ci, c'est le cluster de CVE TLS et crypto, qui dominent les bandes High et Medium. Quatre des six entrées Medium sont de forme TLS, et l'un des deux Highs est une garde sur la longueur de sortie WebCrypto qui touche l'API crypto.subtle dont dépendent beaucoup de code serverless et edge.
Les deux correctifs à sévérité High
CVE-2026-48618, normalisation du hostname TLS pour la vérification d'identité serveur. Le patch de Matteo Collina cible le chemin par lequel un serveur TLS Node.js vérifie le hostname fourni par le client contre le certificat présenté. Avant le fix, le chemin de comparaison ne normalisait pas de manière cohérente les hostnames qu'il comparait, ce qui laissait passer un host soigneusement construit (typiquement avec un mix de casses, des points en suffixe, de l'encodage IDN, ou un mix de caractères URL-encodés et bruts) et se lier à un virtual host que le client n'avait pas voulu atteindre. Le patch normalise le hostname de la même manière côté SNI, côté SAN du certificat et côté URL d'origine du client, ce qui aligne Node sur X509_VERIFY_PARAM_set1_host d'OpenSSL 3.x et sur le parser URL WHATWG. Pour tous ceux qui terminent le TLS dans le process Node plutôt qu'à un load balancer, c'est le correctif phare de la release.
CVE-2026-48933, garde sur la longueur de sortie des chiffrements WebCrypto. Le fix de Filip Skokan atterrit dans les chemins SubtleCrypto.encrypt et SubtleCrypto.decrypt. Certains algorithmes (notamment AES-CTR et AES-CBC quand l'appelant demande une sortie contre-tronquée ou étiquetée) acceptent un paramètre length que l'ancien code n'appliquait pas toujours face au buffer réellement produit par l'appel OpenSSL sous-jacent. Un appelant malveillant ou bogué pouvait passer une length supérieure à la sortie du chiffrement et soit lire au-delà du buffer prévu, soit, selon l'algorithme, observer des octets qui auraient dû être tronqués. Le patch clamp la sortie retournée à la longueur demandée et valide la longueur d'entrée côté encrypt, ce qui ferme les cas de lecture et d'écriture hors bornes. Ce genre de correctif compte pour le code qui utilise crypto.subtle de Node pour de l'authentification HMAC, pour des flows de passkey, et pour toute bibliothèque qui fait de l'envelope encryption dans l'API SubtleCrypto façon navigateur.
Les six correctifs Medium
La bande Medium, c'est le cœur de la release. Six CVE, toutes transformables en déni de service ou en divulgation d'information à faible coût, et toutes à patcher sur le calendrier normal plutôt qu'en attendant un triage « High only ».
- CVE-2026-48615, identifiants proxy dans les erreurs de tunnel. Quand un client HTTP Node.js utilise la méthode
CONNECTpour ouvrir un tunnel à travers un proxy HTTPS, l'ancien chemin d'erreur émettait l'URL du proxy (identifiants embarqués compris) dans le message d'erreur jeté. Le patch rédacte la partie identifiants avant que l'erreur ne soit exposée, donc une stack trace ou un fichier de log ne fuite plus le mot de passe du proxy. Le fix est danslibettest, ce qui veut dire qu'il touche à la fois le chemin runtime et les fixtures de test qui vérifient la forme de l'erreur. - CVE-2026-48619, croissance mémoire de
originSetdans http2. Le chemin serveur HTTP/2 acceptait des entrées d'origine dans unoriginSetinterne sans plafond dur, ce qui laissait une seule connexion faire grossir le set sans limite. Le patch fixe un plafond raisonnable, au-delà duquel les nouvelles entrées sont rejetées. Avec HTTP/2 en particulier, une seule connexion TCP peut servir beaucoup de requêtes, donc une structure de données par connexion non bornée est en pratique non bornée par attaquant. - CVE-2026-48928, matching SNI case-sensitive dans le contexte TLS. La sélection de contexte basée sur le SNI (événement
servername,SNICallback) faisait jusqu'ici une comparaison case-sensitive. La RFC 6066 impose un matching SNI case-insensitive sur le fil, mais la sélection de contexte interne à Node était plus stricte que ce que le fil demandait, ce qui produisait une classe de bugs « le même hostname route vers des certificats différents selon la casse ». Le fix abaisse la comparaison en case-insensitive, ce qui est cohérent avec le fil et avec ce que fait OpenSSL lui-même. - CVE-2026-48930, octets NUL dans les hostnames DNS. Un hostname contenant un octet NUL embarqué (
\x00) était jusqu'ici accepté par les modulesdnsetnet, ce qui est un vecteur d'injection connu de longue date parce que lesgetaddrinfoniveau C traitent le NUL comme un terminateur de chaîne. Le patch rejette ces hostnames à la frontière, ce qui ferme le pattern d'attaque classique « coupe-la-chaîne-sur-le-NUL » qui s'est manifesté à un moment ou un autre dans la couche réseau de tous les langages. - CVE-2026-48934, réutilisation de session TLS liée à l'hôte. Le cache de sessions TLS autorisait jusqu'ici une session reprise d'une connexion précédente vers un hôte à être réutilisée pour un autre hôte. Le fix lie le ticket de session au hostname que la connexion d'origine avait authentifié, donc un client ne peut pas déplacer une session entre hôtes (ce qui serait un vecteur de session fixation dans tout code qui s'appuie sur la reprise de session comme contexte d'authentification).
- CVE-2026-48937, intégration nghttp2 1.69.0. C'est le suivi de dépendance. Les lignes v22 et v24 font sauter nghttp2 en 1.69.0, ce qui est tagué SEMVER-MAJOR dans le message de commit Node parce qu'upstream a livré des changements d'intégration cassants. Le suivi de Tim Perry absorbe ces changements dans le wrapper Node. La ligne v26 garde sa base nghttp2 26.2.0 pour l'instant.
Les quatre correctifs Low
La bande Low, c'est du durcissement du modèle de permissions, avec une exception côté HTTP.
- CVE-2026-48617,
process.chdirsurwritereport. Un chemin oùprocess.chdirn'était pas vérifié face aux allow lists read/write du modèle de permissions. - CVE-2026-48931, empoisonnement de la file de réponses dans
http.Agent. Une classe de sévérité basse où la file de réponses de l'agent pouvait être empoisonnée par un serveur malveillant, menant à un use-after-free dans une fenêtre de course étroite. Le fix de Matteo Collina resserre le cycle de vie de la file. - CVE-2026-48935,
FileHandle.utimesavec le modèle de permissions.FileHandle.utimesest désormais désactivé quand le modèle de permissions est actif, parce que le syscallutimessous-jacent n'était pas dans la allow list et pouvait servir de canal auxiliaire pour apprendre des choses sur le système de fichiers. - CVE-2026-48936, scope net pour pipe open et chmod (v26 uniquement). La ligne v26 reçoit en plus un resserrement de permissions autour de
pipe(2)etchmod(2), qui sont les deux syscalls que le modèle de permissions avait laissés dans un état mi-restreint.
Mises à jour de dépendances et la scission LTS / Current
Trois mises à jour de dépendances atterrissent sur chaque ligne, et une est réservée aux LTS.
- OpenSSL 3.5.7 sur v22, v24 et v26. Refresh de sécurité de routine ; la ligne OpenSSL 3.5.x est celle sur laquelle Node est depuis le passage en LTS de v24.
- llhttp 9.4.2 sur toutes les lignes. Le refresh du parser HTTP est une version mineure, sans changement d'API publique.
- undici passe en 8.5.0 sur v26, 7.28.0 sur v24 et 6.27.0 sur v22. La scission de version reflète la politique Node qui épingle un major différent d'
undicipar ligne de release, de manière à ce que le client fetch bundlé suive le major sur lequel la ligne a été originellement livrée. - nghttp2 1.69.0 sur v22 et v24 uniquement. La ligne v26 garde sa base 26.2.0.
Ce qu'il faut faire
Si vous êtes sur la LTS v22, passez en v22.23.0. Si vous êtes sur la LTS v24, passez en v24.17.0. Si vous êtes sur la Current v26, passez en v26.3.1. La release est une security release sur chaque ligne, donc la mise à jour est à faire sur le calendrier normal de patches et pas à reporter. Si vous êtes encore sur v20, vous êtes sorti de la LTS active et devriez planifier le passage vers v22 (ou, si votre toolchain le supporte, v24).
Pour les Highs TLS et WebCrypto, l'impact pratique concerne le code qui termine le TLS dans le process Node (plutôt qu'à un load balancer) et le code qui utilise crypto.subtle directement (plutôt que de passer par une bibliothèque de plus haut niveau comme jose). Les wrappers de bibliothèque assainissent en général l'argument length avant d'appeler l'API sous-jacente, donc le fix WebCrypto est surtout pertinent pour le code qui parle à SubtleCrypto directement. Le fix TLS hostname concerne tous les serveurs qui utilisent l'événement servername ou SNICallback pour choisir un certificat par hostname.
C'est la deuxième release de sécurité Node.js de 2026, et le pattern est désormais familier : les correctifs sous embargo s'accumulent entre les lignes actives, le projet livre tout le set le même jour, et les releases LTS et Current avancent ensemble. La forme à dominante TLS de ce drop rappelle que les surfaces TLS et crypto de Node restent la catégorie de CVE la plus volumineuse, et que l'habitude du projet de les bundler dans une seule release coordonnée est ce qui garde l'histoire de mise à jour simple pour les gens qui font tourner Node en production.
