n8n self-hosted sécurité : héberger vos automatisations sans ouvrir la porte aux hackers
Docker socket exposé, 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 certifiés OSCP/OSEP ont audité plus de 40 installations self-hosted. Cet articlé documente les vulnérabilités les plus fréquemment 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 données, pas de limitation de workflows, coûts maittrises. Mais dans 80% des installations que nous audittons, le port 5678 est accèssible directement depuis internet, les variables d'environnement contenant les clés API sont en clair dans un docker-compose.yml pousse sur GitHub, et l'image Docker n'a pas été mise à 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 privilèges via le Docker socket (comment un attaquant passe de n8n à root sur votre VPS en 30 secondes), les CVE connus a corriger en priorité, et une checklist de hardening complete. Il s'adresse aux CTO et DSI de PME qui déploient ou envisagent de déployer n8n en self-hosted sur leurs infrastructures parisiennes ou en region.
Le risque métier pour le CEO
Passer au self-hosted pour economiser des licences ou garantir la souverainete est une excellente idee financiere. Mais sans une configuration réseau etanche, vous transformez votre serveur en un point d'entree direct pour les ransomwares. Un n8n mal configuré exposé le socket Docker - ce qui signifie qu'un attaquant qui prend le contrôle de n8n prend le contrôle de tout votre VPS, de tous les containers qui tournent dessus, et de toutes les clés API, mots de passe et secrets stockés dans vos variables d'environnement. C'est tout votre réseau d'entreprise qui se retrouve exposé 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 majorité des installations que nous audittons. Elles resultent presque toutes du même point de depart : un tutoriel YouTube qui montre comment "faire tourner n8n en 5 minutes" sans jamais aborder la sécurité de production.
Erreur 1 - Port 5678 exposé directement sur internet
Le docker-compose.yml par defaut publié n8n sur 0.0.0.0:5678, ce qui le rend accèssible depuis n'importe quelle IP. Même avec l'authentification activee, n8n est directement attaquable par bruteforce, et chaque CVE de l'interface web devient immédiatement 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 contrôle n8n contrôle désormais 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 clés API, mots de passe de basé de données et tokens sont souvent places directement dans le fichier docker-compose.yml, qui finit pousse sur un dépôt GitHub "prive" - ou sur un dépôt public par erreur. Docker Secrets ou un fichier .env exclu du git via .gitignore sont les alternatives.
Erreur 4 - Pas d'isolation réseau entre containers
Sans configuration de réseau Docker explicite, tous les containers sur le même hote peuvent communiquer entre eux par defaut. Un n8n compromis peut alors atteindre la basé de données PostgreSQL, le container Redis, ou d'autres services internes qui n'ont aucune raison d'être accèssibles depuis n8n. Le principe de moindre privilège s'applique aussi aux réseaux de containers.
Erreur 5 - Webhooks publics sans validation de token
Les webhooks n8n générés automatiquement sont publics par defaut - n'importe qui connaissant l'URL peut les decléncher. Sans header d'authentification ou validation HMAC, un attaquant peut decléncher des workflows arbitrairement, potentiellement exfiltrer des données ou injecter des données malveillantes dans vos pipelines.
80%
des n8n self-hosted que nous auditons ont le port 5678 accèssible depuis internet
30s
temps nécessaire pour passer de n8n compromis à root sur le VPS via le Docker socket
8 mois
délai moyen entre la mise en prod et la dernière mise à 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 à root VPS en 30 secondes
C'est le scenario d'attaque le plus severe que nous demonstrons lors de nos audits de sécurité offensifs. Il nécessite deux conditions reunies : une interface n8n accèssible depuis internet (erreur 1) et le Docker socket monte dans le container (erreur 2). Ces deux conditions sont reunies dans une majorité des installations que nous voyons.
Schema 1 - Chaine d'escalade : n8n mal configuré → root VPS
La commande clé de cette escalade est simple et documentee publiquement depuis des années :
Ce que l'attaquant fait ensuite en moins de 2 minutes
Avec un accès root sur l'hote, l'attaquant lit tous les fichiers .env de tous les containers (clés AWS, Stripe, SendGrid, tokens Slack...), installe un backdoor persistant dans le crontab de l'hote, copie la basé de données n8n qui contient tous vos credentials de workflow, et peut déployer un ransomware qui chiffre l'integralite des volumes. Le tout sans decléncher la moindre alerte sur une infrastructure n8n standard non monitoree.
Le node "Exécuté Command" de n8n est aussi un vecteur d'accès direct - il permet d'exécuter 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 créé un workflow minimal et obtient un shell dans le container sans même avoir besoin du Docker socket.
3. CVE n8n connus et pourquoi ne pas mettre à jour est une faute
n8n est un projet actif avec des releases fréquentes. Chaque version corrige des vulnérabilités - dans n8n lui-même, mais aussi dans ses dependances Node.js embarquees. Un n8n "qui marche" non mis à jour depuis 6 mois est statistiquement vulnérable 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 exposés (metadata AWS, Redis, basés de données) en faisant faire des requêtes HTTP a n8n vers des adresses internes. | Exfiltration de données internes, pivot réseau |
| CVE-2023-27562 | CRITIQUE | Injection de commandes via certains nodes de type "Exécuté". Permet l'exécution de code arbitraire dans le container sans passer par le node "Exécuté Command" explicite. | RCE dans le container n8n |
| CVE-2023-26115 | ELEVE | Vulnérabilité ReDoS dans word-wrap, dependance embarquee. Permet un deni de service via des expressions regulieres malicieuses dans les inputs de workflow. | Deni de service, indisponibilité |
| CVE-2023-26136 | ELEVE | Prototype pollution dans tough-cookie (dependance axios). Peut permettre une escalade de privilèges dans certaines configurations ou un contournement de logique applicative. | Contournement logique, escalade potentielle |
| CVE-2022-31129 | MOYEN | ReDoS dans moment.js. Très répandu dans les versions antérieures a n8n 0.194. Deni de service via des inputs de date malformates dans les nodes de transformation. | Deni de service |
Comment vérifier votre version n8n et les CVE applicables
La frequence de mise à jour recommandee pour n8n en production est mensuelle pour les versions mineures (correctifs de sécurité) et trimestrielle pour les versions majeures (avec test prealable). L'équipe n8n publié des changelogs détaillés - les entrees marquees "security" sont à traitér en urgence dans les 72 heures.
Au-dela de n8n lui-même, l'image Docker de basé (node:18-alpine ou similaire) cumule également des CVE au fil du temps. Un docker pull de la même image plusieurs mois plus tard peut donner une image significativement plus sécurisée sans changer la version de n8n.
4. L'architecture n8n sécurisée : nginx + réseau Docker isolé + rootless
Voici l'architecture que nous recommandons et déployons pour nos clients. Elle applique le principe de defense en profondeur : chaque couche limité independamment les risques, de sorte qu'une compromission d'une couche ne suffise pas a compromettre l'ensemble.
Schema 2 - Architecture n8n self-hosted sécurisée
Voici la configuration nginx minimale de production qui implemente cette architecture :
5. Procedure de mise à jour n8n sans perte de données
La raison principale pour laquelle les PME ne mettent pas à jour n8n est la crainte de perdre des workflows. Cette crainte est infondee si la mise à jour est réalisée correctement - les données sont persistees dans un volume Docker qui survit à la mise à jour de l'image. Voici la procedure que nous appliquons en production pour nos clients.
Étape 1 - Backup prealable (2 minutes)
Étape 2 - Mise à jour de l'image (1 minute)
Étape 3 - Vérification post-update (5 minutes)
Nous recommandons d'activer les alertes de nouvelles releases n8n via GitHub (bouton Watch → Releases only sur le dépôt n8n-io/n8n). Les releases de sécurité sont taggees explicitement et doivent être traitées en priorité - généralement dans les 72h pour les CVE critiques, 2 semaines pour les autres.
Pour les PME qui déploient n8n dans le cadre d'une stratégie de gouvernance no-code et automatisation, nous recommandons de documenter la version n8n installee, la date de la dernière mise à jour, et les workflows critiques dans un registre de gouvernance - et de planifier les mises à jour comme n'importe quelle maintenance IT, pas comme un événement 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 présenté des risques significatifs.
✓ Reseau et exposition
- - Port 5678 lié à 127.0.0.1 uniquement (pas 0.0.0.0)
- - Reverse proxy nginx ou Traefik avec SSL actif
- - UFW configuré - seuls les ports 80/443/SSH autorisés
- - fail2ban installe et configuré 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 isolé avec bridge dédié
- - PostgreSQL non exposé sur un port public
- - --cap-drop ALL avec capabilities minimales
- - no-new-privilèges: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 générée aleatoirement (32 chars min)
- - Webhooks avec validation de token HMAC
- - Credentials n8n chiffres au repos
- - Pas de credentials en clair dans les nodes
✓ Mises à jour et monitoring
- - Alerte GitHub sur les releases n8n activee
- - Mise à 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 - Sécurité n8n self-hosted
Pourquoi n8n self-hosted est-il plus risque qu'une installation cloud ?
En cloud, n8n géré lui-même la sécurité de l'infrastructure, les mises à jour et l'isolation. En self-hosted, vous êtes responsable de tout : reverse proxy, pare-feu, isolation Docker, gestion des secrets, mises à jour. Une erreur de configuration exposé 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 sécurité.
Qu'est-ce que l'escalade de privilèges via le Docker socket ?
Le Docker socket (/var/run/docker.sock) est l'interface de contrôle du daemon Docker. Si ce socket est monte dans le container n8n, un attaquant qui compromet n8n peut créer un nouveau container --privileged et monter le système de fichiers de l'hote. En 30 secondes, il obtient un accès root complet au VPS, à tous les autres containers, et à toutes les variables d'environnement contenant vos secrets et clés 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 vulnérabilités dans les dependances Node.js embarquees (moment.js, axios, word-wrap) qui ne sont corrigees qu'en mettant à jour l'image Docker. Un n8n non mis à jour depuis 6 mois cumule statistiquement plusieurs vulnérabilités de severite haute ou critique.
Comment mettre à jour n8n sans perdre ses workflows ?
En 3 étapes : 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 à la mise à 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 être exposé directement sur internet. Il doit imperativement être place derriere un reverse proxy (nginx ou Traefik) qui géré le SSL/TLS, les headers de sécurité, le rate limiting et les règles de filtrage IP. Le port 5678 de n8n ne doit être accèssible 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 sécurité ?
2LKATIME audité et sécurisé les installations n8n self-hosted de PME parisiennes et en region. Nos auditeurs certifiés OSCP/OSEP appliquent les mêmes techniques qu'un attaquant réel : test du Docker socket, bruteforce des webhooks, tentatives d'injection via les nodes, analyse des variables d'environnement exposées. Rapport exécutif et technique avec plan de remédiation en 3 jours. Première consultation offerte.