n8n-MCP Multi-Tenant Workflow Backup Isolation Failure

Technical Analysis

The vulnerability arises from n8n-MCP's local backup storage mechanism for workflow version history not applying tenant-scoping when ENABLE_MULTI_TENANT=true is set in HTTP mode. Any authenticated tenant on a shared MCP server instance could access the backup store as a shared resource, reading other tenants' workflow snapshots which embed sensitive data including credential references and raw authorization headers used by n8n integrations. Beyond read access, the same lack of isolation permitted deletion or destruction of other tenants' backups, enabling denial-of-service and loss of recovery capability. The entry point is any valid tenant session on the MCP server; the attacker crosses tenant trust boundaries entirely within the server's own storage layer, requiring no additional exploitation of the AI agent or model itself. The impact is amplified because MCP servers are increasingly used as trusted tool intermediaries for AI agents, meaning leaked credentials could be reused to impersonate or hijack other tenants' automation workflows and connected systems.

Affected Systems

n8n-MCP; protocols: MCP

Detection Signatures

• Log entries showing cross-tenant access to /backup or version-history endpoints with mismatched tenant_id in request context
• Unexpected read/delete operations on workflow backup files not owned by the requesting tenant session
• ENABLE_MULTI_TENANT=true configurations running versions prior to 2.56.1
• Audit logs showing authorization header or credential reference values appearing in responses to unrelated tenant sessions

Remediation Steps

1. 1

   Upgrade n8n-MCP

   Update to n8n-MCP version 2.56.1 or later, which fixes the tenant isolation flaw in workflow backup storage.

2. 2

   Audit tenant boundaries

   Review historical logs for cross-tenant access to backup/version-history data and rotate any credentials or authorization headers potentially exposed.

3. 3

   Rotate exposed secrets

   Assume any credential references or auth headers stored in backups were compromised; rotate all associated API keys, tokens, and credentials.

4. 4

   Enforce storage-level tenant scoping

   Ensure backup and version history storage paths/queries are strictly scoped by tenant ID at the data access layer, not just at the API layer.

5. 5

   Restrict multi-tenant deployments

   Until patched, avoid enabling ENABLE_MULTI_TENANT in shared HTTP-mode deployments, or isolate tenants via separate server instances.