Multi-Tenant Workflow Backup Isolation Bypass in n8n-MCP

Vulnerability Description

This vulnerability is a tenant isolation bypass affecting n8n-MCP's workflow version history feature in multi-tenant HTTP mode. The root cause is insufficient access control on locally stored workflow backups—version snapshots created automatically before workflow updates are stored in a shared, unscoped location accessible to all authenticated tenants. The vulnerability allows cross-tenant read, modify, and delete operations on backup data, creating a confidentiality breach (exposure of credential references and auth headers) and integrity/availability impact (malicious deletion or corruption of another tenant's audit trail).

Proof-of-Concept Significance

The advisory does not include executable PoC code, but describes the attack surface clearly: any authenticated tenant can enumerate and access the workflow version history endpoint without tenant-specific authorization checks. The precondition is straightforward—the attacker must have valid authentication credentials as any tenant in the shared deployment. The reliability is high because the vulnerability is a direct result of missing tenant context validation in the backup retrieval/deletion logic. This is a high-confidence, easily exploitable flaw in production multi-tenant environments where credentials and workflow logic represent significant business value.

Detection Guidance

Log indicators: Monitor for:

• Workflow version history API calls (e.g., GET /api/workflows/{id}/versions) with mismatched tenant IDs between the authenticated user and requested resource.
• Suspicious batch access patterns to version history endpoints across multiple workflows in short time windows.
• Deletion requests (DELETE) targeting version history not owned by the authenticated tenant.

Configuration review: Check audit logs for ENABLE_MULTI_TENANT=true deployments pre-2.56.1. Query backup storage directories for files lacking per-tenant isolation markers or ACLs. Search application logs for errors or warnings related to version history scope validation.

YARA/detection signatures: Search for log entries containing workflow_version, backup, or /versions/ endpoints paired with cross-tenant request patterns (e.g., tenant_id mismatch in JWT vs. resource path).

Mitigation Steps

Immediate actions (if upgrade not possible):

1. Disable the affected tool: set DISABLED_TOOLS=n8n_workflow_versions in environment variables and restart the n8n-MCP server.
2. Restrict network access to the n8n-MCP instance to trusted administrators only.
3. Implement reverse-proxy WAF rules blocking access to /api/workflows/*/versions* endpoints for multi-tenant deployments.

Primary fix: Upgrade to n8n-MCP 2.56.1 or later. This version includes tenant-scoped backup isolation and runs a one-time migration that removes previously un-scoped backups.

Post-patch validation: Verify that backup storage paths now include per-tenant identifiers, and that access control tests confirm one tenant cannot list/access other tenants' version history.

Risk Assessment

Likelihood of exploitation: High in production environments. The attack requires only valid tenant credentials (widely distributed in multi-tenant SaaS scenarios), making the barrier to entry low. Workflow configurations often embed sensitive credentials, making the attacker's reward significant.

Threat actor interest: High. Competitor reconnaissance, credential harvesting, and workflow disruption are valuable attack objectives. Ransomware operators may target backup deletion for extortion.

In-the-wild exploitation: No confirmed public exploits detected at advisory time, but the simplicity of the attack (authenticated API call to unscoped endpoint) makes opportunistic exploitation likely if the vulnerability becomes known. Organizations running multi-tenant HTTP deployments at versions ≤ 2.56.0 are at immediate risk.