CVE-2026-54052: n8n-MCP's Critical Cross-Tenant Backup Flaw, Explained

If you’ve wired an AI agent up to manage n8n workflows through n8n-MCP, and you’re running it in a shared, multi-tenant deployment, check your version number today. CVE-2026-54052 is a critical authorization bypass, published July 14, 2026, that lets one tenant read, delete, or destroy another tenant’s stored workflow backups.

The short version: upgrade to n8n-mcp 2.56.1. If you can’t do that right now, disable the affected tool with an environment variable until you can.

What the bug actually does

n8n-MCP is a Model Context Protocol server that gives AI agents structured access to manage n8n automation workflows: creating them, editing them, and rolling them back through version history. That last part is where the bug lives.

The advisory, tracked as GHSA-j6r7-6fhx-77wx with a CVSS score of 9.9, describes it plainly: “a tenant could read workflow version snapshots belonging to other tenants, and could delete or destroy other tenants’ stored backups.” In a multi-tenant HTTP deployment, the version history storage wasn’t properly scoped per tenant. A user authenticated as Tenant A could reach Tenant B’s backup snapshots through the same API surface, with no additional authorization check verifying tenant ownership.

The weakness classifications tell you exactly where this sits in the taxonomy of access control bugs: CWE-639 (authorization bypass through user-controlled key) and CWE-862 (missing authorization). This is the same shape of bug that shows up whenever an application trusts an ID passed in a request without verifying the requesting user actually owns the resource that ID points to. It’s one of the most common vulnerability patterns in multi-tenant SaaS generally, and MCP servers, being new and rapidly built, are proving to be no exception.

Who’s exposed

This is narrower than it might first sound. Two conditions both have to be true:

1. You’re running n8n-MCP in HTTP mode, not stdio.
2. You have ENABLE_MULTI_TENANT=true set.

If you’re running n8n-MCP as a local stdio server for a single user (the default and most common setup for individual developers pairing it with Claude Desktop, Cursor, or a similar client), you were never exposed. If you’re running it in HTTP mode but serving a single tenant, you’re also not affected, since there’s no other tenant’s data to cross into.

The exposure is specifically for teams or platforms that stood up a shared n8n-MCP deployment serving multiple customers or business units through one HTTP endpoint. That’s a smaller population than “everyone who uses n8n-MCP,” but it’s exactly the deployment shape that agencies and platform teams building on top of MCP servers are increasingly reaching for, because running one shared instance is cheaper than provisioning a server per tenant.

Why this matters beyond this one package

n8n-MCP joins a growing list of MCP servers that have shipped multi-tenant HTTP modes faster than they’ve hardened the authorization boundaries between tenants. The pattern is predictable: a project starts as a single-user, stdio-based tool, someone adds an HTTP mode so it can be centrally hosted, someone adds multi-tenancy on top of that so one deployment can serve many customers, and the tenant isolation gets bolted on rather than designed in from the start.

If you’re running any multi-tenant MCP server, not just this one, it’s worth specifically auditing: does every data-access code path verify the requesting tenant against the resource’s owning tenant, or does it trust an ID from the request? That question is the entire CVE-2026-54052 story in one sentence, and it generalizes to the next MCP server that adds multi-tenancy this year.

What to do right now

Patch: Upgrade to n8n-mcp 2.56.1 or later. The patched version isolates version history storage per tenant instance and runs a one-time migration on startup to correct any state where backups may have already been visible cross-tenant.

Can’t patch immediately: Set DISABLED_TOOLS=n8n_workflow_versions in your deployment configuration. This disables the specific tool that exposes the vulnerable code path, without requiring a version bump. It’s a reasonable stopgap for a day or two, not a long-term fix.

Either way: If you’re running multi-tenant HTTP mode, review your access logs for the affected period for any workflow-version-related requests where the tenant making the request doesn’t match the tenant owning the resource. The advisory doesn’t indicate active exploitation as of publication, but that’s not the same as confirming none occurred.

For teams building agent-facing infrastructure more broadly, this is also a good moment to revisit how you’re thinking about MCP security posture generally. Multi-tenant AI tooling is being shipped faster than the isolation guarantees are being audited, and this won’t be the last advisory that follows this exact shape. If you’re scoping a production MCP deployment and want a second set of eyes on the tenant isolation model before you go live, that’s exactly the kind of architecture review our team does before a launch, not after an incident.