Alerte de sécurité : n8n corrige la vulnérabilité qui a permis aux éditeurs de flux de travail d'exécuter des commandes sur le serveur

n8n a publié des correctifs pour une vulnérabilité d'évacuation sandbox d'expression qui permet à un éditeur de flux de travail authentifié d'exécuter des commandes système d'exploitation sur le serveur qui héberge la plate-forme d'automatisation. La défaillance affecte les versions antérieures à la section 2.31. et les séries 2.32.0 à 2.32.0 inclusivement., et le problème est enregistré dans GitHub comme GHSA-gv7g-jm28-cr3m avec un score CVSS 4.0 de 8.7. Le fournisseur a publié les lancements parchés le 22 juillet après avoir reçu le rapport des enquêteurs le 15 juillet; il n'y avait pas de CVE assigné le 27 juillet 2026.

Du point de vue technique, le vecteur profite de deux faiblesses combinées dans la réécriture de l'arborescence syntaxique abstraite (AST) que n8n utilise pour déplacer les identifiants JavaScript dans un contexte contrôlé par la plate-forme. La première est une omission dans la gestion FlècheFonction Expression, qui a permis une forme concise d'une fonction de flux - par exemple, () = > process - pour résoudre l'identifiant contre l'exécution Node.js au lieu du contexte sûr. La seconde est une vérification de propriété qui n'a inspecté que les noms statiques dans les expressions des membres, évitant que des fonctions comme Reflect. get peut recevoir la propriété demandée comme argument et être utilisé pour récupérer des modules intégrés et exécuter le processus child _.

La combinaison de ces deux échecs a permis aux chercheurs de récupérer le processus. getBuiltinModule, charge le processus enfant _ et exécute les commandes avec les privilèges du processus n8n. L'opération ne nécessite qu'un compte valide avec la permission de créer ou de modifier des workflows; elle ne dépend pas de l'interaction d'un autre utilisateur. Une attaque réussie peut exposer la variable N8N _ ENCRYPTION _ KEY et ainsi déchiffrer les identifiants stockés N8n, ainsi que des routes ouvertes vers des bases de données, des services internes et des terminaux cloud accessibles depuis l'hôte.

Au-delà de la technique, cet incident met en évidence une leçon récurrente pour les plates-formes à faible code / sans code et d'automatisation : ceux qui peuvent modifier les flux sont des cibles de grande valeur. Permettre aux utilisateurs ayant accès aux flux de travail d'avoir une entrée libre dans les scripts ou expressions intégrés augmente la surface d'attaque. La sécurité opérationnelle nécessite de combiner des correctifs rapides avec de solides contrôles d'accès et des politiques de secret et de privilège.

À titre de mesures immédiates, la principale recommandation est de mettre à jour les versions corrigées (2.31.5 ou 2.32.1) dans tous les cas touchés plutôt que de se fonder uniquement sur l'atténuation provisoire décrite dans votre avis. Ces mesures d'atténuation, qui restreignent l'accès à l'édition des flux de travail à des utilisateurs entièrement fiables, sont utiles à titre temporaire, mais le vendeur les qualifie d'incomplètes et de courte durée.

Après la mise à jour, il convient d'effectuer un examen de gamme : d'inspecter les workflows récemment créés ou modifiés à la recherche de fonctions de flèche concises ou d'osfuscado JavaScript, d'auditer les journaux d'hôte pour les processus d'enfants inattendus (bash, sh, PowerShell, curl, wget ou autre invoqué par Node.js / n8n) et de rechercher une activité de déchiffrement ou l'accès à des ressources sensibles. Si l'exécution suspecte est détectée, N8N _ ENCRYPTION _ KEY devrait être pivoté, les identifiants stockés tournant et les comptes et les accès concernés vérifiés., puisque le risque de pivoter vers des services internes ou des API dans le cloud est réel.

En termes d'atténuation à moyen et à long terme, les organisations devraient appliquer un contrôle d'accès basé sur le rôle et une authentification forte (MFA / SSO) pour séparer clairement les constructeurs de workflow des comptes qui ne consomment que des automatismes. Il est également recommandé de minimiser les privilèges que les identifiants stockés en n8n ont dans les systèmes connectés, d'utiliser des identifiants limités ou temporaires dans la mesure du possible, et de segmenter le réseau pour réduire la portée d'un hôte compromis.

L'incident souligne également l'importance des tests de sécurité des composants qui manipulent le code ou la syntaxe (parsers, réécritures AST, bacs à sable). Selon les chercheurs, Aucune des deux conditions de fonctionnement n'a été couverte par des essais automatisés, qui a facilité la régression après un arrangement précédent en février (CVE-2026-27577) pour fermer une évasion similaire. Les organisations qui fournissent ces plates-formes devraient améliorer les tests de sécurité et les révisions de code pour les limites de cas.

Si vous utilisez n8n Cloud, vérifiez auprès du fabricant si votre environnement a la version vulnérable : l'avis public ne précise pas l'état de n8n Cloud. Pour les références techniques et les détails de l'avis et du suivi, voir l'entrée de l'avis dans GitHub GHSA-gv7g-jm28-cr3m et la page de publication officielle où apparaissent les versions corrigées Relais N8n à GitHub. Pour le contexte journalistique et les rapports de tiers, vous pouvez revoir la couverture et l'analyse dans des médias spécialisés comme The Hacker News thehackernews.com.

En bref : mettre à jour sans délai, ne pas compter uniquement sur l'atténuation administrative, vérifier les changements récents dans les flux de travail et les secrets, et traiter les flux de travail d'édition des comptes comme des actifs essentiels dans votre politique de sécurité. La combinaison de correctifs techniques, de restrictions d'accès et d'une réponse médico-légale rapide est la meilleure défense contre ce type d'évasion de bac à sable.