CVE-2026-21877 : pourquoi ce score CVSS 9.9 est justifié
La vulnérabilité est classée CWE-434 — téléversement de fichier de type dangereux sans restriction. Le nœud Git de n8n permet, sous certaines conditions, à un utilisateur authentifié d'écrire un fichier arbitraire sur le système de fichiers du serveur. Un attaquant peut écrire un script dans un répertoire exécuté par le processus n8n, puis le déclencher via un workflow pour obtenir une exécution de code à distance.
Le vecteur d'attaque est réseau, sans interaction utilisateur supplémentaire requise. La portée change (scope: Changed), ce qui signifie que l'impact dépasse le processus n8n : confidentialité, intégrité et disponibilité de l'hôte sont toutes compromises. L'EPSS atteint 5,449 % (92e percentile), ce qui indique une probabilité élevée d'exploitation dans les 30 jours.
L'alerte AL26-001 du Centre canadien pour la cybersécurité couvre également CVE-2026-21858 (validation d'entrée insuffisante sur les webhooks, CVSS 10.0 selon certaines sources) et CVE-2025-68613 (isolation insuffisante des expressions dans les configurations de workflows). Les trois doivent être considérées dans le même périmètre de remédiation.
Qui est exposé et dans quelle plage de versions
- Toutes les instances self-hosted de n8n >= 0.123.0 et < 1.121.3 sont vulnérables à CVE-2026-21877 selon l'advisory GitHub GHSA-v364-rw7m-3263.
- Les instances derrière un reverse proxy ne sont pas protégées : la vulnérabilité est authentifiée, un compte compromis ou un collaborateur interne suffisent — le périmètre réseau ne change pas l'exposition.
- Les déploiements Docker et npm sont tous deux concernés : le vecteur est le nœud Git, présent dans toutes les distributions de n8n quelle que soit la méthode d'installation.
- Les instances n8n Cloud gérées par n8n.io ont reçu le patch sans action requise de l'opérateur.
- CVE-2025-68613 couvre les versions 0.211.0 à < 1.120.4 : si vous n'avez pas encore atteint 1.120.4, vous êtes exposé aux deux CVE simultanément.
- CVE-2026-21858 affecte les versions 1.65.0 à < 1.121.0 : la mise à jour vers 1.121.3 couvre les trois CVE en un seul geste.
- Le score EPSS à 5,449 % place cette CVE dans le 92e percentile de probabilité d'exploitation active, ce qui justifie la priorité de patch sur l'ensemble des autres maintenances planifiées.
Vérifier la version de votre instance n8n
Avant d'appliquer le patch, identifiez précisément la version en cours. Trois méthodes selon votre contexte de déploiement.
Via l'interface web : connectez-vous à votre instance, cliquez sur l'icône de profil en bas à gauche, puis sur « About n8n ». La version s'affiche dans la fenêtre modale.
Via Docker : la commande docker inspect <nom-du-conteneur> --format '{{index .Config.Labels "org.opencontainers.image.version"}}' retourne la version de l'image en cours d'exécution. Si le conteneur a été démarré à partir de l'image n8nio/n8n:latest, cette valeur est celle qui comptait au moment du docker pull.
Via l'API interne : un curl http://localhost:5678/healthz sur l'hôte retourne {"status":"ok"} avec la version dans les en-têtes si l'instance est en cours d'exécution.
Si votre version est inférieure à 1.121.3, appliquez la procédure ci-dessous sans attendre la prochaine fenêtre de maintenance.
Procédure de mise à jour vers n8n ≥ 1.121.3
Sauvegarder la base de données et les fichiers de configuration
Avant toute mise à jour, sauvegardez l'état courant. Pour une installation Docker Compose, exportez la base SQLite ou PostgreSQL selon votre configuration :
# SQLite (chemin par défaut) cp ~/.n8n/database.sqlite ~/.n8n/database.sqlite.bak-$(date +%Y%m%d) # PostgreSQL pg_dump -U n8n -d n8n > n8n-backup-$(date +%Y%m%d).sqlCopiez également votre fichier
docker-compose.ymlet votre fichier.envdans un répertoire de sauvegarde.Mettre à jour le fichier docker-compose.yml
Si vous utilisez l'image
n8nio/n8n:latest, aucune modification du fichierdocker-compose.ymln'est requise. Si vous avez épinglé une version explicite (par exemplen8nio/n8n:1.115.0), mettez à jour la ligneimage:services: n8n: image: n8nio/n8n:1.121.3Si vous souhaitez suivre la branche stable à long terme, utiliser un tag de version explicite est préférable à
latestpour contrôler les fenêtres de mise à jour.Télécharger la nouvelle image
Depuis le répertoire contenant votre
docker-compose.yml:docker compose pullCette commande télécharge uniquement les couches de l'image qui ont changé. Pour un lien montant à 100 Mbit/s, comptez 30 à 90 secondes selon votre cache local.
Arrêter l'instance en cours
docker compose downL'arrêt est propre : n8n attend la fin des exécutions en cours avant de s'arrêter, sauf si vous ajoutez
--timeout 0. Sur une instance très chargée, préférez attendre que les workflows actifs se terminent avant d'exécuter cette commande, ou suspendez les workflows critiques depuis l'interface.Redémarrer avec la nouvelle image
docker compose up -dDocker Compose utilise la nouvelle image téléchargée. Le démarrage prend habituellement 10 à 20 secondes. Le log de démarrage doit afficher la version 1.121.3 ou supérieure.
Vérifier la version déployée
docker compose logs n8n | grep -i 'version\|n8n@'Ou via l'API interne, depuis l'hôte :
curl -s http://localhost:5678/healthzConfirmez que la version affichée dans l'interface (icône de profil → About n8n) est bien 1.121.3 ou supérieure avant de considérer la mise à jour comme appliquée.
Désactiver le nœud Git si vous ne l'utilisez pas
La variable d'environnement
EXECUTIONS_DATA_PRUNE=truen'est pas liée à ce vecteur. Pour neutraliser le vecteur d'attaque immédiatement sans attendre la mise à jour (par exemple en cas d'impossibilité de fenêtre de maintenance), désactivez le nœud Git via la variable d'environnement :N8N_NODES_EXCLUDE='["n8n-nodes-base.git"]'Ajoutez cette variable dans votre fichier
.envet redémarrez l'instance. Ce n'est pas un substitut à la mise à jour : appliquez le patch dès que possible.Pour une installation npm (sans Docker)
npm update -g n8n # Ou, si vous utilisez un gestionnaire de processus : pm2 stop n8n npm update -g n8n pm2 start n8nVérifiez la version installée avec
n8n --version. La migration vers Docker est recommandée pour les nouvelles installations — le guide dédién8n-migration-npm-docker-avant-v3couvre ce parcours en détail.
Durcissement post-patch : réduire la surface d'attaque
La mise à jour corrige la vulnérabilité connue, mais plusieurs configurations renforcent la posture globale de l'instance.
Restreignez les permissions du processus n8n. Le conteneur ne doit pas tourner en tant que root. L'image officielle utilise l'utilisateur node par défaut depuis plusieurs versions — vérifiez que votre docker-compose.yml ne contient pas user: root.
Activez l'authentification. Si votre instance est exposée sur Internet sans authentification, ajoutez N8N_BASIC_AUTH_ACTIVE=true et des credentials forts, ou placez l'instance derrière un proxy qui exige une authentification. CVE-2026-21877 est authentifiée, mais d'autres vecteurs non authentifiés existent dans l'écosystème.
Limitez les nœuds autorisés. La variable N8N_NODES_INCLUDE permet de n'autoriser qu'un sous-ensemble de nœuds. Sur les instances dédiées à des workflows sans besoin d'accès Git ou système, une liste d'inclusion réduit la surface.
Auditez les comptes utilisateurs. Dans l'interface d'administration, vérifiez que chaque compte actif est légitime et que les comptes de test ou d'anciens collaborateurs sont désactivés.
Abonnez-vous aux alertes de sécurité n8n. Le dépôt GitHub n8n-io/n8n permet de s'abonner aux notifications de sécurité via « Watch → Security alerts ».
Bug de scheduling après la version 2.21.7 : symptôme et contournement
L'issue GitHub #31100 documente un comportement signalé après la mise à jour vers la version 2.21.7 : des workflows à déclenchement planifié (nœud Schedule Trigger) cessent de s'exécuter à leur heure, sans message d'erreur visible dans les logs.
Symptôme exact : les workflows restent en état « actif » dans l'interface, le prochain déclenchement prévu est affiché, mais les exécutions n'ont pas lieu. Le journal d'exécutions ne montre aucune tentative avortée — les workflows ne sont tout simplement pas déclenchés. Ce comportement est observé principalement sur les déploiements en mode queue (multi-workers), avec PostgreSQL, mais peut aussi affecter des instances mono-processus.
Ce que l'issue indique sur le contournement : au moment de la publication de cet article, l'issue est marquée « Needs Feedback » par l'équipe n8n, et aucun contournement officiel documenté n'a été publié dans le thread. Plusieurs opérateurs ont rapporté que les approches suivantes ont rétabli les exécutions planifiées dans leur environnement :
- Désactiver puis réactiver manuellement chaque workflow concerné depuis l'interface (bascule Active/Inactive).
- Redémarrer le conteneur ou le service n8n, ce qui force la réinitialisation de la file de planification interne.
- Sur les déploiements en mode queue : redémarrer en priorité le nœud principal (main), avant les workers.
Ces actions ne constituent pas un correctif : le problème peut se reproduire. Surveillez l'issue #31100 pour le statut officiel et la version de correction.
Identification rapide des workflows affectés : dans l'interface n8n, filtrez l'historique d'exécutions par déclencheur « Schedule » et vérifiez l'absence d'exécutions sur la période attendue. Un workflow qui aurait dû s'exécuter dix fois depuis minuit sans aucune trace dans le journal est un signal clair.
Vérification post-migration : ce qu'il faut contrôler avant de rouvrir le trafic
Une mise à jour n8n réussie se confirme sur plusieurs axes, pas seulement sur la version affichée.
Version : l'interface « About n8n » affiche 1.121.3 ou supérieur. La commande docker inspect sur l'image en cours retourne le même numéro.
Intégrité des credentials : n8n chiffre les credentials avec une clé dérivée de N8N_ENCRYPTION_KEY. Si cette variable n'a pas changé entre les deux versions, les credentials existants sont intacts. Ouvrez un workflow qui utilise une connexion externe (HTTP Request, base de données, API tierce) et vérifiez qu'il s'exécute sans erreur de décryptage.
Workflows actifs : dans le tableau de bord, vérifiez que le nombre de workflows actifs correspond à la situation avant la mise à jour. Un workflow qui était actif et ne l'est plus après le redémarrage est un signal d'alerte.
Exécutions planifiées : si votre instance utilise des nœuds Schedule Trigger, attendez la prochaine heure de déclenchement et confirmez l'exécution dans le journal. Si vous êtes sur la version 2.21.7 de la branche 2.x, consultez la section précédente sur le bug de scheduling.
Logs de démarrage : docker compose logs n8n --tail 50 doit afficher un démarrage sans exception. Les erreurs de connexion à la base de données ou de décryptage de credentials apparaissent dans ces premières lignes.
Accès réseau : si votre instance est exposée via un reverse proxy, vérifiez que les routes /webhook/ et /webhook-test/ répondent correctement après la mise à jour.
Versions n8n : exposition aux CVE de l'alerte AL26-001
Faites défiler le tableau
| Version | CVE-2025-68613 | CVE-2026-21858 | CVE-2026-21877 | Action requise |
|---|---|---|---|---|
| < 1.120.4 | Vulnérable | Vulnérable | Vulnérable | Mise à jour vers ≥ 1.121.3 |
| 1.120.4 – 1.120.x | Corrigé | Vulnérable | Vulnérable | Mise à jour vers ≥ 1.121.3 |
| 1.121.0 – 1.121.2 | Corrigé | Corrigé | Vulnérable | Mise à jour vers ≥ 1.121.3 |
| ≥ 1.121.3 | Corrigé | Corrigé | Corrigé | Aucune action CVE requise |
| 2.x < 2.21.7 | Statut à vérifier | Statut à vérifier | Statut à vérifier | Consulter les release notes 2.x |
| 2.21.7+ | Statut à vérifier | Statut à vérifier | Statut à vérifier | Bug scheduling #31100 actif |
Garder son instance n8n à jour : la voie sur VPS
CVE-2026-21877 illustre le coût d'une instance self-hosted dont la mise à jour dépend d'une fenêtre de maintenance externe. Sur un VPS avec accès root, la commande docker compose pull && docker compose up -d applique le patch en moins de dix minutes, sans dépendre d'un prestataire pour décider du moment.
Cette autonomie a une contrepartie : la veille sur les advisories de sécurité revient à l'opérateur. Deux sources à surveiller pour n8n : le dépôt GitHub (onglet Security, notifications activables) et les alertes du Centre canadien pour la cybersécurité ou de son équivalent CERT dans votre région.
Pour aller plus loin sur la mise en place d'une instance n8n solide — installation initiale, reverse proxy Caddy ou nginx, TLS automatique et sauvegarde — consultez le guide installer n8n sur VPS. Si vous venez d'une installation npm et envisagez la migration vers Docker avant de passer à la branche 2.x, le guide migration npm vers Docker avant v3 couvre ce parcours. Le patron de patch appliqué ici est identique à celui documenté pour CVE-2026-6471 sur PostgreSQL.
