Vulnérabilités critiques dans n8n qui permettent l'exécution de code à partir de formes publiques

Les chercheurs en cybersécurité ont exposé plusieurs vulnérabilités critiques dans n8n, la plate-forme d'automatisation du workflow, qui ont été corrigées lors des dernières livraisons du projet. Les défaillances permettent de l'exécution de commande à distance à l'évaluation des expressions sans authentification par des formes publiques, et risquent à la fois des installations autogérées et des déploiements en nuage.

Deux des défaillances les plus graves correspondent aux identifiants CVE-2026-27577 et CVE-2026-27493. La première est une rupture d'isolement dans le compilateur d'expression : un cas qui n'a pas été traité dans l'arborescence de syntaxe abstraite permet l'exécution de certaines expressions sans la transformation de sécurité attendue, ouvrant la porte à l'exécution de commandes sur le serveur lorsqu'un utilisateur avec suffisamment d'autorisations crée ou modifie un flux. La seconde profite du fonctionnement public des paramètres des formes n8n : un mécanisme de double évaluation dans les nœuds de forme peut permettre à un attaquant d'injecter des expressions malveillantes sans authentification, par exemple en utilisant un formulaire de contact exposé.

La combinaison des deux défauts peut être particulièrement dangereuse: l'évaluation non authentifiée d'une expression sous une forme publique peut être enchaînée avec une échappatoire de l'expression sandbox pour obtenir l'exécution de code dans l'hôte fonctionnant n8n. Recherche Sécurité du pilier ils ont montré des scénarios dans lesquels il suffisait d'entrer une charge dans le champ "Nom" d'un formulaire pour exécuter des commandes dans le système affecté.

En plus de ces vecteurs, les responsables n8n ont corrigé deux vulnérabilités critiques supplémentaires qui pourraient également conduire à l'exécution arbitraire de code: CVE-2026-27495, lié à l'échangeur de tâches JavaScript sandbox, et CVE-2026-27497, qui affecte le mode de requête SQL du nœud Merge et permet d'écrire des fichiers arbitraires sur le serveur.

Les versions concernées couvrent les branches précédentes et moyennes du projet : versions antérieures au 1.123.22, séries 2.0.0 à 2.9.2 et séries 2.10.0 à 2.10.0 inclusivement. Les patchs sont disponibles en 1.123.22, 2.9.3 et 2.10.1. Les notices officielles et les détails techniques se trouvent dans les dépôts de sécurité du projet à GitHub et dans l'analyse des découvreurs ; pour un contexte plus technique et des mesures concrètes, vérifiez les entrées vers les liens de la communauté elle-même : la note de sécurité de n8n à GitHub et le rapport de Pillar Security.

Le risque pratique est élevé car, en plus du code d'exécution, un attaquant réussi pourrait accéder à la variable d'environnement que n8n utilise pour chiffrer les identifiants ( N8N _ ENCRYPTION _ CLÉS) et ainsi déchiffrer les jetons, les clés AWS, les mots de passe de base de données et d'autres secrets conservés dans l'instance. Pour cette raison, l'opération permet non seulement le contrôle du serveur, mais aussi l'engagement des intégrations et des services connectés à partir des flux.

Si la gestion de la mise à jour immédiate n'est pas réalisable, n8n recommande de réduire la surface d'exposition : limiter qui peut créer et modifier les flux - limiter ces permis au personnel de confiance -, exécuter n8n dans des environnements avec des privilèges réduits de système et des contrôles stricts du réseau, et appliquer une atténuation spécifique sur les nœuds vulnérables. Les actions temporaires proposées incluent l'exclusion des nœuds de forme (n8n-non-base.etn8n-nodes-base.formTrigger) par la variable environnement_, l'utilisation du mode coureur externe (N8N _ RUNNERS _ MODE = externe) de restreindre la portée de l'échangeur JavaScript et de la désactivation du nœud Fusion, le cas échéant. Les développeurs N8n se souviennent que ce sont des solutions provisoires et ne remplacent pas l'installation de correctifs officiels.

Pour les opérateurs concernés par l'intégrité de leur environnement, en plus d'appliquer les mises à jour, il est conseillé de vérifier l'utilisation des nœuds de formulaire et des itinéraires publics exposés, de faire pivoter les clés et les secrets si l'engagement est suspecté, d'examiner les journaux et les activités inhabituelles et de renforcer les politiques de segmentation du réseau et d'accès autour du serveur n8n. La consultation des dossiers et la recherche d'exécutions inattendues de commandes ou de modifications de flux de travail sont des étapes pratiques pour détecter les tentatives d'exploitation.

Bien qu'il n'y ait pas de rapports publics sur l'exploitation massive dans les environnements productifs jusqu'à présent, la gravité des échecs et la facilité d'utilisation dans les scénarios avec des formes publiques font immédiatement la mise à jour de la recommandation principale. Vous pouvez lire les corrections dans les avis officiels N8n dans GitHub et suivre l'analyse technique dans le rapport Pilier Sécurité pour mieux comprendre les chaînes d'attaque et les indicateurs d'engagement.

Liens utiles pour approfondir : explications et correctifs dans les avis de GitHub sur CVE-2026-27577 et CVE-2026-27493, Pilier Analyse de sécurité sur l'exploitation par des formulaires Voilà. et autres corrections liées aux avis de sécurité du projet: CVE-2026-27495 et CVE-2026-27497. Pour les références de vulnérabilité publique, vérifiez l'entrée correspondante dans l'inventaire NIST/NVD lorsque disponible : https: / / nvd.nist.gov.

En bref, la leçon pour les administrateurs de sécurité et les équipements est claire : pour les systèmes qui permettent d'exécuter la logique ou le code dans le temps de fonctionnement, la combinaison de paramètres incomplets et de bacs à sable est un vecteur critique. Appliquer des correctifs, réduire les permissions et supprimer les nœuds inutiles sont des mesures immédiates qui réduisent les risques tout en complétant une réponse plus large.