n8n « Ni8mare » (CVE-2026-21858) : une faille CVSS 10.0 livre 100 000 serveurs d'automatisation sans mot de passe

Imaginez un serveur qui orchestre vos automatisations : il lit vos emails, écrit dans votre base de données, déploie du code, poste sur vos réseaux, et détient les clés d'API de la moitié de votre infrastructure. Maintenant, imaginez qu'un attaquant puisse en prendre le contrôle total sans le moindre identifiant, juste en envoyant une requête HTTP bien formée. C'est exactement ce que permet Ni8mare, la faille CVE-2026-21858 notée 10.0 sur 10 au CVSS, qui a laissé environ 100 000 serveurs n8n grands ouverts.

Cet article décortique la vulnérabilité, sa chaîne d'exploitation complète jusqu'au remote code execution, et surtout : comment savoir si vous êtes exposé et comment vous protéger. Parce qu'une instance n8n compromise, ce n'est pas un serveur perdu — c'est, selon les mots des chercheurs de Cyera, « les clés de tout ».

n8n : pourquoi cette cible est si juteuse

n8n est une plateforme open source d'automatisation de workflows (un concurrent self-hostable de Zapier/Make). On la déploie le plus souvent via Docker, sur un VPS ou un homelab, et on la connecte à tout : APIs SaaS, bases de données, serveurs SSH, webhooks entrants. C'est précisément cette position de hub central qui en fait une cible de rêve.

Une instance n8n stocke, en clair ou déchiffrables, les credentials de tous les services connectés. La compromettre, c'est obtenir un pivot vers l'ensemble de l'écosystème qu'elle pilote. Et comme beaucoup d'instances exposent leurs webhooks ou formulaires directement sur Internet (c'est leur fonction première : recevoir des données externes), la surface d'attaque est massive.

Ni8mare (CVE-2026-21858) : l'anatomie de la faille

Découverte par Cyera et divulguée en janvier 2026, Ni8mare est une RCE non authentifiée. La racine du problème est une « Content-Type Confusion » dans le traitement des webhooks.

Concrètement : la fonction qui gère les soumissions de formulaire (formWebhook()) invoque une fonction de manipulation de fichiers (copyBinaryFile()) qui agit sur req.body.files sans avoir vérifié au préalable que le Content-Type de la requête est bien multipart/form-data. En envoyant un Content-Type différent avec un corps malicieux, l'attaquant écrase des variables internes (req.body.files) et obtient une primitive de lecture de fichier arbitraire sur le système.

Une lecture de fichier arbitraire, ça paraît « limité ». Sauf que sur n8n, c'est le premier maillon d'une chaîne qui mène tout droit au contrôle total.

La chaîne d'exploitation, étape par étape

Voici comment on passe d'une simple lecture de fichier à une exécution de code complète — un enchaînement qui mérite d'être étudié tant il est propre :

1. Lecture de la base de données. Avec la primitive de lecture arbitraire, l'attaquant récupère /home/node/.n8n/database.sqlite et en extrait l'ID, l'email et le hash du mot de passe de l'administrateur.
2. Vol de la clé de chiffrement. Il lit ensuite /home/node/.n8n/config pour récupérer la clé secrète de chiffrement (celle qui protège les credentials des services connectés).
3. Forge d'un cookie de session (contournement d'authentification). Avec l'ID admin et la clé secrète, il forge un cookie de session valide et obtient un accès administrateur — sans jamais connaître le mot de passe.
4. RCE via le node « Execute Command ». Devenu admin, il crée un nouveau workflow contenant un node Execute Command et exécute des commandes arbitraires sur le serveur.

Lecture de fichier → vol de secrets → bypass d'auth → RCE. Chaque maillon est anodin pris isolément ; mis bout à bout, c'est une prise de contrôle complète depuis Internet, sans authentification. C'est l'illustration parfaite de pourquoi une « simple » lecture de fichier doit toujours être traitée comme critique.

Ni8mare n'était que le début : la série de CVE du T1 2026

Ce qui rend l'épisode n8n exemplaire, c'est qu'il ne s'agit pas d'une faille isolée mais d'une vague. Rapid7 a regroupé plusieurs de ces vulnérabilités sous les noms « Ni8mare » et « N8scape » :

• CVE-2026-21877 (CVSS 10.0) — RCE authentifiée : sous certaines conditions, un utilisateur authentifié peut faire exécuter du code arbitraire par le service. Corrigée en 1.121.3 (créditée à Théo Lelasseux).
• CVE-2025-68613, 68668, 68697 — failles authentifiées chaînables avec la RCE non authentifiée CVE-2026-21858 pour de l'exécution de code ou de l'écriture de fichier arbitraire.
• CVE-2026-27493 (mars 2026) — un bug de « double évaluation » dans les nodes Form : les endpoints de formulaire étant publics par conception (ni auth, ni compte requis), il suffit de soumettre un payload dans le champ Name d'un formulaire « Contact » public pour exécuter des commandes shell. Brutal de simplicité.
• CVE-2026-27577 — une évasion de sandbox dans le compilateur d'expressions : un cas manquant dans le réécriture de l'AST laisse process passer sans transformation, donnant un RCE à toute expression authentifiée.

Six CVE critiques en un trimestre sur le même produit, ça raconte une histoire : les plateformes d'automatisation self-hosted sont une surface d'attaque encore largement sous-estimée, et leur sécurité n'a pas suivi leur explosion d'adoption.

Suis-je vulnérable ? (le seul chiffre qui compte)

La version corrigeant Ni8mare seule est la 1.121.0. Mais pour être protégé contre l'ensemble des CVE divulguées (la vague complète), il faut être sur :

• n8n 2.14.1 ou supérieur, ou
• n8n 1.123.27 ou supérieur (branche LTS)

Toute version antérieure est vulnérable à au moins une de ces failles. Si vous tournez via Docker (le cas le plus courant), vérifiez immédiatement votre version :

# Version de l'image en cours d'exécution
docker exec -it n8n n8n --version

# Ou via l'API (sans shell dans le conteneur)
curl -s https://VOTRE-INSTANCE/healthz/readiness

# Mise à jour (exemple docker compose)
docker compose pull && docker compose up -d
docker exec -it n8n n8n --version  # confirmer >= 2.14.1

Détection : que chercher dans vos logs

Si votre instance a été exposée non patchée, partez du principe qu'elle a pu être touchée et cherchez les indices suivants :

• Requêtes vers vos endpoints /webhook ou /form avec un Content-Type inhabituel (autre que multipart/form-data sur une soumission de fichier).
• Création de workflows non sollicités, surtout contenant un node Execute Command ou Code.
• Accès en lecture à database.sqlite ou au fichier config dans /home/node/.n8n/.
• Connexions admin sans échec de login préalable (signature d'un cookie forgé plutôt que d'un brute-force).
• Processus enfants anormaux issus du conteneur n8n (un monitoring runtime eBPF type Falco est idéal pour les repérer).

Remédiation et durcissement durable

Patcher est nécessaire mais pas suffisant — surtout si l'instance a pu être compromise. Plan d'action :

1. Patcher immédiatement vers 2.14.1+ / 1.123.27+. Il n'existe aucun contournement fiable pour Ni8mare.
2. Si exposition possible : rotation totale des secrets. Une instance compromise a livré la clé de chiffrement et donc tous les credentials des services connectés. Régénérez la clé, et faites tourner chaque token/API key/mot de passe connecté. Notre guide secrets management (Vault, External Secrets) détaille la marche à suivre.
3. Ne jamais exposer n8n directement sur Internet. Placez l'interface et les endpoints derrière une authentification forte, un reverse-proxy avec restriction d'accès, ou un VPN. Seuls les webhooks strictement nécessaires devraient être joignables, idéalement filtrés.
4. Segmentation réseau. L'instance ne devrait pouvoir atteindre que les systèmes qu'elle pilote réellement — pas tout le LAN. C'est le principe même d'une architecture Zero Trust.
5. Moindre privilège sur les comptes connectés. Chaque credential stocké dans n8n devrait avoir le périmètre minimal. Si l'instance tombe, l'impact est borné.
6. Isolation du conteneur. Faites tourner n8n via Docker avec un utilisateur non-root, un système de fichiers en lecture seule là où c'est possible, et pas de socket Docker monté.

La leçon : automatisation rime avec surface d'attaque

L'affaire n8n est un cas d'école qui dépasse le produit lui-même. Les outils d'automatisation — n8n, mais aussi les serveurs CI/CD, les orchestrateurs, les agents IA — concentrent par nature un pouvoir et des secrets disproportionnés. Ce sont des cibles à haute valeur qu'on déploie souvent avec la désinvolture d'un outil interne, exposés sur Internet « le temps d'un test » qui devient permanent.

La règle est simple : tout ce qui automatise et détient des credentials doit être traité comme un actif critique — patché en priorité, isolé, surveillé, et jamais exposé sans contrôle d'accès. Ni8mare n'a fait que rappeler, avec un CVSS de 10.0, ce que la rigueur opérationnelle aurait dû imposer dès le départ.