n8n-MCP Cross-Tenant Backup Flaws Expose Workflow Secrets — CVE-2026-54052 and CVE-2026-55608
Two newly published advisories describe authorization failures in n8n-mcp's local workflow-version store. In shared HTTP deployments with multi-tenancy enabled, an authenticated tenant could reach backup snapshots outside its own scope. The more severe path, CVE-2026-54052, allowed access to other tenants' snapshots; CVE-2026-55608 covered default-scope backups reachable through an incomplete tenant context.
The current remediation floor is n8n-mcp 2.57.4. Version 2.56.1 isolated ordinary tenant history for the first advisory, but the second boundary condition remained through 2.57.3. Operators should therefore not stop at 2.56.1. The affected component is the MCP server's own automatic workflow-version storage, not n8n's normal workflow API.
The critical flaw crossed tenant boundaries
When ENABLE_MULTI_TENANT=true, versions through 2.56.0 stored workflow history without sufficient per-tenant isolation. An authenticated tenant could read snapshots belonging to another tenant and could delete or destroy those backups. GitHub rates CVE-2026-54052 Critical, CVSS 3.1 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L) and maps it to missing authorization and authorization bypass through a user-controlled key.
A snapshot contains full node definitions. According to the advisory, that can include credential references and authorization headers configured on nodes. Exposure therefore reaches beyond workflow names and topology: a backup may preserve operational details that defenders would treat as secrets or pivots, while deletion removes a recovery and audit artifact.
The scope is important. Stdio and other single-user deployments, including the common Claude Desktop pattern, are not affected by this cross-tenant issue. Neither are single-tenant HTTP deployments with one tenant per instance and database. The vulnerable configuration is a shared n8n-mcp HTTP service and database serving multiple tenants.
A second advisory closes the default-scope edge case
CVE-2026-55608 affects versions through 2.57.3. Under certain conditions, a multi-tenant HTTP caller could land in the local default scope instead of a tenant-specific scope, exposing backups left by an earlier single-tenant deployment or migration. The authenticated caller could read or delete those snapshots. GitHub scores this path Medium, CVSS 4.2 because it requires a higher-complexity condition and has lower stated impact.
The 2.57.4 patch makes the request boundary fail closed in two places. Multi-tenant requests must provide both the tenant URL and key headers; supplying only one is rejected. The workflow-version handler also refuses access when the resolved tenant scope is empty. The accompanying tests verify that list, get, and delete operations fail for a partial context and that a default-scope backup remains intact after a refused deletion attempt.
The disclosure dates and release dates differ. GitHub published both advisories on July 14, while the project released 2.56.1 on June 2 and 2.57.4 on June 13. That means patched builds were available before public advisory publication, but it also makes version-only scanning essential: teams may have upgraded during that interval without recognizing the security significance.
Why local agent state needs first-class isolation
The failure sits in an auxiliary convenience layer rather than the primary n8n authorization system. That distinction is exactly why it matters. Agent gateways routinely add caches, traces, replay buffers, tool results, generated artifacts, and automatic backups around a better-defended upstream service. Every one of those stores can recreate sensitive tenant data and needs the same subject, tenant, retention, and deletion controls as the source.
This is also a different class of MCP risk from unauthenticated internet exposure. Authentication worked well enough to identify a caller, but authorization did not consistently bind that identity to a storage namespace. As discussed in the site's MCP authorization guidance, having a valid token is not the same as proving that a tool call may act on a particular object.
Defensive engineering guidance
- Upgrade to n8n-mcp 2.57.4 or later. Rebuild containers and verify the running image or package version; upgrading only to 2.56.1 does not address the later default-scope advisory.
- Inventory the affected deployment mode. Prioritize instances with
ENABLE_MULTI_TENANT=true, shared databases, and network-reachable HTTP transport. Stdio and isolated single-tenant deployments are outside the stated scope. - Review possible exposure. Examine MCP access logs for workflow-version list, get, and delete operations across tenant contexts. Treat node authorization headers and credential references in exposed snapshots as potentially compromised and rotate usable secrets based on evidence and risk.
- Inspect backup integrity. Confirm expected snapshots still exist for each tenant and reconcile unexplained deletions. Preserve relevant logs before normal retention removes them.
- Remove stale default-scope state. After validating retention requirements, delete obsolete backups left by single-tenant-to-multi-tenant migrations. Do not leave unowned records as an implicit shared namespace.
- Disable the tool if patching is delayed. For the first advisory, the vendor recommends
DISABLED_TOOLS=n8n_workflow_versions; isolating each tenant in its own instance and database also removes the shared-store condition. Restrict HTTP access to trusted operators in either case. - Test every operation at the tenant boundary. Add negative tests for complete, absent, and partial tenant contexts across create, list, read, restore, and delete. A missing scope should always deny access rather than select a default.
The practical lesson is broader than one backup table: generated state inherits the sensitivity of the system it mirrors. An MCP gateway that isolates live API calls but commingles local history has not achieved tenant isolation. Identity must travel with every stored object, and ambiguous context must fail closed before a tool handler touches it.
Sources: