Node.js 24.18.0 'Krypton' (LTS), publiée le 2026-06-23 à 23 h 11 UTC par @richardlau et préparée par @sxa, est la plus grosse release de la ligne v24 LTS depuis que cette ligne est passée en Active en octobre 2025. Elle livre huit changements SEMVER-MINOR : la valeur par défaut Buffer.poolSize à 64 Kio backportée depuis Current, TurboSHAKE et KangarooTwelve de la RFC 9861 ajoutés à Web Cryptography, http.writeInformation pour les codes 1xx arbitraires, le démarrage de la couverture précise de V8 exposé au runtime JS, et l'import-export JWK pour les familles de clés post-quantiques ML-KEM et SLH-DSA. Le même jour, Node.js 22.23.1 'Jod' (LTS) livre un suivi à deux commits de la release de sécurité v22.23.0 du 06-18, qui revient sur un changement d'agent http ayant déclenché un comportement inattendu de re-stream côté clients HTTP en production.
La release arrive sur la ligne LTS la même semaine que les releases de sécurité Node.js de juin 2026, et le timing est volontaire : la release de sécurité a corrigé 14 CVE sur v18, v20, v22 et v24 le 2026-06-18 (couvertes dans notre précédent article sur la sécurité Node.js), et la 24.18.0 est la prochaine release de fonctionnalité sur la ligne v24 que les utilisateurs en production peuvent absorber en une étape. Le correctif de suivi en v22.23.1 est la seconde moitié de la même semaine, puisque le fix de la v22.23.0 a produit un comportement stream inattendu en charge réelle et que l'équipe a choisi de revenir dessus en v22.23.1 plutôt que d'attendre la v22.24.0.
Buffer.poolSize : la valeur par défaut passe à 64 Kio
Le changement d'exécution le plus impactant est la hausse de la valeur par défaut Buffer.poolSize de 8 Kio à 64 Kio, contribué par Matteo Collina (#63597, 7 ajouts, 2 fichiers). Le test du pool slab est size < (Buffer.poolSize >>> 1), ce qui veut dire qu'avec la valeur par défaut de 8 Kio le seuil est de 4 Kio et que l'inégalité stricte fait qu'une allocation de 4 Kio manque elle-même le pool. La valeur par défaut actuelle aide les allocations de 1 octet à 3 999 octets, puis s'arrête brutalement à la frontière alignée sur la page et dimensionnée pour les trames HTTP, où tombent pourtant de nombreuses allocations réelles.
La description de la PR cite trois raisons au changement. La falaise des 4 Kio est la première. La deuxième est que la valeur par défaut est 8 Kio depuis mai 2015, ce qui prédate les tailles de trame 16 Kio à 1 Mio de HTTP/2, les tailles modernes de chunk de stream, et la croissance d'environ 10x de la RAM typique. La troisième est que de nombreux appels à Buffer.allocUnsafe dans le core (fs.readFileSync pour les lectures non-utf8, le parseur HTTP, les chunkers de stream) tombent dans la fourchette 4 Kio à 64 Kio et manquent le pool.
Le benchmark de la PR, exécuté sur 8 threads worker dans un même process sous Linux 6.8 avec glibc 2.39 sur un i7-7700, donne :
| Taille de fichier | pool 8 Kio (défaut) | pool 64 Kio | Δ |
|---|---|---|---|
| 512 B | 404k ops/s | 431k ops/s | +7 % |
| 2 Kio | 360k ops/s | 367k ops/s | ~ |
| 4 Kio | 326k ops/s | 360k ops/s | +10 % |
| 8 Kio | 202k ops/s | 254k ops/s | +26 % |
| 16 Kio | 148k ops/s | 181k ops/s | +23 % |
| 64 Kio | 86k ops/s | 87k ops/s | ~ |
| 1 Mio | 8,7k ops/s | 8,6k ops/s | ~ |
La nouvelle valeur par défaut de 64 Kio étend la couverture du pool aux allocations jusqu'à ~32 Kio. C'est la première fois que la valeur par défaut bouge depuis 2015. Le changement n'est pas cassant, il n'affecte que la valeur par défaut, et les applications peuvent toujours définir Buffer.poolSize manuellement. Le même changement a déjà été livré sur la ligne Current dans Node.js 26.3.0 le 2026-06-01 ; la 24.18.0 est la première fois qu'il arrive sur la ligne LTS. Le titre du précédent article est désormais aussi le titre de celui-ci pour les utilisateurs de la v24.
Web Cryptography gagne TurboSHAKE et KangarooTwelve
Le second titre est l'ajout de TurboSHAKE et KangarooTwelve (PR #62183, 1 521 ajouts, 13 fichiers, Filip Skokan) à l'API Web Cryptography. Les deux sont des fonctions de hachage à sortie extensible de la même famille de permutations Keccak que SHA-3 et SHAKE, standardisées dans la RFC 9861. Elles sont plus rapides que SHAKE sur les messages longs et les digests courts de longueur fixe ; KangarooTwelve est le mode tree-hash recommandé par l'IETF pour les applications à haut débit, et l'écosystème navigateur suit le même draft via la proposition WICG webcrypto-modern-algos.
L'implémentation Node.js est un port direct des primitives keccak1600 d'OpenSSL. Le travail est protégé par le drapeau unstable jusqu'à ce qu'OpenSSL livre un support natif pour les deux primitives ; à ce moment, les algorithmes passeront en stable dans node:crypto et la porte Web Crypto sera levée. La PR est l'une des premières fois que Node.js livre un algorithme Web Crypto avant la release OpenSSL qui le supporte, et le ticket amont openssl/openssl#30304 est le tracker qui commandera la stabilisation.
La release livre aussi un durcissement multi-PR de la stack Web Cryptography. La PR #63363 (Filip Skokan) durcit WebCrypto contre la pollution de prototype, refactore le chemin async vers un nouveau mode interne CryptoJob, passe directement les handles CryptoKey aux jobs KDF, et retire le mot-clé async des méthodes Web Crypto là où le travail est en fait synchrone en dessous. La PR #63255 (Filip Skokan) câble le build BoringSSL pour que ML-DSA, ML-KEM, ChaCha20-Poly1305 et AES-KW soient disponibles dans Web Cryptography quand Node.js est compilé contre BoringSSL. La PR #63111 resserre les slots d'algorithme CryptoKey et les slots internes KeyObject pour que les deux types ne puissent pas accidentellement partager d'état.
Support JWK post-quantique pour ML-KEM et SLH-DSA
La PR #62706 (842 ajouts, 39 fichiers, Filip Skokan) ajoute l'import-export JSON Web Key pour les familles de clés post-quantiques ML-KEM (anciennement Kyber) et SLH-DSA (anciennement Sphincs+), toutes deux sélectionnées par le NIST dans les FIPS 203 et 205. Les formats JWK suivent les drafts du LAMPS WG de l'IETF et les enregistrements JOSE.
Combiné au câblage ML-KEM et ML-DSA côté BoringSSL de la PR #63255, la partie Web Cryptography de Node.js est désormais alignée avec le travail post-quantique que la ligne Current porte depuis le début du cycle 26.x. Un même binaire Node.js peut désormais servir des JWK RSA, ECDSA, Ed25519, ML-KEM, ML-DSA et SLH-DSA dans le même namespace Web Crypto, ce qui compte pour le déploiement en production du TLS post-quantique : le même namespace crypto.subtle qu'un serveur utilise pour vérifier une signature RSA peut désormais vérifier une signature ML-DSA, et le même chemin importKey / exportKey qui gère un JWK P-256 peut désormais gérer un JWK ML-KEM-768.
La PR #62905 ajoute un garde séparé contre les key_ops JWK ML-KEM dupliqués, qui est le genre de cas limite qui remonte dans les tests d'interop avec les implémentations navigateur. La PR #62626 est un fix plus petit qui protège d'un overflow size_t sur l'architecture 32 bits expérimentale ; le changement s'inscrit dans la même famille que les fixes 64 bits livrés en 24.15.0.
http.writeInformation pour les codes 1xx arbitraires
La PR #63155 (306 ajouts, 7 fichiers, Tim Perry) ajoute response.writeInformation({ status, headers }), une API HTTP/1 générique pour envoyer des codes 1xx arbitraires. Le runtime exposait auparavant res.writeContinue pour le 100 et res.writeEarlyHints pour le 103, et c'était tout ; toute personne ayant besoin d'un 1xx personnalisé ou écrivant un proxy qui devait relayer un 1xx de l'upstream devait passer par la méthode privée res._writeRaw, ce que la description de la PR signale comme étant une pratique utilisée par la propre suite de tests de Node.js.
La nouvelle méthode reprend la forme de additionalHeaders côté HTTP/2 et supporte tout code 1xx sauf 101, qui change de protocole et reste géré par l'événement upgrade. Les writeContinue et writeEarlyHints existants sont refactorés au-dessus de la nouvelle méthode. Il y a une incohérence que la PR conserve en l'état : la branche H1 lève une exception si un statut final a déjà été envoyé, alors que la branche H2 est un no-op. La description de la PR signale cette incohérence comme candidate à un alignement dans un futur bump majeur.
Le fix clôt trois issues anciennes, #22624, #27921 et #7588, qui avaient été fermées en stale au fil des années faute d'API générale. Les auteurs de proxy disposent désormais d'une seule API qui marche pour les codes définis par l'IETF, les 1xx personnalisés et tout futur 1xx standardisé, sans avoir besoin d'une méthode par statut.
Couverture précise V8 exposée au runtime JS
Le travail de couverture précise inspector (commit 8c989ec4a3, sangwook, SEMVER-MINOR) est le plus petit titre de la release en nombre de lignes et le plus utile pour quiconque fait tourner de la couverture sur la ligne v24 LTS. Le changement expose le signal de démarrage de la couverture précise de V8 au runtime JS via un nouveau binding interne, si bien que node:inspector et le test runner peuvent tous les deux démarrer la couverture précise au runtime plutôt que seulement au bootstrap via NODE_V8_COVERAGE ou --experimental-test-coverage.
La PR complémentaire #63079 (sangwook) câble la même primitive dans l'API run() du test runner : run({ coverage: true, isolation: 'none' }) collecte maintenant correctement la couverture, et l'exclusion par défaut des fichiers de test est appliquée de manière cohérente entre la voie CLI et la voie API. La PR corrige un vrai bug dans test_runner où la voie API renvoyait une liste de fichiers vide parce que le drapeau de couverture V8 n'était positionné qu'au bootstrap.
Le changement fait partie du même travail de couverture précise qui a été livré progressivement en 24.16.0 et 24.17.0 ; la pièce 24.18.0 est l'exposition finale qui permet au code applicatif de démarrer la couverture à la demande. Pour les utilisateurs qui font tourner c8 ou nyc sur la ligne v24, cela veut dire que le chemin de couverture du test runner est désormais de première classe sur LTS.
L'annulation stream et le suivi v22.23.1
La release annule un changement de la 24.16.0 : la PR #63834 (Stewart X Addison) revient sur le changement 'stream: noop pause/resume on destroyed streams' livré le 2026-05-21. L'intention était de rendre le nettoyage des streams plus idempotent, mais des pipelines HTTP et de spawn de processus réels s'appuyaient sur le fait que pause() reste un no-op-puis-clean même après destroy, et le changement produisait des erreurs 'Cannot call method on destroyed stream' sur des chemins de code qui étaient corrects avant le changement.
Le même jour, Node.js 22.23.1 (16 h 44 UTC, @RafaelGSS) livre un suivi connexe : la PR #64004 (Matteo Collina) revient sur le changement d'agent http de la release de sécurité v22.23.0, qui ajoutait un listener de stream sur les sockets idle de l'agent et produisait en production un comportement inattendu de re-stream côté clients HTTP. Les utilisateurs de la 22.23.0 doivent passer en 22.23.1 ; le fix arrive en 24.18.0 au même moment, donc les utilisateurs de la 24.17.0 doivent passer en 24.18.0 pour récupérer à la fois l'annulation stream et l'annulation agent.
Les deux annulations sont sans rapport au niveau API mais sortent ensemble parce qu'elles ont toutes les deux été détectées en production la même semaine. Le calendrier de release Node.js 22 place la 22.x en Maintenance LTS jusqu'en octobre 2026, et le choix de l'équipe d'émettre un correctif 22.23.1 une semaine après plutôt que d'attendre la 22.24.0 reflète le fait que les branches LTS servent désormais de cibles de production pour des services longue durée.
Ce que la 24.18.0 ne change pas
La release ne change pas la version majeure de V8, la version majeure de libuv ni l'API publique des addons. La surface Node-API récupère la PR #62710 (Yilong Li), qui ajoute le support SharedArrayBuffer à napi_create_typedarray, un fix petit mais réel pour les modules natifs qui veulent exposer des vues SharedArrayBuffer à JS. Les propriétés Date de fs.Stats deviennent énumérables (PR #63328, Livia Medeiros), un fix ancien qui finit par s'aligner avec la spec. SQLite passe en 3.53.1 (PR #63217), simdjson en 4.6.4 (PR #62811), et npm en 11.16.0 (PR #63602). La release inclut aussi la PR #62612, qui ajoute les fichiers des assistants IA au .gitignore du repo ; un petit changement méta qui est en soi un signal de l'idée que se font les mainteneurs Node.js de la prochaine génération d'outillage contributeur.
Le calendrier complet de la ligne Node.js 24 LTS prévoit la maintenance Active LTS jusqu'en octobre 2027 et la Maintenance LTS jusqu'en octobre 2028. La 24.18.0 est la deuxième release de juin sur la ligne v24 et la première à livrer le travail Buffer pool et JWK post-quantique qui s'accumulait sur Current depuis deux mois.
