n8n Security Update September 2026: 14 Advisories, Fixed Versions and Hardening

Running n8n yourself and keeping it up to date? WZ-IT installs and operates n8n in your environment, including updates, backups and monitoring, see n8n managed hosting and CVE monitoring. Book a meeting

On 30 September 2026 n8n published 14 new security advisories, ten rated high and four rated medium. Three of the vulnerabilities can be reached without an n8n account, another allows code execution in the Git node, and another allows takeover of the owner account via the MCP server. They are fixed in n8n 2.41.4 (stable), 2.42.1 (beta) and 1.123.83 (1.x line).

It is the third bundled update within one month. This article groups the 14 advisories by attack prerequisite, shows in a version matrix which fixed version addresses which issue, and describes hardening that makes an n8n instance less exposed regardless of the next update. All information reflects the state of 1 October 2026 and follows n8n's advisory overview on GitHub.

Table of Contents

1. What was published on 30 September
2. Which version fixes the vulnerabilities
3. The 14 advisories at a glance
4. Vulnerabilities without authentication
5. Vulnerabilities for authenticated users
6. Three bundled updates in September
7. Interim measures if the update has to wait
8. Hardening n8n permanently
9. Making updates plannable
10. Our approach at WZ-IT
11. Further guides

What was published on 30 September

The missing CVE numbers have a practical consequence: vulnerability scanners that work exclusively with CVE identifiers may not detect these vulnerabilities. The relevant reference is the GHSA identifier in n8n's GitHub advisory database. Of the 18 advisories in the update of 2 September, 16 carry a CVE number; the entries of 16 and 30 September have none so far.

Which version fixes the vulnerabilities

n8n publishes in three lines. The stable version is intended for production, beta is the most recent release, and patch versions continue to be released for n8n 1.x (n8n docs, install with Docker).

Source: n8n releases on GitHub, as of 1 October 2026.

Two special cases:

• 2.42.0 is not sufficient. This version from 29 September only fixes GHSA-p3pg-xw4f-m72c. All other vulnerabilities in the beta line are closed only in 2.42.1.
• There is no patch for 2.40.x. The last version of this line, 2.40.7, was released on 25 September and therefore predates the advisories. The path leads to 2.41.4.

With n8n, the version number alone does not tell whether an instance is vulnerable. What matters is comparing the installed version with the fixed version of its line.

The 14 advisories at a glance

The "Lines" column shows which release lines are affected according to the advisory. An advisory that only lists 2.x concerns features that do not exist in 1.x, and vice versa.

In summary: twelve of the 14 advisories are relevant on a 2.x instance, seven on a 1.x instance.

Vulnerabilities without authentication

These three advisories can be reached without an n8n account and are therefore relevant for every instance whose webhook, form or chat routes are reachable from the internet.

Send-and-Wait HMAC bypass (GHSA-728h-pmr2-7cgh). The endpoint for waiting executions accepts a Send-and-Wait reference in two forms and chose the validation before normalising the second form. A request in that form was accepted without the signature an approval normally requires. Anyone who knows an execution's resume token can grant an approval intended for someone else. The downstream steps run with the workflow owner's credentials and, depending on the workflow, can reach command execution. Workflows in which a public trigger precedes an approval step and exposes the resume token are particularly affected.

Unbounded OAuth clients (GHSA-3qcw-p65v-c7vq). The unauthenticated authorize endpoint created a new record for every differing client identifier, without a cap, expiry or deletion path. An attacker without an account can grow the table until the disk is full. This is an availability issue, not a data leak.

Workflow execution via the webhook path (GHSA-4c7j-qff5-r9cx). For webhooks with a dynamic path, a server-generated identifier is the only unguessable part of the URL. Resolution matched on the path alone, so a request without that identifier still started the workflow, under the credentials of the associated project. The same resolver serves the form and MCP routes. Authentication configured on the webhook node still applies.

Vulnerabilities for authenticated users

The remaining eleven advisories require an n8n account. This lowers the risk for instances with few, trusted users, but not for instances on which several teams, external contractors or business departments build their own workflows.

The concentration in the newer AI features stands out: agents, the MCP server and the AI Workflow Builder together appear in five of the 14 advisories. Disabling these modules where they are not used reduces the attack surface permanently. How permissions and approvals for AI agents can be designed in general is covered in the article AI agents: permissions and approvals.

The MSSQL case shows a pattern that also affected the Oracle and Supabase nodes in September (GHSA-4wf3-rgqr-xcp3, GHSA-xrqg-3xcp-h45x): values from expressions inserted directly into a query are prone to injection. The advisory recommends moving the node to typeVersion 1.1 or later and passing dynamic values via Query Parameters.

Three bundled updates in September

Since 13 May 2026 n8n bundles security advisories into a bi-weekly update, published on Wednesdays. Critical vulnerabilities that cannot wait are still announced immediately (n8n blog on vulnerability disclosure). In September 2026 this resulted in three dates:

Sources: Security update 2 September 2026, Security update 16 September 2026 and the advisory list on GitHub. The critical rating did not occur in September; the most recent critical advisories date from 13 May 2026.

The number of advisories alone says little about the security of the software. n8n attributes the increase to more regular security testing and attention from researchers. What counts for operations is something else: anyone running n8n themselves needs a process that can roll out a new fixed version every two weeks without each update turning into a separate project. Following the current cadence, the next date would be 14 October 2026.

Interim measures if the update has to wait

Each advisory lists workarounds together with the note that they do not fully remediate the risk. They are meant for the time until the update.

Restricting the webhook routes is only feasible where the callers are known, for example internal systems or fixed IP ranges of a SaaS provider. Public forms and chats cannot be protected this way.

Hardening n8n permanently

The advisories show which features are affected repeatedly: Code and Git nodes, the expression sandbox, credentials in shared workflows, public endpoints and, most recently, the AI modules. Hardening that restricts these areas works beyond the individual update.

Sources: n8n 2.0 breaking changes, SSRF protection, security environment variables.

The page on security environment variables still lists false as the default for N8N_BLOCK_ENV_ACCESS_IN_NODE, while the n8n 2.0 breaking changes list true. If you rely on the value, set it explicitly.

Besides the variables, three organisational points matter:

• Separate network exposure. The editor belongs on an internal network or behind a VPN. Only the routes a workflow actually needs are publicly reachable, i.e. webhooks, forms or chats. A reverse proxy such as Caddy can treat the paths separately; the base installation is described in the article n8n on Ubuntu with Caddy.
• Keep permissions tight. Many advisories concern editors of shared workflows. If workflows are shared only with people who are allowed to use all credentials in them anyway, this class of vulnerability has little impact.
• MFA for all accounts with the owner or admin role. For GHSA-5jr4, MFA made the difference between affected and not affected.

Making updates plannable

According to n8n, a new minor version is released most weeks, and n8n recommends updating at least once a month (n8n docs, update n8n). With the bi-weekly security cadence, a monthly window is not always enough for security fixes. n8n itself recommends that operators maintain a documented fast-track process for security patches.

A sequence that works well:

1. Pin the version. Use a specific version such as n8nio/n8n:2.41.4 instead of latest in the Docker Compose file. This keeps it clear what is running, and a rollback is unambiguous.
2. Stay on the stable line. n8n recommends stable for production and notes that beta may be unstable. The 2.42.0 case also shows that a new beta version does not automatically contain all fixes.
3. Subscribe to security notices. The bi-weekly updates appear in the n8n forum and by email; the GHSA list on GitHub can be watched.
4. Back up before the update. Database backup (PostgreSQL or SQLite) and a copy of the encryption key, without which stored credentials can no longer be read.
5. Test after the update. Trigger critical workflows with fixed test data, check error workflows and the execution log.

If you need to track vulnerabilities across several self-hosted applications, the overarching approach is described in the article CVE monitoring for self-hosted software. The missing CVE numbers at n8n show why monitoring should also evaluate vendor advisories and not just CVE feeds.

Our approach at WZ-IT

1. Inventory. Installed version and release line, deployment type (Docker, Kubernetes, queue mode), reachable routes, users and roles, modules in use such as agents or the MCP server.
2. Assess exposure. Match the instance against the advisories, including which vulnerabilities are reachable without authentication and which workflows have public triggers ahead of approval steps.
3. Apply the update. Back up the database and encryption key, update to the fixed version of the matching line, test the most important workflows.
4. Harden. Environment variables, excluded nodes, SSRF protection, MFA, separation of editor and public routes at the reverse proxy.
5. Ongoing operation. With n8n managed hosting, WZ-IT takes care of installation, updates, backups and monitoring. New n8n advisories are assessed for exposure and impact as part of CVE monitoring. Terms are set out in the quote.

For an overview of all operations services, see the Managed Operations hub.

Further guides

• Install n8n on Ubuntu with Caddy, base installation with Docker and automatic TLS certificates.
• Business process automation with n8n and AI agents, where n8n is used in companies.
• CVE monitoring for self-hosted software, how to track vulnerabilities across many applications.
• LiteLLM vulnerability: hardening the gateway, a critical vulnerability in the AI gateway and the matching hardening.
• AI agents: permissions and approvals, how to design permissions and human-in-the-loop for agents.
• n8n managed hosting, installation, workflow development and operation by WZ-IT.

Security update applied, but hardening still missing? We review the version, configuration and network exposure of your n8n instance and can take over ongoing operation. Book a meeting

Sources

• n8n, security advisories on GitHub
• GHSA-728h-pmr2-7cgh, Send-and-Wait HMAC bypass
• GHSA-3qcw-p65v-c7vq, unbounded OAuth client persistence
• GHSA-4c7j-qff5-r9cx, cross-project workflow execution via webhook path
• GHSA-5jr4-xmvf-frmj, MCP workflow validation owner account takeover
• GHSA-x8wx-g24x-3549, code execution in the Git node
• GHSA-5qpp-pqww-h7fp, SQL injection in the Microsoft SQL node
• n8n releases on GitHub
• n8n community, security update 2 September 2026
• n8n community, security update 16 September 2026
• n8n blog, How n8n Handles Vulnerability Disclosure
• n8n docs, install with Docker (stable and beta release lines)
• n8n docs, update n8n
• n8n docs, v2.0 breaking changes
• n8n docs, enable SSRF protection
• n8n docs, security environment variables