n8n : évasion de sandbox CVSS 8.7 permet l'exécution de commandes OS depuis les workflows

Les faits

Fin juillet 2026, les chercheurs de Security Joes ont divulgué une nouvelle vulnérabilité d'évasion de sandbox dans n8n, la plateforme open-source d'automatisation de workflows très utilisée dans les environnements d'entreprise. Référencée sous l'identifiant GHSA-gv7g-jm28-cr3m, la faille reçoit un score CVSS de 8.7 (Haute). Aucun numéro CVE n'avait été attribué par la base NVD au moment de la publication de cet article.

n8n propose un environnement d'exécution sandbox pour les expressions JavaScript utilisées dans les nœuds de workflow — des morceaux de code permettant de transformer des données, d'effectuer des calculs ou de conditionner des branchements logiques dans les flux d'automatisation. Ce sandbox est censé isoler le code des utilisateurs et empêcher tout accès au système d'exploitation sous-jacent. La vulnérabilité GHSA-gv7g-jm28-cr3m permet de contourner cette isolation : un éditeur de workflow authentifié peut forger des expressions spécialement conçues pour s'échapper du contexte sandbox et exécuter des commandes système arbitraires avec les privilèges du processus n8n.

La découverte est directement liée à un travail de recherche approfondi sur le correctif de CVE-2026-27577, une vulnérabilité similaire patchée par n8n en février 2026. Les chercheurs de Security Joes, en analysant les mécanismes de protection mis en place pour CVE-2026-27577, ont identifié un vecteur de contournement résiduel que le correctif initial n'avait pas adressé. Ce type de "patch bypass" est particulièrement inquiétant car il indique que la surface d'attaque sous-jacente n'avait pas été entièrement assainie lors de la première remédiation.

Les versions affectées couvrent l'ensemble des builds n8n antérieurs à 2.31.5 sur la branche 2.31, et toutes les versions 2.32.0 antérieures à 2.32.1 sur la branche 2.32. Les correctifs sont disponibles dans n8n 2.31.5 et 2.32.1. Les instances n8n sur des versions antérieures à 2.31 devraient également être considérées comme exposées, bien que les versions très anciennes n'aient pas été explicitement mentionnées dans la portée de l'advisory.

La criticité réelle de cette vulnérabilité dépend du modèle de déploiement de n8n et du modèle de confiance accordé aux utilisateurs éditeurs de workflows. Dans les déploiements d'entreprise où n8n est utilisé comme plateforme d'intégration centrale — connectant des bases de données, des API métiers, des services cloud et des systèmes internes — un attaquant ayant obtenu des droits d'édition de workflow peut utiliser GHSA-gv7g-jm28-cr3m pour pivoter vers l'infrastructure sous-jacente, accéder à des secrets stockés sur le serveur, lire des fichiers de configuration, ou établir une persistance sur le système.

n8n a connu une adoption croissante dans les entreprises depuis 2024, notamment comme alternative open-source à des plateformes d'automatisation commerciales telles que Zapier ou Make. Beaucoup d'organisations hébergent n8n en interne sur des serveurs exposés à leur réseau interne ou avec une interface accessible depuis Internet pour faciliter les intégrations. Ce profil de déploiement rend la vulnérabilité particulièrement pertinente : un accès initial à un compte utilisateur n8n, même avec des droits limités d'édition de workflow, peut devenir un pivot vers un accès système complet.

Au moment de la publication, aucune exploitation in-the-wild de GHSA-gv7g-jm28-cr3m n'avait été confirmée. La vulnérabilité ne figure pas encore dans le catalogue KEV de la CISA. Cependant, compte tenu de la disponibilité de détails techniques via la publication Security Joes, et de la tendance historique à l'exploitation rapide des failles d'évasion de sandbox sur des plateformes d'automatisation, la fenêtre avant exploitation potentielle est probablement courte.

Cette vulnérabilité s'inscrit dans une série de failles affectant n8n en 2026 : CVE-2026-27577 en février, CVE-2026-25049 au premier trimestre, et maintenant GHSA-gv7g-jm28-cr3m. Ce schéma récurrent suggère que la sandbox d'expression de n8n présente des faiblesses architecturales profondes qui nécessitent probablement une révision plus fondamentale que de simples correctifs ponctuels. Les organisations hébergeant n8n devraient intégrer ce contexte dans leur évaluation des risques et réfléchir aux contrôles compensatoires appropriés.

Impact et exposition

Toutes les instances n8n on-premises exécutant une version antérieure à 2.31.5 ou une version 2.32.0 antérieure à 2.32.1 sont exposées. Le risque est maximal lorsque l'interface n8n est accessible à des utilisateurs non totalement de confiance — employés de différents niveaux, prestataires, intégrateurs — ou lorsque des comptes d'édition de workflow ont été créés avec des politiques de mot de passe faibles ou sans MFA.

Recommandations

• Mettre à jour n8n vers 2.31.5 ou 2.32.1 immédiatement sur toutes les instances on-premises
• Revoir les droits d'édition de workflows — limiter strictement l'accès aux utilisateurs qui en ont un besoin opérationnel avéré, principe du moindre privilège
• Activer le MFA sur tous les comptes n8n disposant de droits d'édition de workflows
• Restreindre l'accès réseau à l'interface n8n : placer n8n derrière un VPN ou un bastion d'administration si l'accès Internet n'est pas indispensable
• Auditer les logs d'exécution des workflows à la recherche d'expressions inhabituelles ou d'activité depuis des comptes rarement actifs