Alerte de sécurité N8n CVE-2026-25049 permet l'exécution à distance des commandes et échappe sandbox

La communauté de sécurité a détecté une grave défaillance dans n8n, la plate-forme d'automatisation de workflow, qui permet l'exécution à distance des commandes sur le serveur où l'application fonctionne si elle est exploitée avec succès. Le problème, enregistré comme CVE-2026-25049 et avec un score élevé dans le système CVSS (9.4), c'est une évasion des contrôles d'assainissement dans l'évaluation des expressions qui inverse partiellement une correction appliquée l'année dernière pour la vulnérabilité CVE-2025-68613 (CVSS 9.9).

Les responsables N8n ont publié un avis dans GitHub qu'un utilisateur authentifié avec les permissions de créer ou de modifier des flux peut injecter des expressions spécialement construites dans des paramètres d'écoulement qui finissent par s'échapper du mécanisme sandbox et provoquant l'exécution de commandes système hôte. L'explication officielle et les versions corrigées Avis de sécurité N8n à GitHub.

Du point de vue technique, la racine du problème est la différence entre les vérifications de TypeScript dans le temps de compilation et ce qui se passe dans le temps de fonctionnement avec JavaScript. Comme l'ont expliqué plusieurs équipes de recherche, Endor Labs, TypeScript peut aider à identifier que certaines propriétés doivent être une chaîne dans le code source, mais ces garanties disparaissent lors de l'exécution de valeurs qu'un attaquant introduit dynamiquement. En profitant de cela, vous pouvez passer des valeurs inattendues (objets, tableaux, symboles, etc.) qui moquent les fonctions d'assainissement et vous permettent de quitter le coffre.

Des chercheurs indépendants ont publié des analyses techniques qui illustrent comment l'évasion est réalisée et comment les étapes sont enchaînées pour atteindre l'exécution à distance. Le travail de sensibilisation comprend une ventilation détaillée des techniques utilisées et des exemples pratiques; l'une de ces analyses détaillées se trouve dans la recherche de Fatih Çelik sur la séquence des défaillances et des contournements: n8n RCE: Une histoire de 4 lois.

Le risque est augmenté lorsqu'il est associé à la fonctionnalité de n8n webhooks. Si un attaquant crée un flux avec un webhold public et non authentifié, vous pouvez insérer la charge qui provoque l'exécution de la commande et, une fois le flux activé, toute personne qui connaît le paramètre peut le tirer et exécuter le code sur le serveur. Équipements similaires SecureLayer7 et Sécurité du pilier ont des scénarios d'impact détaillés qui comprennent le vol de clés API, l'accès aux secrets du cloud, le mouvement latéral vers les comptes connectés et la prise de contrôle des flux de travail liés aux services d'intelligence artificielle.

n8n a publié des corrections dans les branches concernées; les versions contenant les correctifs sont 1.123.17 pour la série 1.x et 2.5.2 pour la série 2.x. Mettre à jour une version séparée devrait être la priorité numéro un pour tout déploiement vulnérable. S'il n'est pas possible d'appliquer la mise à jour immédiatement, il convient de prendre des mesures compensatoires pour réduire l'exposition : limiter qui peut créer et modifier des flux vers un petit groupe d'utilisateurs de confiance, désactiver ou protéger les sites Web publics, et exécuter n8n dans des environnements avec des privilèges de système restreints et des règles de réseau pour minimiser les dommages en cas d'intrusion.

Il est également important de vérifier les flux et les dossiers d'activité existants pour détecter les changements suspects ou les nouveaux paramètres publics. Dans les systèmes qui ont pu être compromis, les références et les clés qui ont été disponibles dans l'environnement touché doivent être tournées et l'accès examiné. Les entreprises qui dépendent d'intégrations et d'automatisations critiques devraient prioriser cet examen et la campagne de stationnement.

La chaîne de découverte de cette vulnérabilité comprenait des contributions de plusieurs équipes de sécurité et analystes, dont Fatih Çelik, Cris Staicu de Endor Labs, Eilon Cohen de Pillar Security et Sandeep Kamble de SequreLayer7; les responsables du N8n les ont publiquement reconnus pour leurs rapports.

Cet épisode met en évidence une leçon classique mais souvent ignorée : les contrôles statiques du type ne remplacent pas les validations robustes dans le temps de fonctionnement lorsque vous manipulez des entrées peu fiables. Des organisations comme l'OWASP insistent sur la nécessité de plusieurs niveaux de défense et la validation stricte des intrants depuis des années; la documentation générale sur les risques de validation et de contrôle d'entrée peut être consultée dans des ressources telles que OWASP. Pour mieux comprendre pourquoi TypeScript n'évite pas ce type d'exploits, le guide du projet TypeScript offre un contexte sur la façon dont votre système type agit dans le temps de compilation, mais ne persiste pas dans le paquet final: Type de documentation du script.

En bref, si vous utilisez n8n en production : d'abord, mettez à jour les versions parchées dès que possible. Ensuite, il passe en revue les autorisations et l'exposition de webhooks, durcit l'environnement de mise en œuvre et effectue un audit des indicateurs d'engagement possibles. Si vous avez besoin d'informations plus techniques, l'analyse des chercheurs et l'avis de n8n sont des ressources publiques utiles pour comprendre la portée et les moyens de fonctionnement: Avis de GitHub, plongée profonde de Fatih Çelik et les rapports des Endor Labs, SecureLayer7 et Sécurité du pilier.