CVE-2026-55608: n8n-MCP: Incorrect authorization can expose default-scope workflow version backups in multi-tenant HTTP mode

n8n-mcp keeps its own local workflow_versions backups. With ENABLE_MULTI_TENANT=true, each tenant should only see backups in its own scope. Under certain conditions, a tenant without a complete tenant context was served from the default (single-tenant) scope. The advisory does not say which conditions. This concerns n8n-mcp's local storage, not an n8n API feature.

A tenant with a valid login can read or delete those default-scope backups. The typical case is backups left behind from an earlier single-tenant deployment or a migration period. Snapshots can contain sensitive workflow configuration, depending on what the workflows hold.

The rating is medium (CVSS 4.2) because it needs a valid tenant account, has high attack complexity, and only reaches the default scope, not other tenants. It is a follow-up to the cross-tenant backup issue in CVE-2026-54052, which was fixed in 2.56.1; this one remained through 2.57.3.

npm package n8n-mcp 2.57.3 and earlier, in HTTP mode with ENABLE_MULTI_TENANT=true. It matters most if the same database once ran as a single-tenant deployment and still holds default-scope backups. Stdio and single-tenant HTTP deployments are not affected. Check:

npm ls n8n-mcp

For Docker, check the image tag and the container environment for ENABLE_MULTI_TENANT.

Upgrade to n8n-mcp 2.57.4 or later:

npm install [email protected]

The fix requires a full tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be tied to a tenant. Workarounds from the advisory:

• Restrict network access to the HTTP endpoint with a firewall, reverse proxy or VPN, so only trusted callers connect.
• Run in stdio mode, which has no multi-tenant HTTP surface.
• Delete default-scope backups from an earlier single-tenant deployment if you do not need them.

The advisory lists no indicators. Review HTTP access and tool-call logs for tenants calling the workflow versions tool, and for version listings or deletions that do not match what that tenant created. Check whether the database contains default-scope backups from earlier single-tenant use. Missing backups that an operator expected to find can mean they were deleted by another tenant. Treat any secrets in old snapshots as exposed, and rotate them.

Summary

In multi-tenant HTTP mode (ENABLE_MULTI_TENANT=true), an authenticated tenant could, under certain conditions, reach n8n-mcp's local default-scope workflow_versions backups instead of being confined to its own tenant scope. This affects n8n-mcp's own local workflow-version storage, not a normal n8n API capability.

Impact

An authenticated MCP HTTP tenant could read or delete workflow-version backups stored in the default (single-tenant) scope — for example backups left from a prior single-tenant deployment or a migration period. Workflow snapshots may contain sensitive workflow configuration depending on their contents. Single-tenant and stdio deployments are not affected.

Affected versions

<= 2.57.3

Patched version

2.57.4

Remediation

Upgrade to n8n-mcp 2.57.4 or later. The fix requires a complete tenant context in multi-tenant mode and fails closed for workflow-version access that cannot be attributed to a specific tenant.

Workarounds

• Restrict network access to the HTTP endpoint (firewall / reverse proxy / VPN) so only trusted callers can reach it.
• Run in stdio mode, which has no multi-tenant HTTP surface.
• If default-scope backups from a prior single-tenant deployment are not needed, removing them eliminates the exposure.

Credit

Reported by @DavidCarliez.