Lire cet article en anglais : n8n Patches 18 Security Vulnerabilities in Bi-Weekly Update
n8n est l’une des plateformes d’automatisation de workflows auto-hébergées les plus utilisées, souvent présentée comme l’alternative fair-code à Zapier ou Make. Elle sert à faire circuler des données entre applications, déclencher des scripts selon un calendrier, et relier des services qui, à l’origine, n’avaient jamais été prévus pour communiquer entre eux. Comme elle tourne sur votre propre serveur et conserve généralement les identifiants de dizaines de comptes connectés, son niveau de sécurité compte davantage que celui de la plupart des outils de homelab.
Le 2 septembre 2026, l’équipe sécurité de n8n a publié sa mise à jour de sécurité bi-hebdomadaire, corrigeant 18 avis de sécurité depuis la précédente publication du 20 août. Cinq sont classés en sévérité High, treize en Medium. Publier un correctif de sécurité toutes les deux semaines est devenu la norme pour le projet.
Les correctifs High : deux évasions de sandbox menant à l’exécution de code
Les deux avis les plus notables concernent le sandbox d’expression de n8n : l’environnement restreint dans lequel s’exécutent les expressions écrites par les utilisateurs, ces petits bouts de code utilisés dans les nœuds de workflow pour reformater une donnée ou extraire une valeur d’une réponse JSON. Ce sandbox est censé empêcher ces expressions d’atteindre le serveur sous-jacent.
- GHSA-hw8v-xxg5-vvvx : évasion du sandbox d’expression par réattribution du sanitizer de champ de classe, pouvant mener à l’exécution de code.
- GHSA-6xcw-7xm6-48c6 : évasion du sandbox d’expression par altération d’un builtin partagé et injection dans le code-printer, menant à l’exécution de code.
En clair : n8n permet d’écrire de petites expressions de type JavaScript censées rester enfermées dans un sandbox, sans accès au système hôte. Ces deux avis décrivent des méthodes pour sortir de cet enfermement, jusqu’à l’exécution de code arbitraire sur la machine qui fait tourner l’instance n8n. Sur une installation auto-hébergée, cela veut dire que toute personne capable d’influencer les expressions d’un workflow, y compris via un modèle de workflow importé depuis une source externe, pourrait exécuter des commandes sur votre serveur, et pas seulement à l’intérieur de l’automatisation elle-même.
Trois autres failles High ont également été corrigées :
- GHSA-hh89-3r9w-qj3j : un déni de service non authentifié par épuisement du stockage persistant via le endpoint OAuth Dynamic Client Registration.
- GHSA-j535-v25q-vx3q : un ReDoS (déni de service par expression régulière) via le chemin de clonage du nœud Git, désormais atténué par un filtre de motifs bloqués activé par défaut.
- GHSA-34ff-336r-5q23 : un contournement de la restriction de domaine via un endpoint de recherche de modèle non protégé sur le nœud OpenAI Chat Model.
Les correctifs Medium
Les 13 avis de sévérité Medium couvrent des problèmes variés plutôt qu’une thématique unique : une configuration SSO OIDC désactivée restée pourtant active, un contournement de la validation d’approbation via un resumeToken WebSocket réutilisé de façon anonyme, un déchiffrement d’identifiants Generic-Auth sans vérification de propriétaire dans le streaming de logs, une divulgation d’informations personnelles entre locataires via les rôles de projet, une divulgation entre utilisateurs des identifiants de workflows actifs, un déni de service par prototype pollution, un contournement de la restriction du sandbox du nœud Git via des clés de configuration de branche ou de dépôt distant, une injection de chemin dans les nœuds Elasticsearch et ElasticSecurity, une URL de sonde non validée dans la configuration des identifiants IA, un contournement de la vérification de signature des webhooks GitHub Trigger via une réutilisation de chemin (HTTP 422), un contournement de la politique d’appel de sous-workflow via l’outil Agent Workflow, une autorisation incorrecte permettant la suppression inter-projets de workflows et d’identifiants via Source Control push, et une évasion du sandbox de fichiers du nœud Git via une URL distante relative.
Versions corrigées et action à mener
n8n a publié des correctifs sur ses trois lignes de version : la ligne v1 est corrigée en v1.123.76, la ligne beta en v2.38.2, et la ligne stable en v2.37.7.
Les instances n8n Cloud sont patchées automatiquement : les utilisateurs de cette offre n’ont rien à faire. Si vous faites tourner une instance auto-hébergée en dessous de ces versions corrigées, mettez à jour dès que possible. Les deux avis d’exécution de code justifient de traiter cette mise à jour en priorité plutôt que comme un simple entretien de routine. Vous pouvez vérifier votre version depuis l’interface de n8n, généralement affichée en pied de page ou dans les Paramètres, ou en inspectant le tag d’image de votre conteneur Docker.
Pour les instructions de mise à jour de votre instance, consultez le guide officiel de mise à jour de n8n. Les détails techniques complets de chaque avis, avec les versions concernées et les correctifs, sont publiés sur la page des avis de sécurité GitHub de n8n. L’annonce originale est disponible sur le forum communautaire n8n.