An IDOR in n8n-mcp let any authenticated tenant read every other tenant's credentials. The bug is literally guessing sequential numbers. CVE-2026-54052 (assigned by Manifold Security; pending NVD publication), CVSS 9.9 per the GitHub Advisory (GHSA-j6r7-6fhx-77wx) — and it is the fifth multi-tenant security issue in the same project in 2026. The pattern is clear: the routing layer was protected, the persistence layer never was.
The bug: sequential IDs with no ownership check
The workflow_versions table in SQLite had no tenant column. All backups from all tenants shared a table with sequential integer IDs. When a tenant called n8n_workflow_versions with an ID, the handler queried without ownership verification. Supply any integer, receive any other tenant's snapshot. Enumeration was trivial — just increment the ID.
What was exposed: workflow version snapshots include complete node definitions. This means API keys, Bearer tokens, authorization headers, webhook URLs, and credential references configured in nodes. The attacker could also delete, truncate — wipe ALL backups of ALL tenants globally — or import another tenant's snapshot into their own instance, effectively rolling back another tenant's workflow.
According to Francisco Rosales of Manifold Security, who discovered the vulnerability, access was direct with no barrier beyond authentication on the caller's own tenant. According to Manifold Security, the maintainer, Romuald Czlonkowski, acknowledged, confirmed, and published the patch in under a week.
The scope: multi-tenant HTTP, not local usage
n8n-mcp is an MCP (Model Context Protocol) server built by the community that gives AI assistants — Claude Desktop, Claude Code, Cursor, Windsurf — access to n8n node documentation. n8n, the workflow automation platform, has 193K GitHub stars. n8n-mcp, the community-built MCP server, has over 21K stars and 150K weekly npm downloads per npm and GitHub.
The impact scope is specific: it affects ONLY HTTP multi-tenant deployments with ENABLE_MULTI_TENANT=true. It does NOT affect local/stdio usage like Claude Desktop or single-tenant deployments. The most common use case — developers running n8n-mcp locally — is not affected.
But for operators running multi-tenant deployments, the exposure is total. Every credential configured in every node of every workflow of every tenant was accessible to any other authenticated tenant.
The pattern: five CVEs, same root cause
This is the fifth multi-tenant security issue in n8n-mcp in 2026. The previous ones:
- CVE-2026-39974 (CVSS 8.5): SSRF via instance-URL header
- CVE-2026-45707 (CVSS 8.1): credential fallback to operator instance
- CVE-2026-44694 (CVSS v3.1 9.1; v4.0: 7.2): SSRF in webhook/API paths
- Path traversal + SSRF + telemetry leak (CVSS 8.3, no CVE assigned)
The pattern is consistent and structural: the multi-tenant routing layer was protected, but the local persistence layer (SQLite) never received isolation. Each fix addressed the specific vector — SSRF in the header, SSRF in the path, credential fallback — without auditing the underlying data layer.
According to Manifold Security, the project's threat model already listed "cross-tenant bleed" as a known risk, claiming it was mitigated via header-derived credentials. The mitigation covered routing, not the local database. It is the equivalent of locking the front door and leaving the window open — repeatedly.
The patch and what it resolves
n8n-mcp v2.56.1 adds the instance_id column to the workflow_versions table and scopes every query to the calling tenant. A one-time migration runs on upgrade and cleans up previously unscoped backups.
The patch is correct and complete for this specific CVE. But it does not resolve the pattern. Until local persistence is systematically audited for tenant isolation, the next vector surfaces in the next unscoped table.
MCP is the new perimeter
The lesson for anyone building infrastructure for AI agents: MCP is the new perimeter. Every MCP server that gives an agent access to data or tools is an attack surface. And multi-tenant isolation must be end-to-end, not just at the routing layer.
n8n-mcp has 150K weekly npm downloads per npm. Each of those downloads is a potential entry point for an AI agent into corporate infrastructure. When the agent accesses data via MCP, the security of that channel is as critical as the security of the API the agent consumes.
At Tech86, we apply this principle in practice: our managed EDR monitors for anomalous access in local persistence layers — exactly the kind of pattern this IDOR represents. If a tenant starts enumerating sequential IDs in a SQLite table, our monitoring detects and alerts before enumeration becomes exfiltration. When isolation at the data layer fails, behavioral detection is the last line of defense.