n8n self-hosted securite : heberger vos automatisations sans ouvrir la porte aux hackers
Docker socket expose, port 5678 ouvert, CVE non patches : comment une installation n8n "qui marche" peut devenir le point d'entree d'un ransomware.
Analyse 2LKATIME - Base d'audit de 40+ installations n8n self-hosted en PME
2LKATIME accompagne des PME et ETI sur leurs projets d'automatisation n8n depuis 2024. Nos auditeurs certifies OSCP/OSEP ont audite plus de 40 installations self-hosted. Cet article documente les vulnerabilites les plus frequemment trouvees en audit - des erreurs de configuration courantes qui transforment un outil d'automatisation en porte d'entree pour les attaquants.
n8n self-hosted est une excellente solution : souverainete des donnees, pas de limitation de workflows, couts maittrises. Mais dans 80% des installations que nous audittons, le port 5678 est accessible directement depuis internet, les variables d'environnement contenant les cles API sont en clair dans un docker-compose.yml pousse sur GitHub, et l'image Docker n'a pas ete mise a jour depuis 8 mois. Chacune de ces erreurs suffit a compromettre l'ensemble de votre infrastructure.
Ce guide couvre les 5 erreurs de configuration les plus critiques, la chaine d'escalade de privileges via le Docker socket (comment un attaquant passe de n8n a root sur votre VPS en 30 secondes), les CVE connus a corriger en priorite, et une checklist de hardening complete. Il s'adresse aux CTO et DSI de PME qui deploient ou envisagent de deployer n8n en self-hosted sur leurs infrastructures parisiennes ou en region.
Le risque metier pour le CEO
Passer au self-hosted pour economiser des licences ou garantir la souverainete est une excellente idee financiere. Mais sans une configuration reseau etanche, vous transformez votre serveur en un point d'entree direct pour les ransomwares. Un n8n mal configure expose le socket Docker - ce qui signifie qu'un attaquant qui prend le controle de n8n prend le controle de tout votre VPS, de tous les containers qui tournent dessus, et de toutes les cles API, mots de passe et secrets stockes dans vos variables d'environnement. C'est tout votre reseau d'entreprise qui se retrouve expose pour une simple erreur de parametrage.
1. Les 5 erreurs de configuration n8n self-hosted les plus critiques
Ces cinq erreurs ne sont pas theoriques - elles apparaissent dans la majorite des installations que nous audittons. Elles resultent presque toutes du meme point de depart : un tutoriel YouTube qui montre comment "faire tourner n8n en 5 minutes" sans jamais aborder la securite de production.
Erreur 1 - Port 5678 expose directement sur internet
Le docker-compose.yml par defaut publie n8n sur 0.0.0.0:5678, ce qui le rend accessible depuis n'importe quelle IP. Meme avec l'authentification activee, n8n est directement attaquable par bruteforce, et chaque CVE de l'interface web devient immediatement exploitable depuis internet.
Erreur 2 - Docker socket monte dans le container
Pour que n8n puisse piloter d'autres containers, certains tutoriels recommandent de monter /var/run/docker.sock dans le container n8n. C'est une erreur fatale : quiconque controle n8n controle desormais l'ensemble du daemon Docker de l'hote. Voir section 3 pour la chaine d'exploitation complete.
Erreur 3 - Secrets en clair dans docker-compose.yml
Les cles API, mots de passe de base de donnees et tokens sont souvent places directement dans le fichier docker-compose.yml, qui finit pousse sur un depot GitHub "prive" - ou sur un depot public par erreur. Docker Secrets ou un fichier .env exclu du git via .gitignore sont les alternatives.
Erreur 4 - Pas d'isolation reseau entre containers
Sans configuration de reseau Docker explicite, tous les containers sur le meme hote peuvent communiquer entre eux par defaut. Un n8n compromis peut alors atteindre la base de donnees PostgreSQL, le container Redis, ou d'autres services internes qui n'ont aucune raison d'etre accessibles depuis n8n. Le principe de moindre privilege s'applique aussi aux reseaux de containers.
Erreur 5 - Webhooks publics sans validation de token
Les webhooks n8n generes automatiquement sont publics par defaut - n'importe qui connaissant l'URL peut les declencher. Sans header d'authentification ou validation HMAC, un attaquant peut declencher des workflows arbitrairement, potentiellement exfiltrer des donnees ou injecter des donnees malveillantes dans vos pipelines.
80%
des n8n self-hosted que nous auditons ont le port 5678 accessible depuis internet
30s
temps necessaire pour passer de n8n compromis a root sur le VPS via le Docker socket
8 mois
delai moyen entre la mise en prod et la derniere mise a jour d'un n8n self-hosted PME
12+
CVE documentes sur n8n et ses dependances depuis 2022
2. La chaine d'escalade Docker : de n8n compromis a root VPS en 30 secondes
C'est le scenario d'attaque le plus severe que nous demonstrons lors de nos audits de securite offensifs. Il necessite deux conditions reunies : une interface n8n accessible depuis internet (erreur 1) et le Docker socket monte dans le container (erreur 2). Ces deux conditions sont reunies dans une majorite des installations que nous voyons.
Schema 1 - Chaine d'escalade : n8n mal configure → root VPS
La commande cle de cette escalade est simple et documentee publiquement depuis des annees :
Ce que l'attaquant fait ensuite en moins de 2 minutes
Avec un acces root sur l'hote, l'attaquant lit tous les fichiers .env de tous les containers (cles AWS, Stripe, SendGrid, tokens Slack...), installe un backdoor persistant dans le crontab de l'hote, copie la base de donnees n8n qui contient tous vos credentials de workflow, et peut deployer un ransomware qui chiffre l'integralite des volumes. Le tout sans declencher la moindre alerte sur une infrastructure n8n standard non monitoree.
Le node "Execute Command" de n8n est aussi un vecteur d'acces direct - il permet d'executer des commandes shell arbitraires dans le container. Si l'authentification n8n est faible (mot de passe simple, pas de 2FA, session sans expiration), un attaquant cree un workflow minimal et obtient un shell dans le container sans meme avoir besoin du Docker socket.
3. CVE n8n connus et pourquoi ne pas mettre a jour est une faute
n8n est un projet actif avec des releases frequentes. Chaque version corrige des vulnerabilites - dans n8n lui-meme, mais aussi dans ses dependances Node.js embarquees. Un n8n "qui marche" non mis a jour depuis 6 mois est statistiquement vulnerable a plusieurs CVE de severite haute ou critique.
| CVE | Severite | Description | Impact |
|---|---|---|---|
| CVE-2024-39338 | CRITIQUE | SSRF via les webhooks n8n. Permet d'atteindre des services internes non exposes (metadata AWS, Redis, bases de donnees) en faisant faire des requetes HTTP a n8n vers des adresses internes. | Exfiltration de donnees internes, pivot reseau |
| CVE-2023-27562 | CRITIQUE | Injection de commandes via certains nodes de type "Execute". Permet l'execution de code arbitraire dans le container sans passer par le node "Execute Command" explicite. | RCE dans le container n8n |
| CVE-2023-26115 | ELEVE | Vulnerabilite ReDoS dans word-wrap, dependance embarquee. Permet un deni de service via des expressions regulieres malicieuses dans les inputs de workflow. | Deni de service, indisponibilite |
| CVE-2023-26136 | ELEVE | Prototype pollution dans tough-cookie (dependance axios). Peut permettre une escalade de privileges dans certaines configurations ou un contournement de logique applicative. | Contournement logique, escalade potentielle |
| CVE-2022-31129 | MOYEN | ReDoS dans moment.js. Tres repandu dans les versions anterieures a n8n 0.194. Deni de service via des inputs de date malformates dans les nodes de transformation. | Deni de service |
Comment verifier votre version n8n et les CVE applicables
La frequence de mise a jour recommandee pour n8n en production est mensuelle pour les versions mineures (correctifs de securite) et trimestrielle pour les versions majeures (avec test prealable). L'equipe n8n publie des changelogs detailles - les entrees marquees "security" sont a traiter en urgence dans les 72 heures.
Au-dela de n8n lui-meme, l'image Docker de base (node:18-alpine ou similaire) cumule egalement des CVE au fil du temps. Un docker pull de la meme image plusieurs mois plus tard peut donner une image significativement plus securisee sans changer la version de n8n.
4. L'architecture n8n securisee : nginx + reseau Docker isole + rootless
Voici l'architecture que nous recommandons et deployons pour nos clients. Elle applique le principe de defense en profondeur : chaque couche limite independamment les risques, de sorte qu'une compromission d'une couche ne suffise pas a compromettre l'ensemble.
Schema 2 - Architecture n8n self-hosted securisee
Voici la configuration nginx minimale de production qui implemente cette architecture :
5. Procedure de mise a jour n8n sans perte de donnees
La raison principale pour laquelle les PME ne mettent pas a jour n8n est la crainte de perdre des workflows. Cette crainte est infondee si la mise a jour est realisee correctement - les donnees sont persistees dans un volume Docker qui survit a la mise a jour de l'image. Voici la procedure que nous appliquons en production pour nos clients.
Etape 1 - Backup prealable (2 minutes)
Etape 2 - Mise a jour de l'image (1 minute)
Etape 3 - Verification post-update (5 minutes)
Nous recommandons d'activer les alertes de nouvelles releases n8n via GitHub (bouton Watch → Releases only sur le depot n8n-io/n8n). Les releases de securite sont taggees explicitement et doivent etre traitees en priorite - generalement dans les 72h pour les CVE critiques, 2 semaines pour les autres.
Pour les PME qui deploient n8n dans le cadre d'une strategie de gouvernance no-code et automatisation, nous recommandons de documenter la version n8n installee, la date de la derniere mise a jour, et les workflows critiques dans un registre de gouvernance - et de planifier les mises a jour comme n'importe quelle maintenance IT, pas comme un evenement ponctuel.
6. Checklist hardening n8n self-hosted
Cette checklist est celle que nous utilisons lors de nos audits n8n. Cochez chaque point - si vous avez plus de 3 cases non cochees, votre installation presente des risques significatifs.
✓ Reseau et exposition
- - Port 5678 lie a 127.0.0.1 uniquement (pas 0.0.0.0)
- - Reverse proxy nginx ou Traefik avec SSL actif
- - UFW configure - seuls les ports 80/443/SSH autorises
- - fail2ban installe et configure pour n8n et SSH
- - Rate limiting sur le reverse proxy (max 20 req/min/IP)
- - Restriction IP sur l'interface admin si possible
✓ Docker et isolation
- - Docker socket NON monte dans le container n8n
- - Container n8n tourne en user non-root (uid 1000)
- - Reseau Docker isole avec bridge dedie
- - PostgreSQL non expose sur un port public
- - --cap-drop ALL avec capabilities minimales
- - no-new-privileges:true dans security_opt
✓ Secrets et authentification
- - Fichier .env exclu du git via .gitignore
- - Mot de passe n8n fort (16+ chars, generateur)
- - N8N_ENCRYPTION_KEY generee aleatoirement (32 chars min)
- - Webhooks avec validation de token HMAC
- - Credentials n8n chiffres au repos
- - Pas de credentials en clair dans les nodes
✓ Mises a jour et monitoring
- - Alerte GitHub sur les releases n8n activee
- - Mise a jour planifiee mensuelle (ou sous 72h si CVE critique)
- - Backup quotidien automatise des workflows et DB
- - Logs centralises et alertes sur erreurs
- - Version n8n et date de MAJ documentees
- - Procedure de restauration testee
FAQ - Securite n8n self-hosted
Pourquoi n8n self-hosted est-il plus risque qu'une installation cloud ?
En cloud, n8n gere lui-meme la securite de l'infrastructure, les mises a jour et l'isolation. En self-hosted, vous etes responsable de tout : reverse proxy, pare-feu, isolation Docker, gestion des secrets, mises a jour. Une erreur de configuration expose non seulement n8n, mais potentiellement tout votre VPS et les services qui y tournent. La plupart des PME installent n8n en suivant un tutoriel YouTube sans prendre en compte ces aspects securite.
Qu'est-ce que l'escalade de privileges via le Docker socket ?
Le Docker socket (/var/run/docker.sock) est l'interface de controle du daemon Docker. Si ce socket est monte dans le container n8n, un attaquant qui compromet n8n peut creer un nouveau container --privileged et monter le systeme de fichiers de l'hote. En 30 secondes, il obtient un acces root complet au VPS, a tous les autres containers, et a toutes les variables d'environnement contenant vos secrets et cles API.
Quels sont les CVE critiques connus pour n8n ?
Les plus significatifs : CVE-2024-39338 (SSRF via webhooks), CVE-2023-27562 (injection de commandes avec RCE possible), et plusieurs vulnerabilites dans les dependances Node.js embarquees (moment.js, axios, word-wrap) qui ne sont corrigees qu'en mettant a jour l'image Docker. Un n8n non mis a jour depuis 6 mois cumule statistiquement plusieurs vulnerabilites de severite haute ou critique.
Comment mettre a jour n8n sans perdre ses workflows ?
En 3 etapes : 1) Sauvegarder avec docker exec n8n n8n export:workflow --backup, 2) Copier le backup hors du container, 3) docker compose pull && docker compose up -d. Les workflows et credentials survivent a la mise a jour car ils sont persistes dans un volume Docker independant de l'image. Il est recommande de tester d'abord sur un environnement de pre-production pour les versions majeures.
Faut-il exposer n8n directement sur internet ?
Non. n8n ne doit jamais etre expose directement sur internet. Il doit imperativement etre place derriere un reverse proxy (nginx ou Traefik) qui gere le SSL/TLS, les headers de securite, le rate limiting et les regles de filtrage IP. Le port 5678 de n8n ne doit etre accessible qu'en local (127.0.0.1). Les webhooks publics doivent passer par le reverse proxy avec validation de token.
Votre n8n self-hosted passerait-il un audit de securite ?
2LKATIME audite et securise les installations n8n self-hosted de PME parisiennes et en region. Nos auditeurs certifies OSCP/OSEP appliquent les memes techniques qu'un attaquant reel : test du Docker socket, bruteforce des webhooks, tentatives d'injection via les nodes, analyse des variables d'environnement exposees. Rapport executif et technique avec plan de remediation en 3 jours. Premiere consultation offerte.