Node.js 20 is EOL: 12 CVEs Unpatched, AWS Lambda August Deadline & Migration Guide to Node 22/24Node.js 20 en fin de vie : 12 CVE sans correctif, Déadline AWS Lambda août & Guide de Migration vers Node 22/24

Node.js 20 reached end-of-life on April 30, 2026. Since that date, no security patches, no CVE fixes, no official releases. If you are still running Node 20 in production, you are accumulating security debt at an accelerating rate. The proof arrived on June 18, 2026: the Node.js project patched 12 CVEs across its three active release lines — including two HIGH-severity vulnerabilities that every Node 20 server will never receive.

Node.js 20 a atteint sa fin de vie le 30 avril 2026. Depuis cette date : aucun correctif de sécurité, aucun fix de CVE, aucune release officielle. Si vous faites encore tourner Node 20 en production, vous accumulez une dette de sécurité à un rythme croissant. La preuve est arrivée le 18 juin 2026 : le projet Node.js a corrigé 12 CVE sur ses trois lignes de release actives — dont deux vulnérabilités HIGH que chaque serveur Node 20 ne recevra jamais.

For AWS Lambda teams, the urgency is doubly real: Lambda is about to block new Node 20 function creation on August 31, 2026 (61 days from now), and function updates on September 30, 2026. This guide covers what you are exposed to on Node 20 today, how to choose between Node 22 LTS and Node 24, every breaking change you will encounter, and a step-by-step migration checklist.

Pour les équipes AWS Lambda, l’urgence est doublement réelle : Lambda va bloquer la création de nouvelles fonctions Node 20 le 31 août 2026 (dans 61 jours), et les mises à jour de fonctions le 30 septembre 2026. Ce guide couvre ce à quoi vous êtes exposés sur Node 20 aujourd’hui, comment choisir entre Node 22 LTS et Node 24, chaque breaking change que vous allez rencontrer, et une checklist de migration étape par étape.

The 12 CVEs from June 18, 2026 That Node 20 Will Never Receive

Les 12 CVE du 18 juin 2026 que Node 20 ne recevra jamais

On June 18, 2026, the Node.js security team released patches for Node.js 22.23.0, 24.17.0, and 26.3.1 — 12 CVEs fixed in a single coordinated drop. Two are rated HIGH severity. Node 20, being end-of-life since April 30, received nothing. Here are the two vulnerabilities every Node 20 production server is currently exposed to:

Le 18 juin 2026, l’équipe sécurité Node.js a publié des correctifs pour Node.js 22.23.0, 24.17.0 et 26.3.1 — 12 CVE corrigées en un seul drop coordonné. Deux sont évaluées HIGH severity. Node 20, en fin de vie depuis le 30 avril, n’a rien reçu. Voici les deux vulnérabilités auxquelles chaque serveur Node 20 en production est actuellement exposé :

Beyond these two HIGH CVEs, the June 18 batch also patched an HTTP/2 ORIGIN frame memory exhaustion (unlimited frames cause OOM on the client), multiple TLS hostname normalization issues, and Permission Model bypasses. The January 2026 releases patched a symlink-based Permission Model escape that bypassed --allow-fs-read/--allow-fs-write restrictions. The March 2026 releases patched additional DoS and __proto__-header-based crashes. Node 20 received none of the fixes shipped after April 30.

Au-delà de ces deux CVE HIGH, le lot du 18 juin corrige aussi un épuisement mémoire HTTP/2 (frames ORIGIN illimitées provoquant un OOM côté client), plusieurs problèmes de normalisation TLS et des contournements du modèle de permissions. Les releases de janvier 2026 corrigeaient une échappement symlink contournant --allow-fs-read/--allow-fs-write. Les releases de mars 2026 corrigeaient des DoS supplémentaires et des crashes via header __proto__. Node 20 n’a reçu aucun de ces correctifs publiés après le 30 avril.

AWS Lambda Node 20 Deprecation: The Three Deadlines

Dépréciation AWS Lambda Node 20 : Les Trois Échéances

For serverless teams, the Node.js upstream EOL is only the start. AWS Lambda has its own three-phase deprecation schedule for nodejs20.x, and two of those three phases are still ahead of you:

Pour les équipes serverless, la fin de vie en amont Node.js n’est que le début. AWS Lambda a son propre calendrier de dépréciation en trois phases pour nodejs20.x, et deux de ces trois phases sont encore devant vous :

Phase 2 is the most disruptive for most teams: your deployment pipeline will start failing on August 31 if it creates or deploys Lambda functions using the nodejs20.x runtime. The typical migration lead time for a multi-function serverless application is 3–6 weeks including staging environment testing, dependency compatibility verification, and team review cycles. You are at the outer edge of that window now.

La phase 2 est la plus perturbatrice pour la plupart des équipes : votre pipeline de déploiement commencera à échouer le 31 août si il crée ou déploie des fonctions Lambda utilisant le runtime nodejs20.x. Le délai typique de migration pour une application serverless multi-fonctions est de 3 à 6 semaines incluant les tests en environnement de staging, la vérification de compatibilité des dépendances et les cycles de revue équipe. Vous êtes exactement à la limite de cette fenêtre maintenant.

Node 22 LTS vs Node 24: Which Should You Target?

Node 22 LTS vs Node 24 : Lequel Cibler ?

You have two migration targets. Here is how to choose:

Vous avez deux cibles de migration. Voici comment choisir :

Decision rule: If your Lambda functions use the classic callback pattern — exports.handler = (event, context, callback) => { callback(null, response); } — go to Node 22 first. Rewriting callbacks to async/await is the right thing to do, but it is a separate migration effort from the runtime upgrade. Don’t conflate them when you have a 61-day deadline. Upgrade to Node 22 now, schedule the async/await refactor for later, then evaluate Node 24 when Node 22 approaches EOL in 2027.

Règle de décision : Si vos fonctions Lambda utilisent le pattern callback classique — exports.handler = (event, context, callback) => { callback(null, response); } — allez d’abord sur Node 22. Récrire les callbacks en async/await est la bonne chose à faire, mais c’est un effort de migration séparé de la mise à niveau du runtime. Ne les mélangez pas quand vous avez une déadline de 61 jours. Passez sur Node 22 maintenant, planifiez le refactoring async/await plus tard, puis évaluez Node 24 quand Node 22 approchera de sa fin de vie en 2027.

Breaking Changes from Node.js 20 to Node.js 22

Breaking Changes de Node.js 20 vers Node.js 22

Most Node 20 to Node 22 migrations require only dependency updates and a build pipeline change. But four specific breaking changes can cause silent runtime failures if you don’t address them before switching:

La plupart des migrations Node 20 vers Node 22 ne nécessitent que des mises à jour de dépendances et un changement de pipeline de build. Mais quatre breaking changes spécifiques peuvent provoquer des échecs silencieux au runtime si vous ne les traitez pas avant de basculer :

1. ESM Import Assertions Removed — Use Import Attributes

1. Assertions d’import ESM supprimées — Utiliser les attributs d’import

The old assert keyword syntax for ESM imports was dropped entirely in Node.js 22.0.0. The replacement is with (import attributes):

L’ancienne syntaxe avec le mot-clé assert pour les imports ESM a été supprimée dans Node.js 22.0.0. Le remplacement est with (attributs d’import) :

// Node 20 — BREAKS on Node 22
import config from './config.json' assert { type: 'json' };

// Node 22+ — use import attributes
import config from './config.json' with { type: 'json' };

Grep your codebase for assert { type: before migrating. This will cause a syntax error on Node 22 at startup.

Cherchez dans votre code source assert { type: avant de migrer. Cela provoquera une erreur de syntaxe au démarrage sur Node 22.

2. crypto.createCipher / createDecipher Removed

2. crypto.createCipher / createDecipher supprimées

The deprecated crypto.createCipher and crypto.createDecipher APIs are gone in Node 22. You must use createCipheriv and createDecipheriv with an explicit IV:

Les API dépréciées crypto.createCipher et crypto.createDecipher ont été supprimées dans Node 22. Vous devez utiliser createCipheriv et createDecipheriv avec un IV explicite :

// Node 20 — REMOVED in Node 22
const cipher = crypto.createCipher('aes-256-cbc', password);

// Node 22+ — explicit IV required (more secure)
const iv = crypto.randomBytes(16);
const cipher = crypto.createCipheriv('aes-256-cbc', key, iv);

This is a security improvement — implicit IV derivation from passwords was weak. Search for createCipher( and createDecipher( in your codebase.

C’est une amélioration de sécurité — la dérivation implicite d’IV depuis des mots de passe était faible. Cherchez createCipher( et createDecipher( dans votre code.

3. Native Addons Need Recompilation (ABI Change)

3. Les addons natifs doivent être recompilés (changement d’ABI)

Node.js 22 bumped NODE_MODULE_VERSION to 127. Binary addons compiled against Node 20 (module version 115) are ABI-incompatible. Any package that ships precompiled binaries — bcrypt, sharp, canvas, sqlite3, better-sqlite3, node-sass, CPU-intensive native modules — must be rebuilt or upgraded to a version targeting Node 22. If you migrated native modules from prebuild-install to prebuildify for the npm v12 migration, those prebuilt binaries are already scoped to Node module versions — verify they include Node 22 artifacts.

Node.js 22 a incrémenté NODE_MODULE_VERSION à 127. Les addons binaires compilés pour Node 20 (version de module 115) ne sont pas compatibles ABI. Tout package qui livre des binaires précompilés — bcrypt, sharp, canvas, sqlite3, better-sqlite3, node-sass, modules natifs CPU-intensifs — doit être reconstruit ou mis à jour vers une version ciblant Node 22. Si vous avez migré vos modules natifs de prebuild-install vers prebuildify pour la migration npm v12, vérifiez que ces binaires précompilés incluent des artefacts Node 22.

4. Windows: .bat / .cmd Spawn Blocked

4. Windows : spawn de .bat / .cmd bloqué

Node.js 22.0.0 blocks direct spawning of .bat and .cmd files on Windows via child_process (addresses CVE-2024-27980). Any code passing a .bat path directly to spawn() must now explicitly invoke cmd.exe:

Node.js 22.0.0 bloque le spawn direct de fichiers .bat et .cmd sur Windows via child_process (corrige CVE-2024-27980). Tout code passant un chemin .bat directement à spawn() doit maintenant invoquer explicitement cmd.exe :

// Node 20 — BLOCKED on Node 22 (Windows)
child_process.spawn('build.bat', args);

// Node 22+ — explicit cmd.exe required
child_process.spawn('cmd.exe', ['/c', 'build.bat', ...args]);

5. Permission Model Flag Renamed

5. Flag du modèle de permissions renommé

The experimental Permission Model flag changed from --experimental-permission (Node 20) to simply --permission (Node 22+). If your startup scripts or process managers pass the old flag, update them. The Permission Model also gained tighter symlink handling in 2026 — processes with filesystem access now require explicit symlink resolution grants, which is relevant if you process file uploads via symbolic link paths.

Le flag expérimental du modèle de permissions a changé de --experimental-permission (Node 20) en simplement --permission (Node 22+). Si vos scripts de démarrage ou gestionnaires de processus passent l’ancien flag, mettez-les à jour. Le modèle de permissions a aussi gagné une gestion plus stricte des symlinks en 2026.

Step-by-Step Migration Checklist: Node 20 to Node 22

Checklist de Migration Étape par Étape : Node 20 vers Node 22

Follow this order for the lowest-risk migration. Estimated time: 1 day for a standard application, 1 week for a complex multi-service codebase.

Suivez cet ordre pour la migration à moindre risque. Temps estimé : 1 jour pour une application standard, 1 semaine pour une base de code multi-services complexe.

# Step 1 — Install Node 22 locally (use nvm or fnm)
nvm install 22
nvm use 22
node --version  # Should print v22.x.x

# Step 2 — Scan for removed/changed APIs
grep -r "assert { type:" . --include="*.js" --include="*.mjs" --include="*.ts"
grep -r "createCipher(" . --include="*.js" --include="*.ts"
grep -r "createDecipher(" . --include="*.js" --include="*.ts"

# Step 3 — Update .nvmrc / .node-version
echo "22" > .nvmrc

# Step 4 — Update engines field in package.json
# "engines": { "node": ">=22.0.0" }

# Step 5 — Reinstall dependencies (recompile native addons)
rm -rf node_modules
npm ci

# Step 6 — Run your test suite
npm test

# Step 7 — Verify native modules ABI
node -e "require('bcrypt')"         # or sharp, canvas, sqlite3, etc.
node -e "require('better-sqlite3')"

# Step 8 — Check WebCrypto usage (optional if you use subtle.encrypt)
grep -r "subtle.encrypt" . --include="*.js" --include="*.ts"
# Ensure input buffers are guarded against 2 GiB threshold

# Step 9 — Update CI/CD pipeline
# GitHub Actions example:
# uses: actions/setup-node@v4
# with:
#   node-version: '22'

# Step 10 — For AWS Lambda: update runtime identifier
# In your CDK/SAM/Serverless Framework config:
# runtime: nodejs22.x  (instead of nodejs20.x)

AWS Lambda: Updating the Runtime

AWS Lambda : Mettre à jour le runtime

# SAM template.yaml
Properties:
  Runtime: nodejs22.x   # was: nodejs20.x
  Handler: index.handler

# Serverless Framework serverless.yml
provider:
  runtime: nodejs22.x   # was: nodejs20.x

# AWS CDK (TypeScript)
new lambda.Function(this, 'MyFunction', {
  runtime: lambda.Runtime.NODEJS_22_X,  // was: NODEJS_20_X
  handler: 'index.handler',
  code: lambda.Code.fromAsset('lambda'),
});

After updating the runtime identifier, redeploy and verify your function invocations succeed in a staging environment before promoting to production. Pay particular attention to cold start times — Node 22 cold starts in Lambda are comparable to Node 20.

Après avoir mis à jour l’identifiant de runtime, redéployez et vérifiez que les invocations de votre fonction réussissent en environnement de staging avant de promouvoir en production. Accordez une attention particulière aux temps de cold start — les cold starts Node 22 dans Lambda sont comparables à Node 20.

EOL Software & Compliance: PCI-DSS, EU CRA and What Auditors Will Flag

Logiciel EOL & Conformité : PCI-DSS, EU CRA et ce que les auditeurs vont signaler

Running EOL software in production is not just a security risk — it is increasingly a compliance failure. Under PCI-DSS 4.0, Requirement 6.3.3 mandates that all software components be protected from known vulnerabilities via security patches. An EOL runtime that no longer receives patches fails this requirement automatically. HIPAA covered entities running Node 20 in healthcare systems face similar audit exposure. The EU Cyber Resilience Act (CRA), whose SBOM and patch reporting requirements take effect in September 2026, explicitly requires manufacturers to address known exploitable vulnerabilities in a timely manner. An EOL runtime with unfixed HIGH CVEs will be flagged.

Faire tourner des logiciels EOL en production n’est pas seulement un risque sécurité — c’est de plus en plus un échec de conformité. Sous PCI-DSS 4.0, la Requirement 6.3.3 exige que tous les composants logiciels soient protégés contre les vulnérabilités connues via des correctifs de sécurité. Un runtime EOL qui ne reçoit plus de patches échoue automatiquement à cette exigence. Le Règlement européen sur la résilience cybérnétique (CRA), dont les exigences SBOM et de reporting de patches entrent en vigueur en septembre 2026, exige explicitement que les fabricants traitent en temps voulu les vulnérabilités exploitées connues. Un runtime EOL avec des CVE HIGH non corrigées sera signalé.

Frequently Asked Questions

Questions fréquentes