Alerte de sécurité: CVE-2026-25049 en n8n vous permet d'échapper au bac à sable et de prendre le contrôle du serveur

Si vous gérez l'automatisation avec n8n - la plate-forme open source qui vous permet de canaliser les applications et les processus à travers les workflows - vous devriez faire attention: plusieurs enquêtes récentes ont découvert des défauts graves dans l'isolat qui exécute le code côté serveur, qui a permis aux attaquants authentifiés d'échapper au sandbox et exécuter des commandes arbitraires dans l'hôte.

Faiblesse, enregistrée collectivement CVE-2026-25049, affecte la façon dont n8n désinfecte et évalue les fragments JavaScript qui peuvent inclure les utilisateurs dans les flux de travail. Équipes de recherche indépendantes Sécurité du pilier, Endor Labs et SecureLayer7- ont montré comment, avec la permission de créer ou de modifier des workflows, un attaquant peut profiter de ces échecs pour prendre le contrôle complet du serveur où il exécute n8n.

Pour comprendre pourquoi c'est sérieux, il suffit de penser à ce que n8n stocke et à ce qu'il se connecte habituellement avec : les identifiants API, les jetons OAuth, les clés et les flux qui interagissent avec les services cloud ou avec les modèles IA. Selon les descriptions techniques, l'explosion permet d'exécuter des instructions sur la machine victime à lire des fichiers sensibles, d'extraire des identifiants et de pivoter dans des comptes et des ressources connectés, y compris de détourner des flux d'IA en interceptant ou en modifiant des invites et des réponses.

Au cœur du problème se trouve la stratégie « sandboxing » basée sur l'analyse de syntaxe de code (AST). Les chercheurs expliquent que les vérifications ont supposé certaines restrictions de type script, mais ces garanties n'ont pas été appliquées pendant le temps d'exécution, ce qui a entraîné une condition de confusion de type qui permet d'éviter le code. Concrètement, cela ouvre la porte pour construire des expressions qui, une fois évaluées sur le serveur, récupèrent des objets globaux à partir de Noeud. js ou utilisez le constructeur de fonction pour exécuter le code arbitraire.

La décision n'est pas apparue de nulle part : l'équipe de recherche Pillar Security a signalé une chaîne d'évacuation le 21 décembre 2025 et n8n a mis en place une correction initiale peu après, mais les chercheurs ont montré que la solution ne fermait pas tous les vecteurs. Après une analyse plus approfondie, d'autres contournements ont été trouvés et les développeurs n8n ont confirmé de nouvelles évasions avant de publier des correctifs ultérieurs. L'analyse complète et les essais conceptuels sont disponibles dans les rapports techniques du Sécurité du pilier, Endor Labs et SecureLayer7.

n8n a publié des correctifs et des mesures d'atténuation; précédent et note de sécurité avec atténuation temporaire pour confirmer quelles versions contiennent les corrections finales. De plus, l'équipement qui ne peut pas être mis à jour immédiatement devrait appliquer les mesures provisoires proposées par le projet et limiter qui peut créer ou modifier des flux de travail dans l'installation.

La menace est plus grande dans les déploiements multi-locataires : si un attaquant est en mesure d'accéder aux services de cluster internes, il pourrait gravir et accéder aux données d'autres locataires. En outre, l'attention accordée à la communauté malveillante se reflète déjà dans les analyses de masse et d'enquête portant sur les cas exposés; par exemple, GreyBoise a documenté l'activité d'enquête par rapport aux paramètres vulnérables dans des campagnes récentes, ce qui montre de l'intérêt pour les points d'entrée qui facilitent le contrôle des systèmes compromis ( Rapport sur le bruit gris).

Si vous administrez n8n, la priorité immédiate est de vérifier si votre installation est dans une version parachevée et, dans la négative, de la mettre à jour dès que possible. Les équipes de sécurité et d'exploitation devraient également faire pivoter la clé de chiffrement n8n et toutes les références stockées sur la plateforme, examiner les flux de travail pour les expressions suspectes et limiter la capacité de créer / modifier des flux de travail à des utilisateurs entièrement fiables. Dans le dépôt de sécurité n8n, vous trouverez des instructions sur l'atténuation temporaire pour ceux qui ne peuvent pas appliquer le patch immédiatement: atténuation temporaire à GitHub.

Du point de vue technique, la leçon est claire : permettre aux utilisateurs de définir des fragments de code exécutables sur le serveur nécessite toujours un bac à sable rigide et des contrôles dans le temps de fonctionnement, pas seulement sur les types ou sur la surface du code. Des erreurs subtiles dans la logique de sanitisation, en particulier dans les environnements qui utilisent le typage statique comme aide au développeur, peuvent être utilisées si l'implémentation de l'exécution n'impose pas les mêmes garanties.

Pour l'instant, il n'y a pas de rapports publics confirmés d'attaques dans la production exploitant cette vulnérabilité particulière, mais la visibilité du problème et les tests conceptuels publiés par les chercheurs augmentent le risque. Maintenir des plateformes à jour, durcir les autorisations et faire pivoter les secrets sont des mesures qui réduisent l'exposition et le temps d'intervention aux incidents possibles.

Si vous avez besoin de consulter la recherche originale, des rapports techniques et des preuves conceptuelles sont disponibles dans les publications de Sécurité du pilier, Endor Labs et SecureLayer7, et les informations officielles et les mesures d'atténuation sont publiées dans leur dépôt de GitHub ( n8n avis).

Conclusion: Si votre organisation dépend de n8n, agissez maintenant : validez la version, appliquez des correctifs, cassez les touches et réduisez qui peut modifier les flux de travail. La combinaison de l'exécution de code sur le serveur et une mauvaise désinfection fait une autorisation apparemment bénigne - créer ou modifier un workflow - dans une porte directe au système.