If you run self-hosted n8n, the versions to be on right now are 2.39.6 on stable, 2.40.1 on beta, or 1.123.80 on the v1 line. Those came out of the 16 September 2026 advisory, which closed sixteen issues, twelve of them high severity. Two weeks earlier another advisory closed eighteen more, including two expression sandbox escapes that lead to code execution. That is thirty-four security fixes in a single month, and none of them reach your instance until you pull them. n8n Cloud is patched for you. Your Docker container is not.
What n8n actually patched in September 2026
The two September advisories are worth reading in full, but here is the shape of them.
The 2 September advisory listed eighteen vulnerabilities, five high severity. The headline items were two separate expression sandbox escapes — one via class-field sanitizer rebinding, one via shared builtin tampering and code-printer injection — both leading to code execution. There was also an unauthenticated storage exhaustion bug in the OAuth dynamic client registration endpoint, a ReDoS in the Git node's blocked-file-pattern matching, and a domain-restriction bypass in the OpenAI Chat Model node's model-search endpoint. Fixed in 1.123.76, 2.37.7 and 2.38.2.
The 16 September advisory was smaller in count and worse in character: sixteen issues, twelve of them high. A few that should make any agency operator sit up:
- Inline agent node credential decryption. An agent node's tool introspection could decrypt any credential on the instance with no ownership check. On a shared instance that is every client's API key.
- Duplicate node IDs circumventing credential protections, exposing credentials to anyone who can edit a shared workflow.
- Community package install validation bypass in queue mode, via PubSub — meaning the protection you thought you had on arbitrary package installs did not hold on exactly the deployment shape agencies run.
- Path traversal in signed resume URLs, enabling cross-project approval forgery. If you run human-in-the-loop approval steps, that is your approval gate being forged.
- Injection in the Supabase and Oracle nodes (PostgREST filter injection and SQL injection respectively).
Fixed in 1.123.80, 2.39.6 and 2.40.1.
None of this is a reason to abandon n8n. An automation engine whose entire value proposition is running user-supplied expressions against arbitrary APIs is going to have a large attack surface by construction. The reason to pay attention is the delivery model.
Why self-hosted is the one that has to act
This is the part people miss when they pick self-hosted for cost reasons.
When n8n publishes a fix, Cloud instances get it. Self-hosted instances get a forum post. Your container keeps running the image you last pulled, indefinitely, and nothing in the UI shouts at you about it. We have taken over client instances that were eleven minor versions behind with three unread advisories between them, and the client's honest belief was that "it updates itself."
It gets worse when the advisory comes with a public exploit. In January 2026, CVE-2026-21858 landed at CVSS 10.0 — unauthenticated remote access to sensitive information, affecting 1.65.0 through 1.120.x, fixed in 1.121.0. Singapore's national cyber agency published an alert noting a proof-of-concept was already public and recommending that instances which could not patch immediately restrict access to public webhook and form endpoints, or go offline. Read that again: the official interim mitigation for an unpatched self-hosted n8n was turn it off.
That is the trade. Self-hosting gives you data residency, no per-execution pricing and full node access — the reasons we still recommend it for most agency workloads, as we covered in self-hosted vs cloud for agencies. It also transfers patch responsibility to you, permanently.
The cadence is the actual finding
One advisory is an event. Two advisories fourteen days apart is a schedule.
The practical consequence: stop treating n8n patching as incident response and put it on a recurring calendar. We run a standing biweekly maintenance window per instance. Most of the time it is a ten-minute no-op because there is nothing to apply. The point is that when there is something, there is already a slot for it, the backup script already ran, and nobody has to negotiate a downtime window with a client on a Thursday afternoon.
The mechanics of the window itself are the same as any other upgrade, and the order matters more than the speed. We wrote the full sequence up in n8n upgrade rollback: what actually works — short version: record the current version, dump the database, take the patched release on your own line rather than jumping lines, and bring main and workers up together.
That "own line" rule deserves emphasis, because a security advisory is exactly when people panic-upgrade. Each advisory gives you three fixed versions: one for v1, one for stable, one for beta. If you are on 1.123.x, the fix is 1.123.80 — not 2.39.6. Take the security fix, skip the major version migration, do the major version deliberately in a separate window when you have time to test.
Run n8n audit before you assume you're clean
Patching closes the vulnerabilities n8n found. It says nothing about the ones you built yourself.
n8n ships a built-in audit command that scans your instance for common self-hosting risks. Run it from the machine hosting n8n:
n8n audit
docker exec -it n8n n8n audit # same command, inside the container
Per the official docs, it reports on credentials that aren't used in any active workflow (stale keys nobody remembers issuing), expressions used in Execute Query and Query Parameters fields on SQL nodes (your own injection surface), nodes that interact with the host filesystem, and the built-in nodes that can fetch and run arbitrary code.
The credentials category is the one that consistently surprises people. Every agency instance accumulates them — a Meta token from a client who churned last year, a test Stripe key, an SMTP login from a migration. They're dead weight until an advisory like the 16 September credential-decryption issue turns the whole credential store into one blast radius. Delete what isn't in an active workflow. It costs nothing and it's the only security control on this page that doesn't require downtime.
The audit does not check your version against advisories, so it complements patching rather than replacing it. Run both.
The multi-tenant problem nobody wants to hear
Several September issues were privilege problems, not perimeter problems: credentials exposed to shared workflow editors, approval bypass, project-scoped variables resolved from attacker-controlled project IDs. An internal-only instance behind a VPN does not help with any of them.
If you run one n8n instance for several clients, your isolation model is n8n's project and credential-sharing permissions — and those are exactly what a duplicate-node-ID bug undermines. This is the strongest argument we know for taking multi-tenant separation seriously rather than relying on in-app permissions alone. Separate instances cost more in hosting and patch labour. They also mean one advisory does not put every client's credentials in the same basket.
And if an advisory describes credential exposure on an instance you were running unpatched with multiple editors, patching stops the bleeding but does not undo it. Rotate the keys that were reachable. Start with anything holding ad account or CRM access, because those are the ones that spend money.
What this looks like when it's working
A patched instance is a boring instance. The signals that it's actually working:
- You hear about the advisory from a subscription, not from a client. Watch the GitHub security advisories feed or the community Security Advisories category.
- Your version is pinned in the compose file, so you know exactly what you're running without SSHing in to look.
- A database dump exists from before the last upgrade, and someone has actually restored one at some point to prove it works.
- Errors surface on their own. If a patch does break a workflow, error handling and monitoring should tell you within minutes, not when a client asks why their leads stopped arriving.
- The credential list is short. Everything on it is used by an active workflow.
None of that is exotic. It's the same operational hygiene you'd apply to any production service. The reason it gets skipped on n8n specifically is that n8n feels like a tool rather than infrastructure — you built the workflow in a browser, in an afternoon, and it just works. Then it's running payroll notifications and ad spend pacing for five clients, and it's infrastructure, and nobody made the switch in their head.
Get a free automation audit
If you are not sure what version your n8n instance is on, or whether the last three advisories touched anything you use, that uncertainty is the finding.
We run self-hosted n8n automation for agencies and their clients, which means we're in the patch cycle whether we want to be or not. A free automation audit covers your current version against the open advisories, an n8n audit run and what it turns up, your credential inventory, and whether your rollback is real or theoretical.
Book a free automation audit and we'll tell you where you stand — including if the answer is "you're fine, keep doing what you're doing."