TL;DR
Francisco Rosales of Manifold Security found a critical cross-tenant flaw (CVSS 9.6) in n8n-mcp, a community-built MCP server with 120,000+ weekly npm downloads and 21,500+ GitHub stars.
In shared multi-tenant deployments, any logged-in tenant could read another tenant's saved workflow backups, including the API keys and Bearer tokens stored inside them, just by guessing a number. The same flaw let a tenant delete another tenant's backups, or wipe every tenant's backup history on the server in a single call.
The flaw hits multi-tenant setups: hosting providers, platform teams, and anyone offering n8n-mcp as a shared service. Single-user setups (the Claude Desktop case) and one-tenant-per-server setups are not affected.
Fixed in v2.56.1. Upgrade now if you run multi-tenant mode, or apply one of the workarounds below.
Full technical detail is in GHSA-j6r7-6fhx-77wx. A CVE has been requested and is pending; we'll update this post once assigned.
What an attacker could actually do
Picture a hosting provider or an internal platform team running one n8n-mcp server for several customers or business units. Each tenant connects through the same server but points at their own separate n8n instance. That's the multi-tenant setup the project documents and supports.
Under that setup, a logged-in tenant could type a number and read another tenant's most recent workflow backup. That backup is a full snapshot of the workflow, and it carries the secrets configured on the workflow's nodes: API keys, authorization headers, webhook URLs. So a marketing automation tenant could pull the payroll automation tenant's credentials off the same server, without ever touching that tenant's n8n instance.
The same flaw allowed destruction. A tenant could delete a specific backup, delete all backups for a given workflow, or call a single operation that wiped every tenant's backup history across the entire server at once. No special access, no elevated role. Any authenticated tenant could do it.
This is the kind of boundary failure that matters most in exactly the deployments built to keep customers apart from one another.
How widespread is the exposure?
n8n-mcp pulls 120,000+ weekly downloads on npm and carries 21,500+ GitHub stars, putting it among the most widely used MCP servers in the ecosystem. Multi-tenant mode is a documented, first-class feature: the project ships a dedicated multi-tenant hosted-deployment guide and exports a multi-tenant engine class for builders who want to put n8n-mcp in front of many users through a single backend. Hosting providers, platform teams, and SaaS builders offering n8n-mcp as a shared service are exactly the operators who turn it on, and exactly the ones this flaw targets.
For scale on the underlying platform, a Shodan search for n8n's login page returns over 170,000 publicly reachable n8n instances as of June 2026. That's n8n itself, not n8n-mcp, but it's the platform these connectors plug into. n8n-mcp is the connector increasingly sitting in front of those deployments to give AI agents control over them. Single-user installs running locally inside an AI client like Claude Desktop are not exposed. The risk concentrates in the shared, multi-tenant deployments where the blast radius is largest, one server holding many tenants' credentials in one unguarded table.
The bug: one shared table, no tenant column
n8n-mcp keeps a local version history of workflows. Before each workflow update, it takes an automatic snapshot and saves it to a workflow_versions table in a local SQLite database. These snapshots live only inside n8n-mcp. They are not part of the n8n API.
The workflow_versions table has no tenant column. Every tenant's backups sit in the same table, and the row identifier is a simple sequential integer. When a tenant calls the n8n_workflow_versions tool with an ID, the handler runs the query with no check that the calling tenant owns that row. Supply any integer, get any tenant's snapshot. Because the IDs increment predictably, enumeration is trivial.
The exposed operations:
Mode | What an attacker can do |
| Read a full workflow snapshot: nodes, credential references, webhook URLs, Bearer tokens |
| Enumerate the version history of any workflow |
| Destroy a specific backup |
| Destroy every backup for a workflow |
| Wipe all tenants' backups globally in one call |
| Import another tenant's snapshot into your own n8n instance |
A control that existed on paper
One detail stands out. The project's threat model already lists "cross-tenant bleed in multi-tenant HTTP deployments" as a known threat, and claims it's handled through header-derived credentials. That mitigation is real, but it covers only the routing layer: which n8n instance each tenant's requests go to. It never reached the local SQLite layer where the backups live.
The threat was identified with a fix applied in one place but not the other. That gap is the vulnerability.
Retrofitting multi-tenancy onto a tool that began as single-user is genuinely hard, and n8n-mcp has had to close earlier multi-tenant gaps before, including aserver-side request forgery flaw and acredential-fallback issue. That isn't a knock on the project so much as a reminder: every place that assumed one user now has to assume many, and the local storage layer is an easy one to miss.
Proof of concept
Francisco set up two tenants pointing at completely separate n8n instances (separate containers, separate hostnames) on one n8n-mcp server. Tenant A updated a workflow through the normal tool path, which created a backup through n8n-mcp's own code. Tenant B, connected to a different n8n instance, then read that backup by guessing the integer ID:
Tenant B → n8n_workflow_versions(mode=get, versionId=3095)
← "Tenant-A-Confidential-Payroll" with Bearer TENANT-A-SECRET-TOKEN ✗ BUG
Tenant B went on to list Tenant A's version history and delete the backup. The deletion was confirmed by Tenant A trying to read the same ID and getting nothing back. A negative control confirmed the endpoint returns "not found" for IDs that don't exist, ruling out a broken catch-all.
The full reproduction environment is described in the GHSA advisory.
Fix and workarounds
Fixed in v2.56.1. The patch adds an instance_id column to workflow_versions and scopes every query to the calling tenant. A one-time migration runs on upgrade and clears the previously un-scoped backups, which are short-retention auto-snapshots rather than primary data.
If you can't upgrade right away:
Set
DISABLED_TOOLS=n8n_workflow_versionsin your server environment (for example, in your Docker.env). This removes the affected tool for all tenants. Automatic backups still happen, but the cross-tenant access path is closed.Or stop running multi-tenant mode: serve each tenant from a separate instance with its own database, so no local store is shared.
Restrict network access to the HTTP endpoint to trusted operators.
stdio and single-tenant HTTP deployments are not affected.
We want to credit the maintainer, Romuald Członkowski (@czlonkowski), for a clean disclosure process. After we filed the private advisory, he acknowledged the report, confirmed it against our PoC, shipped the fix, and requested a CVE all within a week. That kind of turnaround is worth naming.
How Manifold can help
This finding lands on a theme we keep running into: an access control that's correct in one layer and absent in another. The tool list looks right, the routing looks right, and the gap is in a local store nobody re-checked. From the outside, nothing looks wrong until a tenant types the wrong number.
That's the layer Manifold watches. We monitor what AI agents and the MCP servers behind them actually do at runtime: the tools they invoke and the calls they make. A network gateway sees authenticated HTTPS and nothing unusual. Runtime behavioral visibility is where this class of problem, an authorized client doing something it shouldn't be able to, becomes observable, rather than a gap that only surfaces when someone reports it.
For teams that want to start at the supply chain layer, n8n-mcp is indexed in Manifest, Manifold's free open-access tool for vetting MCP servers and AI agent skills. This advisory is flagged there against versions prior to 2.56.1.
Check what your agents and MCP servers are actually doing at runtime, not just what they're authorized to do. Talk to Manifold today.
Latest articles
