L’équipe sécurité de n8n publie son bulletin selon un cycle bimestriel, et l’édition du 20 août 2026 regroupe neuf correctifs appliqués depuis la précédente livraison. Les détails ont été publiés dans une mise à jour du forum communautaire à 12h14 UTC : six failles classées en sévérité haute et trois en sévérité moyenne. Deux des failles à sévérité haute ouvrent des chemins distincts vers l’exécution de code à distance, ce qui pèse lourd même sur ce qui ressemble par ailleurs à un jour de correctifs de routine pour n8n, la plateforme d’automatisation de workflows auto-hébergeable.
Voici la liste complète, classée par sévérité, avec l’identifiant GitHub Security Advisory (GHSA) de chaque faille.
Sévérité haute
- Échappement du bac à sable d’expressions via une fuite de prototype $fromAI, menant à une exécution de code sur l’hôte (GHSA-9×83-43r8-5hwc)
- Contournement SpreadElement du bac à sable d’expressions permettant une mutation persistante d’objets natifs entre évaluations (GHSA-fg85-4wv2-p98j)
- Les nœuds Strapi, SeaTable et Mailcheck exposent des identifiants déchiffrés dans les données d’erreur d’exécution conservées (GHSA-vrv8-j27g-g7cr)
- Les nœuds Gmail et Brevo acceptent un contenu non textuel, ouvrant la voie à une lecture de fichier local et à du SSRF (GHSA-95ph-833c-4wrp)
- Exécution de code à distance dans le nœud Git via une neutralisation incomplète de la configuration locale au dépôt (GHSA-mwp5-2m32-r54h)
- L’éditeur de workflow partagé permet d’exfiltrer des identifiants via un sous-workflow imbriqué dans le nœud Workflow Tool (GHSA-4r56-g65c-fm83)
Sévérité moyenne
- Injection de requête dans les nœuds Elasticsearch et Google Cloud Firestore via une interpolation d’expression non échappée (GHSA-wxwj-8wv6-vpw2)
- L’API Insights ne vérifie pas les autorisations par projet, exposant noms de workflows et statistiques d’exécution entre projets (GHSA-jmmj-93rg-6j39)
- Le contrôle SSRF de l’ancien assistant de requêtes valide le champ uri alors qu’Axios envoie url (GHSA-jp9j-jr97-w9pj)
Trois failles à sévérité haute méritent qu’on s’y attarde. Deux sont des évasions du bac à sable dans le moteur d’expressions du nœud Code : l’une exploite une fuite de prototype via l’assistant $fromAI, l’autre un contournement de l’analyse SpreadElement, et toutes deux débouchent sur une exécution de code natif sur la machine qui héberge n8n plutôt que de rester confinées au bac à sable du workflow. La troisième est une fuite d’identifiants partagée par les nœuds Strapi, SeaTable et Mailcheck, qui écrit des secrets déchiffrés dans les données d’erreur d’exécution stockées : ces secrets peuvent donc dormir dans votre historique d’exécution même si personne n’a exploité la faille contre vous. Ajoutez à cela la faille d’exécution de code à distance du nœud Git, due à une gestion incomplète de la configuration locale au dépôt, et le problème Gmail/Brevo qui acceptait du contenu non textuel en ouvrant une voie de lecture de fichier local et de SSRF : ce lot touche une part du parc de nœuds n8n plus large que la moyenne des bulletins.
Les correctifs restants comptent surtout sur les instances partagées ou multi-projets. La faille de l’éditeur de workflow partagé permettait à un éditeur d’exfiltrer les identifiants d’un autre utilisateur via un sous-workflow imbriqué dans le nœud Workflow Tool : une sévérité jugée haute justement parce qu’elle fonctionne à l’intérieur du modèle de partage normal de n8n, sans contournement exotique. Côté sévérité moyenne, le correctif de l’API Insights empêche un utilisateur de voir les noms de workflows et les statistiques d’exécution d’un projet qui n’est pas le sien, le correctif d’injection de requête ferme une voie d’expression non échappée dans les nœuds Elasticsearch et Google Cloud Firestore, et le correctif de l’ancien assistant de requêtes corrige une validation du mauvais champ : le contrôle SSRF vérifiait le paramètre uri alors qu’Axios envoyait lui-même url.
C’est le rythme bimestriel habituel de n8n, pas une divulgation d’urgence hors cycle, et n8n n’a signalé aucune exploitation active pour aucune des neuf failles. C’est une vraie nuance, qui doit influencer le degré d’urgence, mais ce n’est pas une raison de repousser la mise à jour. n8n exécute une logique de workflow arbitraire et héberge souvent, sur la même instance, les identifiants d’autres services auto-hébergés. Deux chemins indépendants vers une exécution de code au niveau de l’hôte restent une bonne raison de corriger rapidement, en particulier sur tout ce qui est joignable depuis l’extérieur de votre réseau.
Les correctifs sont arrivés sur toutes les branches actuellement maintenues par n8n : 1.123.73 pour la branche 1.x, 2.35.4 pour la branche 2 stable, et 2.36.2 pour la branche 2 bêta. Si vous utilisez n8n Cloud, c’est déjà corrigé, rien à faire de votre côté. En auto-hébergement, comparez votre version actuelle à ces numéros et mettez à jour en suivant le guide de mise à jour officiel de n8n si vous êtes en retard. Déjà sur le dernier correctif de votre branche ? C’est réglé.
Vous ne savez pas quelle version tourne chez vous ? Elle apparaît dans le menu de compte de l’éditeur n8n, ou dans la variable d’environnement N8N_VERSION si vous utilisez Docker Compose. Dans un homelab typique, n8n tourne souvent derrière un reverse proxy tout en détenant les identifiants d’autres services auto-hébergés (messagerie, stockage cloud, hubs domotiques) : une compromission au niveau de l’hôte ne reste donc pas forcément cantonnée à n8n.
Pour en savoir plus sur la plateforme elle-même, direction notre fiche n8n, qui explique à quoi elle sert et comment la faire tourner sous Docker. La liste complète des failles, avec le détail technique de chacune, est indexée sur la page des security advisories de GitHub pour qui veut creuser avant de mettre à jour.