n8n's August 2026 Metabase breach exposed 136 user records, five of them with password hashes, five months after a separate, fixed but severe sandbox-escape chain (CVSS 9.5 and 9.4) showed the platform could leak every credential stored inside it. Neither event makes n8n uniquely unsafe. Both prove the same architectural point: a workflow-automation platform is a credential vault, and any Dutch mkb running Exact Online, AFAS or e-Boekhouden through it needs to treat it like one.
What happened with n8n and Metabase in August 2026?
On 6 August 2026, n8n told users it had been made aware of a security incident affecting Metabase, a third-party analytics tool the company uses internally. Unauthorised activity took place on 3 August; Metabase, which had a critical zero-day SQL-injection flaw tracked as GHSA-vwf4-m7j8-wcjf with a CVSS score of 10.0 sitting in an unauthenticated password-reset endpoint, patched the hole shortly after.
n8n's investigation found that 136 records containing names and email addresses were accessed across both self-hosted and n8n Cloud users. Five of those records held bcrypt-hashed n8n Cloud account passwords; self-hosted passwords are never shared with n8n, so those installs were not directly exposed by this incident. Because the queries an attacker ran returned, in n8n's words, "a variable, non-deterministic set of rows each time they are run," the company says it cannot determine exactly which records were touched — which is why it is resetting credentials broadly rather than only for confirmed victims. The investigation also surfaced an older, unrelated bug (already fixed via an earlier pull request) that had stored a small number of Cloud passwords in plain text; n8n contacted those 25 account holders directly as a precaution. The company notified its Data Protection Officer and the Berlin Commissioner for Data Protection and Freedom of Information, the standard notification path for a Germany-incorporated processor under the GDPR.
Why is a workflow-automation platform a "credential vault" by design?
The Metabase breach touched account metadata, not workflow credentials. The more structurally serious story sits five months earlier. n8n was notified of the flaw in early February 2026 and shipped a fix within weeks; security researchers at Pillar Security then published the full technical disclosure in March, describing two critical n8n vulnerabilities that, chained together, let an unauthenticated attacker take over an n8n instance and read every credential it held. Per Pillar's writeup, the first flaw — CVE-2026-27493, CVSS 9.5 — was a second-order expression-injection bug in n8n's Form nodes: because n8n evaluated a submitted form value in two separate passes, an attacker could put a shell command in a public form's Name field and have it executed on the second pass. Chained with a second flaw, CVE-2026-27577 (CVSS 9.4), the attacker could escape n8n's sandbox entirely and execute commands on the underlying host.
Pillar's own framing is the sentence worth keeping: "n8n is a credential vault by function. It stores keys to every system it connects to. A single sandbox escape exposes the n8n instance and every connected system." That is not a criticism specific to n8n — it is true of Make, Zapier, Power Automate, or any orchestration layer sitting between your business systems and holding the keys to reach them. What made this particular chain more exposed is how directly reachable the attack surface was: Form endpoints are meant to be reachable from the open internet, so exploitation required nothing more than one public form submission and one follow-up request. On n8n Cloud's shared, multi-tenant infrastructure, Pillar noted the blast radius extended further still — a sandbox escape triggered through one tenant's workflow could open a path into shared infrastructure serving other customers.
What did the sandbox-escape fix actually change, and what didn't it change?
n8n shipped the fix in versions 2.10.1, 2.9.3 and 1.123.22, released in late February 2026. Technically, the patch removed the redundant second expression-evaluation pass that made the injection possible, added several global identifiers to the sandbox's blocked-identifier list, and hardened the AST-aware identifier analysis that decides what a workflow expression is allowed to reference. Any instance still running an older build carries the full RCE-to-sandbox-escape chain today, reachable through nothing more than a public form.
What the patch could not fix, because it was never a code defect, is the fact Pillar's writeup names directly: n8n's credential store is only as safe as everything around it. The August Metabase incident is the proof. It had nothing to do with the Form-node bug, ran through a completely unrelated internal analytics vendor, and still ended with n8n resetting user credentials as a precaution. A patched instance and a hardened sandbox close the specific vulnerability class Pillar found. They do nothing about your own account hygiene, your credential rotation policy, or the security posture of whichever vendor n8n itself happens to depend on next.
n8n Cloud or self-hosted: which risk profile fits a small business?
For a business running n8n without a dedicated security function — most Dutch mkb's between one and fifty FTE — n8n Cloud is usually still the pragmatic choice, precisely because patching becomes n8n's job rather than yours: both the February sandbox fix and the August credential reset shipped without requiring action from most customers. The trade-off Pillar flagged is real — a sandbox escape on shared Cloud infrastructure carries cross-tenant risk that a single-tenant, self-hosted instance does not — but that risk sits behind n8n's own patch cadence, which so far has moved faster than most SMEs' internal IT capacity would.
Self-hosting shifts that responsibility onto you. It is the right call once someone actually tracks n8n's security advisories and treats the instance the way you would treat a database holding your CRM's API keys: network-segmented, unreachable from the open internet unless a workflow genuinely needs a public endpoint, and patched on a schedule rather than whenever someone remembers. A business in the 250–500 FTE range that already runs its own IT-security or governance function is the more natural home for self-hosted n8n; without that function already in place, self-hosting mostly adds an unpatched attack surface nobody is actively watching.
What should you actually do this week if you run n8n?
The two incidents point to the same short list of actions, regardless of which one worries you more.
- Confirm your n8n version is 2.10.1, 2.9.3 or 1.123.22 or newer — anything older is still exposed to the Form-node RCE-to-sandbox-escape chain.
- If self-hosted, audit every workflow with a public Form trigger for fields that feed into an expression, and treat every field on a public form as attacker-controlled input by default.
- Rotate the API keys and OAuth tokens for any system n8n touches that holds financial or customer data — Exact Online, AFAS, e-Boekhouden, WhatsApp Business — on a fixed calendar, not only after an incident makes the news.
- Scope every connected credential to least privilege: a workflow that only reads Exact Online reporting data does not need a key that can also post facturen.
- On n8n Cloud, enable MFA and reset your password even if you never received a direct email — n8n itself says it cannot confirm which accounts the Metabase queries touched.
Does this mean you should switch to Make or Zapier instead?
No — and the honest reason is that Make and Zapier are the same credential vault behind a different interface. Neither has published its own version of Pillar's disclosure, but that reflects where security researchers have been looking, not a fundamentally different architecture. Our comparison of n8n, Make and Zapier still holds on features and pricing; nothing in this incident changes that verdict.
What it should change is the question you ask before connecting a live financial system to any automation platform, whether you run it yourself or bring in an implementation partner: what is the patch cadence, how tightly are credentials scoped per workflow, and can every connected credential be audited after the fact. That third question is also where MCP's permission model is worth the comparison — the newer protocol was designed from the outset around scoping what a connected credential can do, which is one reason it is increasingly showing up alongside n8n rather than instead of it in production stacks. And if your automation already touches customer or financial data and nobody on your team can currently say what each connected credential is allowed to do, that gap is worth closing before you wire in the next integration.
