[{"data":1,"prerenderedAt":184},["ShallowReactive",2],{"seo-verification":3,"blog-n8n-cve-2026-21877-mise-a-jour-urgence-fr":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-n8n-cve-2026-21877-mise-a-jour-urgence-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":126,"ctaBody":127,"ctaButton":128,"ctaUrl":129,"relatedPosts":130},360,"n8n-cve-2026-21877-mise-a-jour-urgence",{"fr":10,"en":12,"ar":13,"es":14},"n8n-cve-2026-21877-critical-rce-patch","n8n-cve-2026-21877-تصحيح-ثغرة-rce","n8n-cve-2026-21877-parche-rce-critico","n8n CVE-2026-21877 : patch RCE CVSS 9.9 en urgence","CVE-2026-21877 ouvre une exécution de code à distance authentifiée dans n8n (CVSS 9.9). Procédure de mise à jour vers ≥ 1.121.3 et workaround scheduling.",10,0,false,"2026-09-18T00:00:00+00:00","2026-09-19T02:00:43+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Sécurité & Monitoring","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fn8n-cve-2026-21877-mise-a-jour-urgence-poster.svg",{"categorySlug":34,"appSlug":35},"automatisation","n8n","L'alerte CERT Canada AL26-001 publiée le 12 janvier 2026 identifie trois vulnérabilités actives dans n8n. La plus critique, CVE-2026-21877 (CVSS 9.9), permet à un utilisateur authentifié d'exécuter du code arbitraire sur l'hôte via le nœud Git. Toute instance self-hosted non mise à jour est exposée. Ce guide décrit la procédure de patch, les vérifications post-migration et le contournement du bug de scheduling introduit en version 2.21.7.",[38,42,53,56,84,88,91,94,123],{"type":39,"title":40,"body":41},"h2","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.\n\nLe 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.\n\nL'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.",{"type":43,"title":44,"items":45},"ul","Qui est exposé et dans quelle plage de versions",[46,47,48,49,50,51,52],"**Toutes les instances self-hosted de n8n >= 0.123.0 et \u003C 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 à \u003C 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 à \u003C 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.",{"type":39,"title":54,"body":55},"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.\n\n**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.\n\n**Via Docker** : la commande `docker inspect \u003Cnom-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\u002Fn8n:latest`, cette valeur est celle qui comptait au moment du `docker pull`.\n\n**Via l'API interne** : un `curl http:\u002F\u002Flocalhost:5678\u002Fhealthz` sur l'hôte retourne `{\"status\":\"ok\"}` avec la version dans les en-têtes si l'instance est en cours d'exécution.\n\nSi votre version est inférieure à 1.121.3, appliquez la procédure ci-dessous sans attendre la prochaine fenêtre de maintenance.",{"type":57,"title":58,"steps":59},"steps","Procédure de mise à jour vers n8n ≥ 1.121.3",[60,63,66,69,72,75,78,81],{"title":61,"body":62},"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 :\n\n```bash\n# SQLite (chemin par défaut)\ncp ~\u002F.n8n\u002Fdatabase.sqlite ~\u002F.n8n\u002Fdatabase.sqlite.bak-$(date +%Y%m%d)\n\n# PostgreSQL\npg_dump -U n8n -d n8n > n8n-backup-$(date +%Y%m%d).sql\n```\n\nCopiez également votre fichier `docker-compose.yml` et votre fichier `.env` dans un répertoire de sauvegarde.",{"title":64,"body":65},"Mettre à jour le fichier docker-compose.yml","Si vous utilisez l'image `n8nio\u002Fn8n:latest`, aucune modification du fichier `docker-compose.yml` n'est requise. Si vous avez épinglé une version explicite (par exemple `n8nio\u002Fn8n:1.115.0`), mettez à jour la ligne `image` :\n\n```yaml\nservices:\n  n8n:\n    image: n8nio\u002Fn8n:1.121.3\n```\n\nSi vous souhaitez suivre la branche stable à long terme, utiliser un tag de version explicite est préférable à `latest` pour contrôler les fenêtres de mise à jour.",{"title":67,"body":68},"Télécharger la nouvelle image","Depuis le répertoire contenant votre `docker-compose.yml` :\n\n```bash\ndocker compose pull\n```\n\nCette commande télécharge uniquement les couches de l'image qui ont changé. Pour un lien montant à 100 Mbit\u002Fs, comptez 30 à 90 secondes selon votre cache local.",{"title":70,"body":71},"Arrêter l'instance en cours","```bash\ndocker compose down\n```\n\nL'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.",{"title":73,"body":74},"Redémarrer avec la nouvelle image","```bash\ndocker compose up -d\n```\n\nDocker 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.",{"title":76,"body":77},"Vérifier la version déployée","```bash\ndocker compose logs n8n | grep -i 'version\\|n8n@'\n```\n\nOu via l'API interne, depuis l'hôte :\n\n```bash\ncurl -s http:\u002F\u002Flocalhost:5678\u002Fhealthz\n```\n\nConfirmez 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.",{"title":79,"body":80},"Désactiver le nœud Git si vous ne l'utilisez pas","La variable d'environnement `EXECUTIONS_DATA_PRUNE=true` n'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 :\n\n```bash\nN8N_NODES_EXCLUDE='[\"n8n-nodes-base.git\"]'\n```\n\nAjoutez cette variable dans votre fichier `.env` et redémarrez l'instance. Ce n'est pas un substitut à la mise à jour : appliquez le patch dès que possible.",{"title":82,"body":83},"Pour une installation npm (sans Docker)","```bash\nnpm update -g n8n\n# Ou, si vous utilisez un gestionnaire de processus :\npm2 stop n8n\nnpm update -g n8n\npm2 start n8n\n```\n\nVé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-v3` couvre ce parcours en détail.",{"type":85,"title":86,"body":87},"tip","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.\n\n**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`.\n\n**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.\n\n**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.\n\n**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.\n\n**Abonnez-vous aux alertes de sécurité n8n.** Le dépôt GitHub `n8n-io\u002Fn8n` permet de s'abonner aux notifications de sécurité via « Watch → Security alerts ».",{"type":39,"title":89,"body":90},"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.\n\n**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.\n\n**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 :\n\n- Désactiver puis réactiver manuellement chaque workflow concerné depuis l'interface (bascule Active\u002FInactive).\n- Redémarrer le conteneur ou le service n8n, ce qui force la réinitialisation de la file de planification interne.\n- Sur les déploiements en mode queue : redémarrer en priorité le nœud principal (main), avant les workers.\n\nCes 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.\n\n**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.",{"type":39,"title":92,"body":93},"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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\n**Accès réseau** : si votre instance est exposée via un reverse proxy, vérifiez que les routes `\u002Fwebhook\u002F` et `\u002Fwebhook-test\u002F` répondent correctement après la mise à jour.",{"type":95,"title":96,"headers":97,"rows":103},"comparison","Versions n8n : exposition aux CVE de l'alerte AL26-001",[98,99,100,101,102],"Version","CVE-2025-68613","CVE-2026-21858","CVE-2026-21877","Action requise",[104,108,111,113,116,120],[105,106,106,106,107],"\u003C 1.120.4","Vulnérable","Mise à jour vers ≥ 1.121.3",[109,110,106,106,107],"1.120.4 – 1.120.x","Corrigé",[112,110,110,106,107],"1.121.0 – 1.121.2",[114,110,110,110,115],"≥ 1.121.3","Aucune action CVE requise",[117,118,118,118,119],"2.x \u003C 2.21.7","Statut à vérifier","Consulter les release notes 2.x",[121,118,118,118,122],"2.21.7+","Bug scheduling #31100 actif",{"type":39,"title":124,"body":125},"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.\n\nCette 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.\n\nPour 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 \u003Ca href=\"\u002Fblog\u002Finstaller-n8n-vps\">installer n8n sur VPS\u003C\u002Fa>. Si vous venez d'une installation npm et envisagez la migration vers Docker avant de passer à la branche 2.x, le guide \u003Ca href=\"\u002Fblog\u002Fn8n-migration-npm-docker-avant-v3\">migration npm vers Docker avant v3\u003C\u002Fa> couvre ce parcours. Le patron de patch appliqué ici est identique à celui documenté pour \u003Ca href=\"\u002Fblog\u002Fpostgresql-cve-2026-6471-patch-instances-self-hosted\">CVE-2026-6471 sur PostgreSQL\u003C\u002Fa>.","Un VPS avec accès root pour appliquer vos patchs quand vous le décidez","Sur un VPS ServOrbit, `docker compose pull && docker compose up -d` s'exécute en moins de dix minutes. Aucune dépendance à un hébergeur pour la fenêtre de maintenance.","Voir les VPS Cloud","\u002Fvps-cloud",[131,151,167],{"id":132,"slug":133,"slugs":134,"title":138,"excerpt":139,"readTime":140,"views":141,"isPinned":19,"publishedAt":142,"updatedAt":143,"category":144,"categories":147,"featuredImage":30,"bgImage":31,"posterImage":149,"relatedSolution":150},3,"installer-n8n-vps",{"fr":133,"en":135,"ar":136,"es":137},"install-n8n-on-vps-with-docker-complete-2026-guide","تثبيت-n8n-على-vps-مع-docker-دليل-شامل-2026","instalar-n8n-en-vps-con-docker","Installer n8n sur VPS avec Docker : guide complet 2026","Déployez n8n sur VPS avec Docker, reverse proxy et HTTPS. Crash V8, 502 nginx, migration npm vers Docker et sécurisation des exécutions persistées (advisory août 2026).",12,2,"2026-06-05T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":141,"name":145,"slug":34,"color":146,"icon":34},"Automatisation","bg-brand-action\u002F10 text-brand-action",[148],{"id":141,"name":145,"slug":34,"color":146,"icon":34},"\u002Fblog\u002Fcovers\u002Finstaller-n8n-vps-poster.svg",{"categorySlug":34,"appSlug":35},{"id":152,"slug":153,"slugs":154,"title":158,"excerpt":159,"readTime":23,"views":18,"isPinned":19,"publishedAt":160,"updatedAt":161,"category":162,"categories":163,"featuredImage":30,"bgImage":31,"posterImage":165,"relatedSolution":166},344,"n8n-migration-npm-docker-avant-v3",{"fr":153,"en":155,"ar":156,"es":157},"n8n-migration-npm-to-docker-before-v3","n8n-migration-npm-to-docker-before-v3-ar","n8n-migracion-npm-docker-antes-v3","n8n 3.0 : migrer de npm vers Docker avant octobre 2026","n8n 3.0 retire npm et npx en octobre 2026. Détectez votre mode, exportez vos workflows et basculez sur Docker Compose avec PostgreSQL avant l'échéance.","2026-09-09T00:00:00+00:00","2026-09-09T21:41:07+00:00",{"id":141,"name":145,"slug":34,"color":146,"icon":34},[164],{"id":141,"name":145,"slug":34,"color":146,"icon":34},"\u002Fblog\u002Fcovers\u002Fn8n-migration-npm-docker-avant-v3-poster.svg",{"categorySlug":34,"appSlug":35},{"id":168,"slug":169,"slugs":170,"title":174,"excerpt":175,"readTime":176,"views":177,"isPinned":19,"publishedAt":178,"updatedAt":179,"category":180,"categories":181,"featuredImage":30,"bgImage":31,"posterImage":183,"relatedSolution":30},339,"postgresql-cve-2026-6471-patch-instances-self-hosted",{"fr":169,"en":171,"ar":172,"es":173},"postgresql-cve-2026-6471-patch-self-hosted-instances","تصحيح-ثغرة-postgresql-cve-2026-6471-الخوادم-الذاتية","cve-2026-6471-postgresql-parchear-instancias-self-hosted","CVE-2026-6471 et -14669 : patcher PostgreSQL sur VPS","Deux failles critiques PostgreSQL corrigées le 13 août 2026 : réplication vers RCE et heap overflow vers RCE. Patcher vos instances via apt ou Docker.",7,1,"2026-09-08T00:00:00+00:00","2026-09-08T21:59:59+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[182],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fpostgresql-cve-2026-6471-patch-instances-self-hosted-poster.svg",1789783525581]