n8n’s security team runs its bulletin on a two-month cycle, and the edition dated August 20, 2026 covers nine advisories fixed since the last round. The team posted the details in a community forum update at 12:14 UTC, split into six rated High severity and three rated Medium. Two of the High-severity bugs are separate paths to remote code execution, which matters even on what’s otherwise a routine patch day for n8n, the self-hostable workflow automation platform.
Here’s the full set, grouped by severity, with each advisory’s GitHub Security Advisory identifier for reference.
High severity
- Expression Sandbox Escape via $fromAI Prototype Leak Leads to Host RCE (GHSA-9×83-43r8-5hwc)
- Expression Sandbox SpreadElement Bypass Enables Persistent Cross-Evaluation Native Object Mutation (GHSA-fg85-4wv2-p98j)
- Strapi, SeaTable, and Mailcheck Nodes Leak Decrypted Credential Secrets into Persisted Execution Error Data (GHSA-vrv8-j27g-g7cr)
- Gmail and Brevo Nodes Accept Non-String Content, Enabling Local File Read and SSRF (GHSA-95ph-833c-4wrp)
- Git Node Remote Code Execution via Incomplete Repository-Local Configuration Neutralization (GHSA-mwp5-2m32-r54h)
- Shared-Workflow Editor Can Exfiltrate Credentials via Workflow Tool Node Inline Sub-Workflow (GHSA-4r56-g65c-fm83)
Medium severity
- Query Injection in Elasticsearch and Google Cloud Firestore Nodes via Unescaped Expression Interpolation (GHSA-wxwj-8wv6-vpw2)
- Insights API Missing Per-Project Authorization Exposes Workflow Names and Execution Stats Across Projects (GHSA-jmmj-93rg-6j39)
- Legacy Request Helper SSRF Check Validates uri While Axios Dispatches url (GHSA-jp9j-jr97-w9pj)
Three of the High-severity items stand out. Two are sandbox escapes in the Code node’s expression engine: one abuses a prototype leak through the $fromAI helper, the other abuses a SpreadElement parsing bypass, and both end in native code execution on the host running n8n rather than staying contained inside the workflow sandbox. The third is a credential-leak bug shared by the Strapi, SeaTable, and Mailcheck nodes, which writes decrypted secrets into stored execution error data. That means those secrets can sit in your execution history even if nobody actually exploited the bug against you. Throw in the Git node’s remote code execution bug, caused by incomplete repository-local configuration handling, plus a Gmail and Brevo issue that accepted non-string content and opened a local-file-read and SSRF path, and this round covers more of n8n’s node ecosystem than most bulletins do.
The remaining fixes matter most on shared or multi-project instances. The Shared-Workflow Editor bug let an editor exfiltrate another user’s credentials through an inline sub-workflow inside the Workflow Tool node, a High-severity issue precisely because it works within n8n’s normal sharing model rather than some exotic bypass. On the Medium side, the Insights API fix stops a user from seeing workflow names and execution statistics that belong to someone else’s project, the query-injection fix closes an unescaped-expression path into the Elasticsearch and Google Cloud Firestore nodes, and the legacy request helper fix corrects a validate-the-wrong-field bug: the SSRF check validated the uri parameter while Axios itself dispatched url.
This is n8n’s normal bimonthly security cadence, not an emergency out-of-band disclosure, and n8n hasn’t reported active exploitation for any of the nine issues. That’s a real distinction; it should shape how urgently you treat this, but it’s not a reason to put the update off. n8n executes arbitrary workflow logic and often holds credentials for other self-hosted services in the same instance. Two independent roads to host-level code execution are still a good reason to patch promptly, especially on anything reachable from outside your own network.
Fixes landed across every branch n8n currently maintains: 1.123.73 for the 1.x line, 2.35.4 for the 2.x stable channel, and 2.36.2 for the 2.x beta channel. If you run n8n Cloud, you’re already patched and there’s nothing to do. If you self-host, check your running version against those numbers and update by following n8n’s own update guide if you’re behind. Already on the latest patch for your branch? You’re done.
Not sure which version you’re on? It’s shown in the n8n editor’s account menu, or in the N8N_VERSION environment variable if you’re running Docker Compose. In a typical homelab, n8n usually sits behind a reverse proxy while holding credentials for other self-hosted services (email, cloud storage, home automation hubs), so a host-level compromise doesn’t necessarily stay contained to n8n itself.
For background on the platform itself, see our n8n overview, which covers what it’s for and how to run it in Docker. The full list of advisories, including technical detail on each vulnerability, is indexed on GitHub’s security advisories page for anyone who wants to dig deeper before updating.