Deux failles critiques d'évasion du bac à sable dans la populaire plate-forme d'automatisation des flux de travail n8n permettent aux utilisateurs authentifiés d'exécuter du code à distance sur les instances concernées.
Selon de nouvelles découvertes de JFrog, les protections du sandboxing destinées à contenir une logique de flux de travail non fiable peuvent être contournées, exposant ainsi les environnements d'automatisation d'entreprise à une compromission totale de l'hôte. Les entreprises qui s'appuient sur n8n pour orchestrer les intégrations, automatiser les processus internes et optimiser les services cloud et les systèmes sur site courent des risques. Les chercheurs de JFrog ont déclaré que le mécanisme de sandboxing de n8n peut échouer dans des configurations spécifiques lorsque les utilisateurs évaluent des expressions ou exécutent des scripts personnalisés.
Les échappements Sandbox peuvent exposer des informations d'identification, des API et l'infrastructure sensibles des moteurs de flux de travail concernés.
Expression Engine Sandbox Escape active JavaScript RCE
L'un des problèmes identifiés par JFrog affecte le moteur d'expression JavaScript de n8n, conçu pour évaluer en toute sécurité les expressions fournies par l'utilisateur lors de l'exécution du flux de travail. Selon les chercheurs, des failles dans la manière dont les expressions sont nettoyées permettent à un attaquant autorisé à créer ou à modifier des flux de travail d'échapper au bac à sable et d'exécuter du JavaScript arbitraire sur l'hôte sous-jacent.
JFrog a expliqué dans un article de blog que les protections du moteur d'expression peuvent être contournées par des charges utiles soigneusement conçues qui exploitent les hypothèses de la logique du sandboxing. Une fois échappé, l'attaquant n'est plus limité à l'évaluation des expressions et peut exécuter des commandes arbitraires dans le contexte du service n8n.
“Lorsque le moteur d'expression rencontre un bloc {{}}, il traite le contenu joint en le transmettant à un constructeur de fonctions JavaScript, qui exécute ensuite le code fourni”, ont expliqué les chercheurs. n8n utilise un bac à sable basé sur AST pour neutraliser les constructions JavaScript dangereuses avant leur exécution. Un cas limite omis dans l’instruction obsolète « with » permet aux attaquants de contourner ces vérifications et de réaliser l’exécution de code arbitraire.
La vulnérabilité a été attribuée CVE-2026-1470 et a un indice de gravité critique de CVSS 9,9 sur 10, en raison de la facilité avec laquelle les restrictions du bac à sable peuvent être brisées et du niveau d'accès obtenu après exploitation.
L'échappement du nœud de code Python brise l'isolement
JFrog a également identifié un échappement sandbox distinct qui affecte le nœud de code Python de n8n lorsque la plateforme est configurée pour utiliser son mode d'exécution « interne ». Dans ce cas, les restrictions destinées à contenir l'exécution de code Python peuvent être contournées, permettant là encore aux utilisateurs authentifiés d'exécuter du code arbitraire en dehors du bac à sable.
Le deuxième problème, signalé sous le numéro CVE-2026-0863, a reçu un indice de gravité élevé de CVSS 8,5 sur 10. Bien que l'exploitation dépende d'options de configuration spécifiques, JFrog a noté que le mode d'exécution interne est couramment utilisé dans les déploiements d'entreprise auto-hébergés pour des raisons de performances et de simplicité opérationnelle.
Les chercheurs ont démontré comment les restrictions du bac à sable de Python peuvent être contournées, en accordant l'accès à des ressources système qui devraient être interdites.
Besoin urgent de mettre à jour
Les deux problèmes ont été résolus et les entreprises exécutant n8n doivent s’assurer qu’elles disposent de versions mises à jour. En attendant que les correctifs soient appliqués, il est conseillé aux organisations de vérifier attentivement qui dispose des autorisations nécessaires pour créer ou modifier des flux de travail, en particulier dans les environnements où elles n'ont pas accès aux réseaux internes, aux secrets ou aux API privilégiées.
CVE-2026-1470 a été corrigé dans les versions 1.123.17, 2.4.5 et 2.5.1, tandis que CVE-2026-0863 a été résolu dans les versions 1.123.14, 2.3.5 et 2.4.2. Les chercheurs ont noté que la mise à niveau vers l’une de ces versions atténue le risque d’exploitation.
