Patching n8n is the easy half. The structural problem is that your orchestrator holds the densest credential store in the business behind one authenticated surface — and agent nodes keep widening what counts as authenticated.
Last Updated: October 12, 2026
The October 2026 n8n sandbox-escape advisories are real and you should patch today. But patching does not fix the structural problem: a self-hosted n8n instance concentrates CRM, ERP, cloud, payment, email and model API credentials into one process that also evaluates user-supplied JavaScript, and the key that decrypts all of them sits in that process's environment. Assume the next escape lands. Design so that an escape yields short-lived, narrowly scoped tokens instead of your whole credential estate.
What actually shipped in the last six weeks
On 5 October 2026, n8n published two advisories on the same day. CVE-2026-86076 (CVSS 8.7) is an expression sandbox escape: the expression compiler resolved its sanitizer through a dynamically-scoped this, so a class field named __sanitize could rebind the sanitizer and reach the Function constructor. The fixed versions are 1.123.76, 2.37.7 and 2.38.2. The same-day companion, CVE-2026-44790, is a CVSS 9.4 argument-injection issue (CWE-88) that needs only network access and low privileges. Its published detail is thin — that is worth stating plainly rather than dressing up.
Four days earlier, n8n's routine bi-weekly bulletin carried fourteen advisories at once. That batch included SQL injection in the Microsoft SQL node via expression interpolation, a send-and-wait HMAC bypass allowing unauthenticated approval of waiting executions, stored XSS in the binary-data preview, and prototype pollution in the AI workflow builder — fixed in v1.123.83, v2.42.1 and v2.41.4. Two entries in that list matter more than their "High" label suggests, and I will come back to them.
None of this is new behaviour for the platform. Pillar Security's CVE-2026-25049 write-up — which they score 10.0 on CVSS 3.1 — showed that an authenticated user could execute system commands, read N8N_ENCRYPTION_KEY from the environment, decrypt every stored credential, and on n8n Cloud reach internal services including the secrets API and the internal npm registry. Earlier in the year there was CVE-2026-1470 at CVSS 9.9, disclosed 27 January 2026, and CVE-2026-21858 ("Ni8mare") on 7 January, which required no authentication at all. In March, two more criticals followed: CVE-2026-27577 (9.4), another expression sandbox escape, and CVE-2026-27493 (9.5), unauthenticated expression evaluation through the Form nodes.
The pattern is not incompetence. It is a platform whose core value proposition — arbitrary JavaScript inside any node parameter — is permanently adjacent to arbitrary code execution. Every sandbox around an expression language is a denylist pretending to be a boundary.
Why your orchestrator is the densest credential store in the company
Think about what a mature n8n instance accumulates over eighteen months. Salesforce or HubSpot with write scope. A Postgres read-write user. AWS or GCP service account keys. Stripe. Google Workspace OAuth with domain-wide delegation, because someone needed to send mail as anyone. Slack bot tokens. Xero. OpenAI and Anthropic keys with no spend ceiling. A GitHub PAT, usually with repo, because the Git node needed it.
No other system in a mid-sized business holds that set. Your identity provider holds identities, not third-party API keys. Your secrets manager holds secrets, but it does not also execute user-authored JavaScript. n8n holds both, in one process, protected by one symmetric key that is usually sitting in a Docker --env-file on the same host.
And the root of trust is more overloaded than the docs let on. GitGuardian found that the JWT signing secret was derived from N8N_ENCRYPTION_KEY by taking every other character — so a 32-character key yields a 16-character signing secret — and that the key also fed the public instance ID. Of 31,793 instances they found, 4,398 exposed that public instance ID (13.8%), and 129 internet-accessible instances had IDs matching weak encryption key values already published on GitHub. That is an offline-crackable path to credential decryption with no CVE required.
Blast radius, in orchestration terms
Not "what can the attacker run" but "what can the attacker authenticate as, for how long, against which destinations, before anyone notices". On a default self-hosted n8n, the answer is: everything stored, indefinitely, to anywhere on the internet, silently.
The blast radius, layer by layer
Five layers matter, and they fail in sequence.
1. Expression and Code node execution. This is the layer every advisory is about. In n8n 1.x, Code node execution ran inside the main process unless you explicitly enabled task runners; from 2.0 the enablement variable is deprecated but external mode still requires a separate runners deployment. Most self-hosted instances I have seen in the wild never made that change. Internal mode means a sandbox escape lands in the same memory space as your credentials.
2. Encryption key handling. Once step one lands, the key is one process.env read away. There is no HSM boundary, no per-credential unwrap, no audit event for decryption. The database file and the key together give offline plaintext for every credential — permanently, regardless of whether you later patch.
3. Community nodes and the npm surface. Installing a community node is installing unreviewed npm code into the process that holds your keys. There is no capability model. A node that claims to talk to one SaaS vendor can read the environment. This risk is entirely yours and no CVE will ever be filed for it.
4. The agent and MCP layer. This is the part that is genuinely new, and the October batch proves it. n8n's shared-workflow credential check inspected a node's credentials field, but the agent node keeps model and per-tool credential IDs elsewhere in its parameters — so an editor of a shared workflow could have the owner's credentials resolved for tools they control and sent to a destination they choose. Separately, the MCP workflow-validation tool evaluated caller-supplied code in the main process through an interpreter that permitted assignment onto shared prototypes; a member holding only a read grant could make a server-side permission check return truthy, and the reporter drove it to full takeover of the owner's account. Notably, that advisory records that accounts protected by MFA were not affected — one of the few places where a mundane control actually held the line.
5. Queue workers. In queue mode your workers pull jobs and need credential decryption too. Teams scale workers horizontally and quietly multiply the number of hosts holding the encryption key, often onto nodes with weaker network policy than the main instance. Your credential boundary is now the union of every worker's security posture.
How one expression becomes every API key
A contractor, a junior marketer, a reused API token from a public commit, or an agent node acting on model-generated input.
A crafted expression reaches the Function constructor and executes inside the n8n Node.js process.
N8N_ENCRYPTION_KEY from the environment, plus the credentials table from SQLite or Postgres.
No further requests to the target. Patching afterwards changes nothing about the stolen plaintext.
Cloud accounts, CRM exports, payment APIs, mailbox access — each using legitimate credentials that look normal in the destination's logs.
Patch first — then assume the credentials are already gone
Do the obvious thing immediately: move to 2.42.1, 2.41.4 or 1.123.83 at minimum, which covers the 1 October batch and sits above the 5 October fix lines. Confirm the running version from inside the container rather than from your deploy pipeline, because a cached image tag will lie to you.
Then do the thing most write-ups skip. If an untrusted or semi-trusted account held workflow-edit rights during any exposure window, rotate every credential the instance could decrypt. Not the suspicious ones — all of them. Decryption leaves no trace in n8n, so absence of evidence is the expected state after a successful attack, not reassurance.
Treating "we upgraded" as the remediation
It happens because the advisory's "Patches" section is the only actionable-looking text in the document. But these are credential-disclosure bugs with offline follow-on. Upgrading closes the door; it does not recall the keys that walked out of it. VulnCheck observed in-the-wild exploitation of CVE-2026-21858 against canaries and linked exploitation of the chained CVE-2025-68613 to the Iranian group MuddyWater — mass scanning, not targeted interest in your workflows.
N8N_ENCRYPTION_KEY and a separate N8N_USER_MANAGEMENT_JWT_SECRET, invalidate all sessions and public API keys, and review the destination systems' own audit logs for the exposure window — not n8n's.The baseline hardening below interrupts the chain at several points. It is adapted from GitGuardian's hardened configuration; validate each variable against your deployed version, because several only exist in newer 2.x lines.
# Independently generated. Never derive one from the other.
N8N_ENCRYPTION_KEY=<openssl rand -hex 64>
N8N_USER_MANAGEMENT_JWT_SECRET=<a different openssl rand -hex 64>
N8N_ENFORCE_SETTINGS_FILE_PERMISSIONS=true
# Shrink the unauthenticated surface
N8N_PUBLIC_API_DISABLED=true
N8N_PUBLIC_API_SWAGGERUI_DISABLED=true
N8N_MCP_MANAGED_BY_ENV=true
N8N_MCP_ACCESS_ENABLED=false
# Starve workflow code of the environment
N8N_BLOCK_ENV_ACCESS_IN_NODE=true
NODE_FUNCTION_ALLOW_BUILTIN=
NODE_FUNCTION_ALLOW_EXTERNAL=
# Remove nodes you do not actually use
NODES_EXCLUDE='["n8n-nodes-base.executeCommand","n8n-nodes-base.ssh","n8n-nodes-base.git"]'
# Execute code outside the process that holds your keys
N8N_RUNNERS_MODE=external
N8N_RUNNERS_AUTH_TOKEN=<separate random secret>External task runner mode is the single highest-leverage change on that list. It is also the one people skip, because it means running and monitoring another container. Do it anyway.
An isolation pattern that survives the next sandbox escape
Hardening reduces probability. Architecture reduces consequence. Four changes, in the order I would sequence them on a real build.
Per-workflow service identities. Stop having one "n8n user" in Salesforce, one in AWS, one in Postgres. Each workflow gets its own identity in each downstream system, scoped to the objects and verbs it actually touches. This is tedious and it is the whole game: it converts "the orchestrator was compromised" into "these four workflows were compromised". It also makes downstream audit logs legible, because you can tell which automation did what.
Brokered, short-lived credentials. Put a small credential broker between n8n and the real secrets. n8n holds only a broker token; the broker mints a token valid for minutes, scoped to one workflow identity, and logs every issuance. A sandbox escape then yields a short-lived token for a narrow scope plus a broker log entry that fires an alert, rather than a permanent AWS key. Be honest about the limit: at execution time the plaintext still passes through the n8n process, so an attacker with persistence can keep requesting tokens. What you gain is expiry, scope and — critically — a decryption audit trail that n8n itself does not provide.
Egress allow-lists. n8n has no concept of binding a credential to a destination. An HTTP Request node will happily post your Stripe key to an attacker's domain. Enforce this at the network layer instead: a Kubernetes NetworkPolicy or an egress proxy with an explicit allow-list of API hostnames, applied to the n8n pods and the task runners. This is the control that actually stops exfiltration, and almost nobody deploys it.
Split high-privilege writes out of the orchestrator entirely. Anything that moves money, deletes records, grants access, or sends on behalf of a human should not be an n8n node holding a credential. Make it a small service you own with a narrow, idempotent interface — POST /refund {order_id, amount} — that does its own authorization and rate limiting. n8n calls the service; the service holds the Stripe key. An orchestrator compromise then buys refunds within your own policy ceiling instead of the Stripe account. This is the pattern we default to in agentic builds at Twarx: the orchestrator decides, a hardened action service executes. See how we scope that split.
Giving the agent node the credentials you would give a senior admin
Agent tooling makes over-permissioning feel efficient: one broad credential, and the model figures out which calls to make. The October advisories show why that is the wrong instinct — the credential-sharing check did not even look where the agent node stores its per-tool credential IDs, and model-generated tool arguments are untrusted input by construction.
Self-hosted, n8n Cloud, or a custom stack
The honest comparison, written from builds rather than from marketing pages. Note that n8n Cloud instances are patched automatically — a genuine advantage — but Pillar's research also showed that the shared multi-tenant architecture meant a single malicious user could potentially reach data belonging to other customers. Neither option is strictly safer; they trade different risks.
| Option | Choose when | You still own | Main failure mode |
|---|---|---|---|
| Self-hosted n8n, default config | Internal tooling, no regulated data, one or two trusted builders | Patching within days, key custody, network policy, backups | You miss one bi-weekly bulletin and an internet-exposed instance gets mass-scanned |
| Self-hosted n8n, hardened + brokered credentials | Production business workflows, data residency requirements, multiple builders | Everything above plus the broker, egress proxy and per-workflow identities | Operational drag — teams quietly bypass the broker to ship faster |
| n8n Cloud | Small teams without platform engineering, non-sensitive integrations | Who you invite, which credentials you store, MFA enforcement | Multi-tenant isolation is the vendor's problem and the vendor's incident |
| n8n for orchestration + custom action services | Payments, PII, healthcare, anything with a regulator | The action services, their authz and their own deploy pipeline | More code to maintain; the split has to be enforced in review or it erodes |
| Fully custom orchestrator | You have a platform team and workflows are a product surface, not internal glue | All of it, including the sandbox bugs you will write yourself | Rebuilding 400 integrations badly |
For most teams the second and fourth rows combined are the right answer. The fifth is almost never worth it; your hand-rolled expression sandbox will not be better than one that has absorbed dozens of CVEs worth of adversarial attention. See how these architectures get sequenced.
What I would not put in n8n right now
Three categories, stated as flatly as I would in a client room.
Do not give an n8n instance Google Workspace domain-wide delegation. A single credential that can read and send as every employee is not a workflow credential; it is a breach waiting for a CVE. Use a dedicated service account per workflow with explicit per-mailbox grants, or move the mail action behind a service you control.
Do not run a shared multi-tenant n8n for clients on one instance with one encryption key. The sharing and permission bugs in the October batch are specifically cross-user and cross-project issues. One instance per client, or one Kubernetes namespace per client with separate keys.
Do not let an autonomous agent hold write credentials to a financial system without a human approval gate — and if you use n8n's send-and-wait approval for that gate, note that the 1 October batch included an HMAC bypass allowing unauthenticated approval of waiting executions. An approval control that an unauthenticated party can satisfy is theatre. Put the gate in the action service, where you control the signature verification.
The uncomfortable summary: n8n is a good orchestrator and a bad vault, and the industry has been using it as both. Separating those two jobs is a week of work that the next advisory will make look cheap. If you want help scoping that separation against your current instance, start here.
Frequently Asked Questions
Which n8n version do I need to be on right now?
At minimum 1.123.83, 2.41.4 or 2.42.1, which carry the fourteen advisories published in n8n's 1 October 2026 bulletin. Those versions also sit above the 1.123.76 / 2.37.7 / 2.38.2 fix lines for the 5 October expression sandbox escape. Verify the version from inside the running container, not from your deployment manifest, since a cached image tag will report the intended version rather than the running one.
If I patch, do I still need to rotate credentials?
Yes, if any account you do not fully trust had workflow-create or edit rights during the exposure window, or if the instance was reachable from the internet. These bugs lead to encryption key disclosure, and decryption happens offline afterwards. Patching stops new access; it does not revoke credentials already extracted. n8n logs no event when a credential is decrypted, so you will not find confirmation either way.
Is n8n Cloud safer than self-hosting?
It removes your patching lag, which is the most common real-world failure. It introduces multi-tenant exposure instead: Pillar Security's research found that on n8n Cloud a single malicious user could potentially reach other customers' data and internal platform services. If your main risk is operational neglect, Cloud is better. If your main risk is a regulator asking where credentials live, self-hosted with brokered secrets is better.
Do external task runners actually prevent credential theft?
They move Code node execution into a separate container, so code execution there does not automatically land in the process holding the encryption key. That is a real boundary and worth deploying. It does not cover expression evaluation paths that run in the main process, nor community nodes loaded into core. Treat it as one layer, combined with a separate JWT secret, blocked environment access, and network egress controls.
What makes AI agent nodes riskier than ordinary nodes?
They widen what counts as authenticated. Agent nodes store per-tool credential references in a different place than standard nodes, and n8n's shared-workflow credential check missed that location until the 1 October patch, letting an editor have the owner's credentials resolved for tools they control. Add model-generated tool arguments and MCP servers evaluating caller-supplied input, and the set of things that can trigger a privileged call grows well beyond your user list.
Should we stop using n8n?
No. Any platform that evaluates user-supplied expressions will produce sandbox escapes, and n8n's disclosure cadence is more transparent than most. The change to make is architectural: keep n8n as the orchestration and decision layer, stop using it as the primary credential store, and move high-privilege write actions into small services with their own authorization. Then a sandbox escape costs you an incident rather than the business.
Research digest
AI Research Briefing
Honest insights on AI agents, Small Language Models, and local RAG. No hype. Only when we have something worth sending.
- No hype, just measurable outcomes
- Read by 2,400+ engineers
- Unsubscribe anytime
