Node.js 22 Security Guide 2026: Stable Permission Model, 3 Bypass CVEs & Complete Hardening ChecklistGuide Sécurité Node.js 22 en 2026 : Permission Model Stable, 3 CVE de Bypass & Checklist de Durcissement Complète

If you followed our Node.js 20 EOL article and migrated to Node.js 22, here is what you actually gained from a security perspective. Node.js 22 shipped three landmark security features: a Permission Model promoted to Stability 2 (Stable) in v22.13.0, a native WebSocket client stable since v22.4.0, and the Web Crypto API available globally without any import. These reduce your attack surface at the runtime level — independently of your application code.

Si vous avez suivi notre article sur l’EOL Node.js 20 et migré vers Node.js 22, voici ce que vous avez concrètement gagné en sécurité. Node.js 22 a livré trois fonctionnalités de sécurité majeures : un Permission Model promu en Stabilité 2 (Stable) depuis la v22.13.0, un client WebSocket natif stable depuis la v22.4.0, et la Web Crypto API accessible globalement sans aucun import. Ces éléments réduisent votre surface d’attaque au niveau du runtime — indépendamment du code applicatif.

The June 18, 2026 security release complicated the picture: 12 CVEs were patched across Node 22.x (now at v22.23.0), including two HIGH-severity issues and three vulnerabilities that bypass the Permission Model you may have just deployed. This article explains exactly what Node 22 secures, what remains bypassable, and a complete hardening checklist for Node.js 22 in production.

La release de sécurité du 18 juin 2026 a nuancé le tableau : 12 CVE ont été corrigées sur Node 22.x (maintenant en v22.23.0), dont deux problèmes de sévérité HIGH et trois vulnérabilités qui contournent le Permission Model que vous venez peut-être de déployer. Cet article explique exactement ce que Node 22 sécurise, ce qui reste bypassable, et une checklist de durcissement complète pour Node.js 22 en production.

Node.js 22 in July 2026: Maintenance LTS, Not Active LTS

Node.js 22 en Juillet 2026 : Maintenance LTS, Pas Active LTS

An important clarification for teams planning migrations: as of October 2025, Node.js 22 moved from Active LTS to Maintenance LTS. This means it receives security patches and critical bug fixes only — no new features. Node.js 24, which entered Active LTS in October 2025 (codename Krypton), is the version that gets new backports and extended security investment.

Une clarification importante pour les équipes qui planifient des migrations : depuis octobre 2025, Node.js 22 est passé de Active LTS à Maintenance LTS. Cela signifie qu’il ne reçoit que des correctifs de sécurité et correctifs critiques — pas de nouvelles fonctionnalités. Node.js 24, entré en Active LTS en octobre 2025 (nom de code Krypton), est la version qui reçoit les nouveaux backports et l’investissement sécurité étendu.

The practical consequence: if you migrated from Node 20 to Node 22 last month, you are on a supported, patched runtime. But if you are starting a new project in July 2026, Node 24 is the better target — it gets backports, ships npm v12 natively, has built-in TypeScript type stripping, and OpenSSL 3.5 with post-quantum algorithms. We cover the Node 22 vs Node 24 decision in detail below.

La conséquence pratique : si vous avez migré de Node 20 vers Node 22 le mois dernier, vous êtes sur un runtime supporté et corrigé. Mais si vous démarrez un nouveau projet en juillet 2026, Node 24 est la meilleure cible — il reçoit les backports, livre npm v12 nativement, dispose du stripping de types TypeScript intégré, et d’OpenSSL 3.5 avec les algorithmes post-quantiques. Nous détaillons le choix Node 22 vs Node 24 ci-dessous.

The Permission Model Goes Stable: What It Actually Restricts

Le Permission Model Passe en Stable : Ce Qu’Il Restreint Concrètement

Node.js 22.13.0 (released January 2026) promoted the Permission Model from Active Development (experimental) to Stability 2: Stable. The flag changed from --experimental-permission to simply --permission. This is the biggest security architecture shift since Node.js introduced support for ES modules: it allows you to run untrusted third-party code with explicit, narrowly scoped access grants.

Node.js 22.13.0 (publié en janvier 2026) a promu le Permission Model de Active Development (expérimental) à Stabilité 2 : Stable. Le flag est passé de --experimental-permission à simplement --permission. Il s’agit du plus grand changement d’architecture de sécurité depuis l’introduction des modules ES dans Node.js : il vous permet d’exécuter du code tiers non fiable avec des accès explicitement et étroitement délimités.

The Permission Model controls access to five categories of system resources:

Le Permission Model contrôle l’accès à cinq catégories de ressources système :

A basic locked-down Node.js 22 invocation for a web server that reads only from /app and writes to /tmp:

Une invocation Node.js 22 basique et verrouillée pour un serveur web qui lit uniquement depuis /app et écrit dans /tmp :

node --permission \
  --allow-fs-read=/app \
  --allow-fs-read=/usr/local/lib/node_modules \
  --allow-fs-write=/tmp \
  --allow-net=0.0.0.0:3000 \
  server.js

You can also check permissions at runtime using the process.permission API, which was added alongside the model:

Vous pouvez également vérifier les permissions à l’exécution avec l’API process.permission, ajoutée en même temps que le modèle :

// Check before performing a sensitive operation
if (!process.permission.has('fs.write', '/etc/passwd')) {
  console.log('Write to /etc/passwd: DENIED (as expected)');
}

// Deny read to arbitrary paths
if (!process.permission.has('fs.read', '/home/ubuntu/.ssh')) {
  console.log('SSH key read: DENIED');
}

The model eliminates approximately 92% of the file system and network exfiltration vectors that malicious npm packages exploit — without any runtime overhead for operations within the allowed paths. However, three June 2026 CVEs demonstrate it is not infallible.

Le modèle élimine environ 92% des vecteurs d’exfiltration de système de fichiers et de réseau exploités par les packages npm malveillants — sans aucune surcharge d’exécution pour les opérations dans les chemins autorisés. Cependant, trois CVE de juin 2026 montrent qu’il n’est pas infaillible.

June 2026 Security Release: 12 CVEs in Node 22.23.0

Release de Sécurité Juin 2026 : 12 CVE dans Node 22.23.0

On June 18, 2026, the Node.js project released v22.23.0, v24.17.0, and v26.3.1 to address 12 CVEs spanning the WebCrypto, TLS, HTTP/2, HTTP, DNS, and Permission Model subsystems. If you are running an older Node 22.x release, update immediately to v22.23.0 — the two HIGH-severity issues allow unauthenticated attackers to crash your process.

Le 18 juin 2026, le projet Node.js a publié les versions v22.23.0, v24.17.0 et v26.3.1 pour corriger 12 CVE couvrant les sous-systèmes WebCrypto, TLS, HTTP/2, HTTP, DNS et Permission Model. Si vous exécutez une ancienne version Node 22.x, mettez à jour immédiatement vers v22.23.0 — les deux problèmes HIGH permettent à des attaquants non authentifiés de faire crasher votre processus.

CVE-2026-48618: TLS Wildcard Certificate Bypass (CVSS 7.7 HIGH)

CVE-2026-48618 : Bypass Certificat TLS Wildcard (CVSS 7.7 HIGH)

This is the highest-priority fix in the June 2026 batch. Node.js's TLS certificate verification code failed to correctly handle Unicode normalization for wildcard certificates (*.example.com). An attacker who controls a subdomain could craft a hostname that, after Unicode normalization, resolves to a different domain — bypassing the wildcard check. This is classified as CWE-176 (Improper Handling of Unicode Encoding). Multi-tenant SaaS applications performing TLS hostname verification for customer-supplied endpoints are the most exposed.

Il s’agit du correctif prioritaire du lot de juin 2026. Le code de vérification des certificats TLS de Node.js ne gérait pas correctement la normalisation Unicode pour les certificats wildcard (*.example.com). Un attaquant contrôlant un sous-domaine pouvait créer un nom d’hôte qui, après normalisation Unicode, résolvait vers un domaine différent — contournant la vérification wildcard. Cela est classé CWE-176 (Gestion incorrecte de l’encodage Unicode). Les applications SaaS multi-locataires effectuant une vérification de nom d’hôte TLS pour des endpoints fournis par les clients sont les plus exposées.

CVE-2026-48933: WebCrypto 2 GiB Process Crash (HIGH)

CVE-2026-48933 : Crash de Processus WebCrypto 2 Gio (HIGH)

The built-in WebCrypto API (crypto.subtle.encrypt()) has an integer overflow when the input buffer is a multiple of 2 GiB. The integer arithmetic for the buffer length wraps around, triggering a native crash that brings down the entire Node.js process. Any application that accepts user-supplied data as input to WebCrypto operations — file encryption services, content pipelines, media processors — is vulnerable if it does not validate input size before calling subtle.encrypt().

L’API WebCrypto intégrée (crypto.subtle.encrypt()) présente un débordement d’entier lorsque le tampon d’entrée est un multiple de 2 Gio. L’arithmétique entière pour la longueur du tampon déborde, déclenchant un crash natif qui fait tomber tout le processus Node.js. Toute application acceptant des données fournies par l’utilisateur comme entrée dans les opérations WebCrypto — services de chiffrement de fichiers, pipelines de contenu, processeurs média — est vulnérable si elle ne valide pas la taille de l’entrée avant d’appeler subtle.encrypt().

// Mitigation: validate input size before WebCrypto operations
const MAX_ENCRYPT_SIZE = 512 * 1024 * 1024; // 512 MB hard limit

async function safeEncrypt(key, data) {
  if (data.byteLength >= MAX_ENCRYPT_SIZE) {
    throw new RangeError(`Input too large: ${data.byteLength} bytes`);
  }
  return crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, data);
}

3 Permission Model Bypass CVEs: What They Mean in Practice

3 CVE de Bypass du Permission Model : Ce Que Cela Signifie Concrètement

All three Permission Model bypass CVEs from June 2026 are rated LOW severity. They matter because they affect users who specifically deployed --permission to sandbox dependencies. The bypasses are narrow and require specific conditions, but each one represents a gap in the containment boundary.

Les trois CVE de bypass du Permission Model de juin 2026 sont toutes classées en sévérité LOW. Elles importent car elles affectent les utilisateurs qui ont spécifiquement déployé --permission pour backer les dépendances. Les contournements sont étroits et nécessitent des conditions spécifiques, mais chacun représente une lacune dans la frontière de confinement.

CVE-2026-48617 — process.report.writeReport() path misvalidation: When the diagnostic reporting API (process.report.writeReport('/arbitrary/path/report.json')) was called with an absolute path, the permission model did not validate the target path against the --allow-fs-write allowlist. Malicious code could write a diagnostic report to any filesystem location, even if that location was not in the write allowlist.

CVE-2026-48617 — process.report.writeReport() mauvaise validation du chemin : Lorsque l’API de rapport de diagnostic (process.report.writeReport('/chemin/arbitraire/rapport.json')) était appelée avec un chemin absolu, le Permission Model ne validait pas le chemin cible par rapport à la liste d’autorisation --allow-fs-write. Du code malveillant pouvait écrire un rapport de diagnostic à n’importe quel emplacement du système de fichiers, même si cet emplacement n’était pas dans la liste d’autorisation d’écriture.

CVE-2026-48935 — FileHandle.chmod/chown incomplete permission check: This is an incomplete fix for CVE-2024-36137. The promises API's FileHandle.chmod() and FileHandle.chown() methods were missing permission checks. Code running under --permission with restricted --allow-fs-write could still modify file metadata (permissions, ownership) on any path. The callback-based fs.chmod() was fixed; the promise-based FileHandle variant was not.

CVE-2026-48935 — FileHandle.chmod/chown vérification de permission incomplète : Il s’agit d’un correctif incomplet pour CVE-2024-36137. Les méthodes FileHandle.chmod() et FileHandle.chown() de l’API promises manquaient de vérifications de permission. Du code exécuté sous --permission avec --allow-fs-write restreint pouvait quand même modifier les métadonnées de fichiers (permissions, propriété) sur n’importe quel chemin. La variante basée sur les callbacks fs.chmod() était corrigée ; la variante promise via FileHandle ne l’était pas.

CVE-2026-48936 — Unix domain socket bypass (incomplete CVE-2026-21636 fix): Code running under --permission without the --allow-net flag could still create a Unix Domain Socket (UDS) server. UDS sockets create local IPC endpoints accessible to other processes on the same machine, which is a network-equivalent communication channel. This could allow malicious dependency code to establish a backdoor IPC channel despite the network permission being denied.

CVE-2026-48936 — Bypass socket Unix (correctif incomplet de CVE-2026-21636) : Du code exécuté sous --permission sans le flag --allow-net pouvait quand même créer un serveur Unix Domain Socket (UDS). Les sockets UDS créent des points de terminaison IPC locaux accessibles aux autres processus sur la même machine, ce qui est un canal de communication équivalent réseau. Cela pouvait permettre à du code de dépendance malveillant d’établir un canal IPC backdoor malgré le refus de la permission réseau.

All three are fixed in Node.js 22.23.0. If you are using --permission on any older 22.x release, these bypasses may be exploitable by compromised dependencies. Update immediately.

Les trois sont corrigées dans Node.js 22.23.0. Si vous utilisez --permission sur une ancienne version 22.x, ces contournements peuvent être exploités par des dépendances compromises. Mettez à jour immédiatement.

Key Security Features Node.js 22 Adds Over Node.js 20

Fonctionnalités de Sécurité Clés qu’Ajoute Node.js 22 par Rapport à Node.js 20

1. Native WebSocket Client (Stable since v22.4.0)

1. Client WebSocket Natif (Stable depuis v22.4.0)

Node.js 22.4.0 stabilized the built-in WebSocket client, removing the need for third-party packages like ws or socket.io-client for outbound WebSocket connections. From a supply chain perspective, each third-party package is a potential attack vector — eliminating ws for outbound connections removes one dependency from your threat surface. The built-in implementation is spec-compliant with the WHATWG WebSocket standard and shares the same TLS stack as the rest of Node.js (meaning CVE-2026-48618 is patched there too).

Node.js 22.4.0 a stabilisé le client WebSocket intégré, éliminant le besoin de packages tiers comme ws ou socket.io-client pour les connexions WebSocket sortantes. Du point de vue de la chaîne d’approvisionnement, chaque package tiers est un vecteur d’attaque potentiel — éliminer ws pour les connexions sortantes supprime une dépendance de votre surface de menace. L’implémentation intégrée est conforme au standard WHATWG WebSocket et partage la même pile TLS que le reste de Node.js (ce qui signifie que CVE-2026-48618 y est également corrigé).

// No import needed — WebSocket is a global in Node.js 22+
const ws = new WebSocket('wss://api.example.com/stream');

ws.addEventListener('open', () => {
  ws.send(JSON.stringify({ type: 'subscribe', channel: 'alerts' }));
});

ws.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
  // handle message
});

2. Web Crypto API as a Global (No Import Required)

2. Web Crypto API en Global (Aucun Import Nécessaire)

Since Node.js 19, globalThis.crypto has been available without any import. In Node.js 22, this is fully stable and the preferred way to do cryptographic operations. The advantage over the legacy node:crypto module: it uses the same API as browsers, making cross-platform code portable, and it avoids the require('node:crypto') pattern that can be accidentally bundled with deprecated algorithms.

Depuis Node.js 19, globalThis.crypto est disponible sans aucun import. Dans Node.js 22, c’est totalement stable et la manière préférée d’effectuer des opérations cryptographiques. L’avantage par rapport au module hérité node:crypto : il utilise la même API que les navigateurs, rendant le code multiplateforme portable, et évite le pattern require('node:crypto') qui peut être accidentellement bundlé avec des algorithmes dépréciés.

// Modern Node.js 22 Web Crypto — no require() needed
async function deriveKey(password, salt) {
  const keyMaterial = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(password),
    'PBKDF2',
    false,
    ['deriveKey']
  );
  return crypto.subtle.deriveKey(
    { name: 'PBKDF2', salt, iterations: 310000, hash: 'SHA-256' },
    keyMaterial,
    { name: 'AES-GCM', length: 256 },
    false,
    ['encrypt', 'decrypt']
  );
}

3. ESM require() — Eliminating Dynamic Import Footguns

3. ESM require() — Éliminer les Pièges des Imports Dynamiques

Node.js 22 stabilized synchronous require() inside ES modules (previously you had to use await import() and deal with asynchronous module loading). This eliminates a class of race condition vulnerabilities that arose when code used import() dynamically to load sensitive modules — the async gap between resolution and execution could be exploited in certain threading scenarios. With synchronous require() in ESM, the module is loaded atomically.

Node.js 22 a stabilisé require() synchrone dans les modules ES (avant, il fallait utiliser await import() et gérer le chargement asynchrone des modules). Cela élimine une classe de vulnérabilités de conditions de course qui apparaissaient lorsque le code utilisait import() dynamiquement pour charger des modules sensibles — le délai asynchrone entre la résolution et l’exécution pouvait être exploité dans certains scénarios de threading. Avec require() synchrone dans ESM, le module est chargé de manière atomique.

4. Built-in Test Runner with Security Test Patterns

4. Test Runner Intégré avec Patterns de Tests de Sécurité

The node:test module in Node.js 22 supports coverage reporting, custom reporters, and mock timers out of the box — eliminating jest or mocha for many projects. From a supply chain perspective, removing a test framework dependency eliminates a significant attack vector: test packages have historically been heavily targeted by supply chain attackers because they run during npm install (postinstall hooks) and are present in every developer's machine.

Le module node:test dans Node.js 22 supporte les rapports de couverture, les reporters personnalisés et les mocks de timers par défaut — éliminant jest ou mocha pour de nombreux projets. Du point de vue de la chaîne d’approvisionnement, supprimer une dépendance de framework de test élimine un vecteur d’attaque significatif : les packages de test ont historiquement été très ciblés par les attaquants car ils s’exécutent lors de npm install (hooks postinstall) et sont présents sur chaque machine de développeur.

Node 22 vs Node 24 in July 2026: Which Should You Run?

Node 22 vs Node 24 en Juillet 2026 : Lequel Devez-Vous Exécuter ?

If you just migrated from Node 20, the answer depends on your situation. Node 22 (Maintenance LTS, supported until April 2027) is the safe, low-risk choice for existing production workloads — it receives security patches and critical bug fixes, and your migration is already done. Node 24 (Active LTS, codename Krypton, supported until April 2028) is the better choice for new projects or teams with bandwidth for a second migration.

Si vous venez de migrer depuis Node 20, la réponse dépend de votre situation. Node 22 (Maintenance LTS, supporté jusqu’à avril 2027) est le choix sûr et à faible risque pour les charges de travail de production existantes — il reçoit des correctifs de sécurité et des correctifs critiques, et votre migration est déjà faite. Node 24 (Active LTS, nom de code Krypton, supporté jusqu’à avril 2028) est le meilleur choix pour les nouveaux projets ou les équipes disposant de la bande passante pour une seconde migration.

Our recommendation: Stay on Node 22 if you just migrated and your workloads are stable — you have until April 2027 before EOL. Plan a migration to Node 24 for Q1 2027, or sooner if you need OpenSSL 3.5 post-quantum support or npm v12 natively bundled. If you are starting a new project today, start on Node 24.

Notre recommandation : Restez sur Node 22 si vous venez de migrer et que vos charges de travail sont stables — vous avez jusqu’à avril 2027 avant l’EOL. Planifiez une migration vers Node 24 pour le T1 2027, ou plus tôt si vous avez besoin du support post-quantique OpenSSL 3.5 ou de npm v12 bundlé nativement. Si vous démarrez un nouveau projet aujourd’hui, commencez sur Node 24.

Node.js 22 Security Hardening Checklist

Checklist de Durcissement Sécurité Node.js 22

A complete security checklist for Node.js 22 applications in production:

Une checklist de sécurité complète pour les applications Node.js 22 en production :

Frequently Asked Questions

Questions Fréquentes