La surface RCE récurrente de n8n : un hub d'automatisation qui détient toutes vos clés

En bref Sur le premier semestre 2026, n8n — une plateforme de workflows open source très utilisée pour bâtir des agents et des automatisations pilotés par des LLM — a corrigé une série continue de failles critiques d’exécution de code à distance : une chaîne de lecture de fichiers non authentifiée divulguée en janvier 2026, une famille d’évaluation d’expressions retravaillée au printemps, puis un lot de juin 2026 ajoutant une évasion du sandbox du nœud Python et un chemin de prototype pollution vers la RCE. Aucune n’est exotique isolément. Ensemble, elles illustrent un problème structurel : un hub d’automatisation qui détient l’ensemble de vos secrets est une cible de première valeur, et chaque bug frappe le même magasin de secrets partagé. Ceci est un décryptage de classe de vulnérabilités, pas un mode d’emploi d’exploitation.

De quoi s’agit-il ?

n8n est un moteur d’automatisation de workflows auto-hébergeable — une colle qui relie votre Google Drive, vos clés d’API OpenAI ou Anthropic, Salesforce, vos bases de données, vos processeurs de paiement, votre CI/CD, et de plus en plus des nœuds d’agents LLM qui appellent des outils et des modèles à votre place. Une centaine de milliers d’instances sont joignables sur l’Internet public, et les chercheurs d’eSecurity Planet en ont dénombré plus de 103 000 exposées à au moins une faille récente.

Si n8n revient si souvent dans les advisories, ce n’est pas qu’il serait particulièrement mal écrit. C’est qu’un moteur de workflows est, par conception, une machine à transformer une entrée fournie par l’attaquant en logique évaluée et en appels d’API sortants, tout en trônant sur le magasin de secrets le plus sensible de l’entreprise. Au premier semestre 2026, le projet a livré des correctifs pour plusieurs causes racines distinctes — une confusion de content-type menant à des lectures de fichiers arbitraires (divulguée en janvier 2026 par Cyera Research Labs sous le nom « Ni8mare »), une série d’évasions de l’évaluation d’expressions corrigées et re-corrigées au printemps, une faille globale de prototype pollution atteignable via un paramètre de pagination non validé, et une évasion du sandbox du nœud de code Python publiée en juin. Des bugs différents, un seul rayon d’impact.

Comment ça marche

Il n’y a pas ici un payload unique ; il y a une forme qui se répète. À travers ces failles, le schéma ressemble à ceci :

Le motif RCE de n8n (conceptuel, expurgé)
-----------------------------------------
1. Un point d'entrée accepte une entrée non fiable
   (webhook de formulaire, paramètre de requête HTTP, champ de workflow)
2. Cette entrée atteint une surface d'évaluation
   - valeurs préfixées pour être traitées comme une expression -> double évaluation
   - un nœud de code dont le sandbox ne contraint pas totalement le runtime
   - un chemin de fusion d'objets qui pollue un prototype partagé
3. L'évaluation produit lectures de fichiers, fuite de config/secrets ou exécution de code
4. Ce que l'attaquant atteint, il atteint le magasin de secrets
   -> tokens d'API, autorisations OAuth, connexions BDD, clé secrète de l'instance

La chaîne de janvier a été la plus bruyante car elle n’exigeait aucune authentification : une requête au mauvais content-type était traitée par la mauvaise routine, ce qui permettait à un appelant non authentifié de lire des fichiers locaux — dont la clé secrète de l’instance et la base des utilisateurs — puis de forger une session d’administrateur et d’ajouter un nœud d’exécution de commandes. Les problèmes de juin sont plus étroits : ils exigent en général un compte authentifié disposant du droit d’éditer les workflows, ce qui les cantonne à un abus interne ou à une session d’éditeur volée. Mais « plus étroit » est relatif quand un seul éditeur compromis peut faire sortir un nœud Python de son sandbox vers le conteneur du task runner, ou polluer un prototype jusqu’à l’exécution de code hôte. La famille de l’évaluation d’expressions est la plus instructive : n8n traite comme une expression à évaluer une valeur de champ commençant par un préfixe précis, et dès lors que la donnée utilisateur est évaluée plutôt que lue, seul le sandbox se dresse entre cela et la RCE — sandbox désormais franchi à plus d’une reprise.

Pourquoi c’est important

La leçon n’est pas « n8n est dangereux », c’est « les plateformes d’orchestration sont porteuses de charge, et nous continuons à les sécuriser comme de simples applications web ». Un hub d’automatisation IA concentre l’autorité comme un contrôleur de domaine concentre l’identité : chaque workflow que vous construisez lui confie un secret de longue durée de plus, de sorte que la valeur d’une seule RCE croît avec chaque intégration ajoutée. Comme le résume Cyera, une instance compromise ne signifie pas perdre un système — mais livrer les clés de tout ce qui y est branché.

Cela compte davantage, et non moins, à mesure que ces plateformes se dotent de nœuds d’agents. Un nœud LLM transforme documents récupérés, sorties d’outils et messages de chat en un canal d’entrée non fiable de plus, alimentant les mêmes surfaces d’évaluation et de secrets. L’injection de prompt indirecte et l’injection d’expression classique finissent par rimer : dans les deux cas, « une donnée contrôlée par l’attaquant atteint un endroit où elle est interprétée ». Quand l’interpréteur repose sur votre magasin de secrets, le plafond de sévérité, c’est tout l’environnement.

Défenses

1. Patchez agressivement et suivez la branche, pas une version. n8n rétroporte ses correctifs sur plusieurs lignes de version (par exemple le correctif d’évasion de sandbox de juin a atterri sur les branches 1.123.x, 2.21.x et 2.22.x). Épinglez le dernier patch de votre branche et surveillez directement les advisories de sécurité du projet, les notes de version étant volontairement retardées.
2. Sortez-le de l’Internet public. Le nombre d’instances exposées est le vrai sujet. Placez n8n derrière un ingress authentifié ou un VPN ; un hub d’automatisation n’a rien à faire accessible au monde entier.
3. Appliquez le moindre privilège aux éditeurs. La plupart des failles de juin exigent le droit d’édition de workflows. Restreignez qui peut créer ou modifier des workflows, auditez l’historique des changements, et traitez le droit d’édition comme une autorisation sensible, pas un réglage par défaut.
4. Contraignez et isolez les nœuds de code/d’expression. Désactivez les nœuds Python et Form/Code lorsqu’ils sont inutiles (via la configuration d’exclusion de nœuds), faites tourner les task runners dans un segment réseau isolé et appliquez un filtrage de sortie pour qu’une évasion de sandbox ne puisse ni téléphoner à l’extérieur ni atteindre des services internes.
5. Faites tourner et compartimentez les secrets. Supposez qu’une compromission du hub équivaut à une perte totale des secrets : cantonnez les tokens, préférez des identifiants à durée de vie courte, alertez sur les connexions sortantes inattendues du runner, et faites tourner tout ce que n8n pourrait lire en cas de suspicion d’abus.

Statut

Élément	Référence	Date	Notes
Lecture de fichiers non authentifiée → RCE (« Ni8mare »)	CVE-2026-21858 (Cyera)	2026-01-07	CVSS 10.0 ; confusion de content-type, corrigé en 1.121.0 (nov. 2025)
Évasion de l’évaluation d’expressions → RCE	CVE-2025-68613 et suites	2026 (re-patché)	Éditeur de workflow authentifié ; expression traitée comme du code
Prototype pollution → RCE	CVE-2026-44789	2026-06	CVSS 9.4 ; paramètre de pagination non validé dans le nœud HTTP Request
Évasion du sandbox du nœud Python	CVE-2026-49444	2026-06-23	CWE-20 ; éditeur authentifié s’échappe vers le conteneur task runner ; corrigé 1.123.48 / 2.21.8 / 2.22.4
Exposition	eSecurity Planet	2026	~103 000 instances joignables et affectées par une faille récente

Le cadrage honnête, c’est qu’aucun de ces bugs n’est une attaque inédite. Ce sont les modes de défaillance les plus anciens du logiciel web — confusion de parseur, entrée évaluée, sandbox faibles, prototype pollution — qui atterrissent sur une infrastructure dont tout le rôle est de détenir vos secrets et d’agir en votre nom. C’est précisément pourquoi ils font régulièrement l’actualité, et précisément pourquoi le hub d’automatisation mérite la même méfiance que vous accorderiez à un contrôleur de domaine.