CVE-2026-27577 dans n8n : Quand le patch lui-même est contourné

Wer n8n selbst betreibt, kennt die Routine: Sicherheitsmeldung lesen, Version hochziehen, Haken dran. Bei CVE-2026-27577, cette routine n'a pas suffi. La faille a été corrigée le 25 février 2026, et en juillet 2026, les chercheurs en sécurité ont contourné exactement ce correctif.

Ce n'est pas une erreur, mais la quatrième tentative documentée contre le même composant en l'espace de huit mois. Pour les instances auto-hébergées, cela change la question : non pas si vous avez appliqué une mise à jour particulière, mais si vous avez un processus qui détecte les corrections du même composant. La situation générale est décrite dans les failles de sécurité n8n 2026. Cet article traite du contournement lui-même.

Qu'est-ce que CVE-2026-27577 exactement ?

CVE-2026-27577 est une faille critique dans l'évaluation des expressions de n8n, via laquelle un utilisateur connecté ayant le droit de créer ou modifier des workflows peut exécuter des commandes système sur l'hôte via des expressions préparées dans les paramètres du workflow.

Le NVD répertorie la faille avec CVSS 3.1 de 9,9 (critique) et la classe de faille CWE-94, Code Injection. L'avis de sécurité GitHub GHSA-vpcf-gvg4-6qwr l'évalue en outre selon CVSS 4.0 avec 9,4. Les versions affectées sont tous les stables antérieurs à 1.123.22, la série 2.x à partir de 2.0.0 antérieurs à 2.9.3, ainsi que 2.10.0. Elle est corrigée dans 1.123.22, 2.9.3 et 2.10.1, tous trois publiés sur npm le 25 février 2026.

Point important pour le classement : n8n décrit CVE-2026-27577 dans son propre avis explicitement comme un complément à CVE-2025-68613, la faille originelle dans l'évaluation des expressions de décembre 2025. Entre-temps, il y avait déjà CVE-2026-25049 du 4 février 2026, également CVSS 3.1 de 9,9, également une façon de contourner le même mécanisme de protection.

Pourquoi le correctif CVE-2026-27577 a-t-il été contourné en juillet 2026 ?

Le correctif de CVE-2026-27577 a fermé le vecteur d'attaque spécifiquement signalé, mais n'a pas résolu la faille sous-jacente dans l'outil de réécriture des expressions. L'entreprise de sécurité Security Joes a montré en juillet 2026 que le même accès à l'environnement d'exécution Node.js peut être obtenu via un autre élément du langage.

Technisch beschreibt Security Joes zwei Blindstellen, die einzeln harmlos sind und erst zusammen greifen: Die Umschreibung freier Bezeichner überspringt Pfeilfunktionen, sodass ein Ausdruck der Form „Pfeilfunktion, die das Prozess-Objekt zurückgibt“ am Schutz vorbeiläuft, und die Sperrliste für gefährliche Eigenschaften prüft nur statisch notierte Namen, greift also nicht, wenn derselbe Name als Zeichenkette übergeben wird. Verifiziert wurde das laut Veröffentlichung auf n8n 2.30.4, also auf einem Stand nach der Patch-Linie zu CVE-2026-27577 (Quelle: Security Joes, „Breaking the Sandbox Again“, 27. Juli 2026).

La chronologie plaide en faveur du fabricant : Security Joes a signalé la découverte le 15 juillet 2026 via le programme de divulgation des failles de n8n, le 22 juillet 2026 le correctif était déployé et l'Advisory GHSA-gv7g-jm28-cr3m publié, évalué avec CVSS 4.0 de 8,7. Ce vecteur est corrigé dans 2.31.5 et 2.32.1. Le même jour, n8n a publié avec CVE-2026-65591 (CVSS 4.0 de 8,9) un deuxième contournement du même type dans l'ancien évaluateur d'expressions, corrigé dans 1.123.64, 2.29.8 et 2.30.1.

Quelle version de n8n est maintenant sûre ?

Une version à partir de 1.123.67, 2.31.5 ou 2.32.1 est sûre contre tous les contournements mentionnés ici, car les correctifs de juillet se trouvent derrière la ligne de correctifs pour CVE-2026-27577. Si vous avez mis à jour vers 1.123.22 ou 2.10.1 en février 2026 et n'avez rien fait depuis, vous êtes vulnérable.

• Faille d'expressions CVE-2025-68613 (décembre 2025) : corrigée dans 1.120.4, 1.121.1 et 1.122.0.
• Contournement CVE-2026-25049 (4 février 2026) : corrigé dans 1.123.17 et 2.5.2.
• Contournement CVE-2026-27577 (25 février 2026) : corrigé dans 1.123.22, 2.9.3 et 2.10.1.
• Contournement CVE-2026-65591 (22 juillet 2026) : corrigé dans 1.123.64, 2.29.8 et 2.30.1.
• Contournement via fonctions fléchées, GHSA-gv7g-jm28-cr3m (22 juillet 2026) : corrigé dans 2.31.5 et 2.32.1.

À la date de clôture de cet article, 2.32.7 du 31 juillet 2026 est la version stable actuelle sur npm. Vous trouverez le numéro de version de votre instance dans les paramètres de l'interface.

Qui est autorisé à modifier les workflows chez vous ?

Toutes les failles de cette série supposent un compte connecté avec le droit de créer ou de modifier des workflows. Cela signifie que l'attribution des droits dans n8n n'est pas un réglage de confort, mais une limite de sécurité : quiconque peut modifier les workflows se trouve, en cas de contournement ouvert, pratiquement au même niveau qu'un utilisateur ayant accès au shell du serveur.

Dans de nombreuses installations que nous reprenons, tous les participants ont simplement les droits de modification, parce que c'était le plus rapide au moment de la mise en place et que personne ne l'a revu après. Pour les instances gérées, nous vérifions donc non seulement la version, mais aussi qui détient les droits de modification et si l'interface doit vraiment être accessible depuis Internet ouvert. Les deux font partie de l'exploitation continue d'une instance n8n et non d'une action spéciale après le prochain gros titre.

Que doivent faire les hébergeurs autonomes maintenant ?

La seule protection complète est la mise à jour, c'est ce que disent les avis n8n eux-mêmes. Les mesures transitoires mentionnées là-bas atténuent la situation, mais ne la résolvent pas explicitement.

• Vérifier et mettre à jour la version : au minimum vers 1.123.67, 2.31.5 ou 2.32.1, mieux vers la version stable actuelle.
• Réduire les droits de modification : Seuls ceux qui en ont vraiment besoin pour leur travail peuvent créer et modifier des workflows. C'est la mesure transitoire recommandée par n8n elle-même.
• Revoir les accès si vous avez fonctionné longtemps sur une version vulnérable : Security Joes recommande dans ce cas de considérer la clé de chiffrement de l'instance et les identifiants stockés comme compromis et de les remplacer, car une attaque réussie y donne accès.
• Ne pas exposer l'interface directement à Internet : Accès via VPN ou un proxy inverse sécurisé, voir les conseils de durcissement dans la documentation n8n.
• Suivre les annonces en permanence : s'abonner aux avis de sécurité GitHub de n8n et planifier une fenêtre de mise à jour régulière, plutôt que de réagir au coup par coup.

Cette série de CVE montre pourquoi le conseil banal est le plus décisif : Entre le correctif du 25 février et celui du 22 juillet, il s'est écoulé près de cinq mois au cours desquels une instance correctement mise à jour restait vulnérable dès que quelqu'un trouvait le prochain vecteur. n8n fournit des conseils de durcissement détaillés sous docs.n8n.io.

Questions fréquentes

n8n Cloud est-il affecté par CVE-2026-27577 ?

n8n met à jour lui-même son propre environnement Cloud, la gestion des correctifs se fait côté fournisseur. Le danger pratique de cette série de CVE affecte principalement les instances auto-hébergées qui ne sont pas mises à jour en temps opportun. Le problème de droits subsiste dans les deux modèles d'exploitation, car un compte avec droits de modification des workflows est la condition préalable à l'attaque.

Suffit-il de mettre à jour vers 1.123.22 ou 2.10.1 ?

Non, cela ne ferme que CVE-2026-27577 lui-même. Les contournements du même mécanisme de protection publiés en juillet 2026 ne sont corrigés qu'à partir de 1.123.67, 2.31.5 respectivement 2.32.1, le contournement dans l'ancien évaluateur à partir de 1.123.64, 2.29.8 et 2.30.1.

Comment savoir si mon instance a été exploitée ?

Il n'existe pas de signe de reconnaissance certain à distance. Utile : un coup d'œil à l'historique d'exécution pour les workflows avec des expressions inhabituelles dans les paramètres des nœuds et la vérification des connexions sortantes du serveur. En cas de doute, le principe de la publication de Security Joes s'applique : traiter les identifiants d'accès comme compromis et les remplacer.

Pourquoi le même composant est-il touché quatre fois ?

Parce que l'évaluateur d'expressions de n8n doit permettre aux utilisateurs d'exécuter du JavaScript tout en le protégeant de l'environnement d'exécution du serveur. Chaque correctif ferme d'abord le vecteur signalé. Security Joes formule exactement cela comme un schéma : Le correctif à CVE-2026-27577 était correct pour le cas signalé, mais n'a pas posé la question plus générale d'autres éléments du langage qui auraient pu être contournés.

NordFlux aide-t-il à sécuriser les instances n8n existantes ?

Oui. Nous vérifions l'état de la version, l'attribution des droits et la protection d'accès des installations existantes et nous prenons en charge la gestion des mises à jour en continu si vous le souhaitez. Un aperçu de notre travail avec n8n se trouve sur la page des services n8n.