MCP Tool Sequential Integer ID Enumeration (Cross-Tenant IDOR, CVE-2026-54052)
Some AI-agent tools identify saved data — like workflow versions or backups — using plain sequential numbers (1, 2, 3...) instead of checking who owns each record. An attacker with access to the same shared system can simply count upward through these numbers and pull back other customers' private data, including embedded API keys and tokens.
How the attack works
The attacker connects to a multi-tenant deployment of the vulnerable tool and calls a version/backup/snapshot lookup function that takes a bare integer ID. Instead of asking for their own records, they submit sequential IDs one after another — either by hand, in a script, or by having an agent iterate a counter variable. Because the underlying database table has no tenant ownership check, each ID returns whatever tenant's data happens to sit at that row, including full configuration snapshots, credentials, and tokens. The same technique can also be used to delete other tenants' backups by ID. The specific case behind this rule is CVE-2026-54052 in n8n-mcp before v2.56.1, where the workflow_versions table and its lookup tool had no tenant scoping at all.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- ff9b31e3-ec6e-4b64-945a-5b642dae06b6
- Severity
- Critical
- CVEs
- CVE-2026-54052
Why it matters
An attacker can read or destroy another customer's stored workflow data on a shared multi-tenant deployment, including any embedded API keys and bearer tokens, without needing valid credentials for that tenant.
What you can do
- →Upgrade n8n-mcp to v2.56.1 or later if running ENABLE_MULTI_TENANT=true.
- →Add tenant-ownership checks to any tool that accepts a bare integer ID for versions, backups, or snapshots — never trust the ID alone to authorize access.
- →Replace sequential auto-increment identifiers with per-tenant scoped or random (UUID-style) IDs for any externally addressable resource.
- →Rate-limit and log repeated calls to version/backup lookup tools that vary only the numeric ID, and review any burst of such calls for whether the IDs came from a legitimate prior listing or were guessed.
Known benign look-alikes
- Migration, backup-verification or disaster-recovery tooling that legitimately walks every version row of a single-tenant deployment — the payload shape is identical to the attack and only the authorisation context differs.
- Integration or load tests that seed and then read back N sequential version records against a test instance.
- An agent that legitimately fetches each version returned by a prior authorised list call still emits one invocation envelope per ID, so layers 2 and 3 fire: they count ID-bearing calls and cannot tell a server-supplied ID set from a guessed one. (A returned collection on its own no longer matches — layer 3 requires a per-ID invocation envelope — but an authorised fan-out of real calls is indistinguishable from a sweep.)
- Security research and advisory prose that quotes an attacker's instruction verbatim can still match layer 7. Purely descriptive write-ups no longer match: layer 7 additionally requires a collection or exfiltration imperative, which describing text ('an attacker could read the api key') does not carry.
- Single-tenant deployments pinned below v2.56.1 that set ENABLE_MULTI_TENANT=true for local development against one instance will match layer 6 even though no second tenant exists.