CVE-2026-55608: n8n cross-tenant leak of workflow

Q: Is CVE-2026-55608 actively exploited?

No confirmed active exploitation of CVE-2026-55608 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-55608?

Upgrade to n8n-mcp 2.57.4 or later, which requires a complete, verifiable tenant context for any workflow-version access and fails closed rather than defaulting to the shared scope. If immediate upgrade isn't possible: restrict network reachability to the MCP HTTP endpoint via firewall, reverse proxy, or VPN so only trusted callers can reach it; or switch affected deployments to stdio mode, which has no multi-tenant HTTP surface and is unaffected. Audit and, if unneeded, delete any default-scope workflow_versions backups left over from a prior single-tenant deployment or migration to eliminate the exposure window. For detection, review access logs on the multi-tenant HTTP endpoint for workflow-version read/delete calls whose tenant identifier doesn't match the requesting session's own tenant.

Q: What systems are affected by CVE-2026-55608?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers / tool gateways, multi-tenant SaaS orchestration.

Q: What is the CVSS score for CVE-2026-55608?

CVE-2026-55608 has a CVSS v3.1 base score of 4.2 (MEDIUM). The EPSS exploitation probability is 0.28%.

CISO Take

n8n-mcp's multi-tenant HTTP mode has an incorrect-authorization flaw (CWE-863) where an authenticated tenant can read or delete another tenant's default-scope workflow_versions backups instead of being confined to its own tenant — essentially a broken tenant-isolation bug in the MCP server that exposes AI-agent workflow configuration. The blast radius is bounded: only n8n-mcp deployments running ENABLE_MULTI_TENANT=true over HTTP are affected (stdio and single-tenant setups are safe), the CVSS score is a modest 4.2 (AC:H, PR:L, no availability impact), there's no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template — this is not an actively exploited or trivially weaponized bug. Still, with 16 downstream dependents and an OpenSSF Scorecard of only 6.6/10 for a package family carrying 136 other CVEs, organizations running n8n-mcp as a shared multi-tenant MCP gateway for AI agents should treat leaked workflow snapshots as a potential credential/config disclosure risk, not just noise. Upgrade to 2.57.4, which enforces a complete tenant context and fails closed when tenant attribution is ambiguous; until patched, firewall the HTTP endpoint to trusted callers or run in stdio mode, and purge any leftover default-scope backups from prior single-tenant deployments.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Medium overall risk (CVSS 4.2). Exploitability is constrained by high attack complexity (AC:H) and a requirement for low-privilege but valid tenant authentication (PR:L) — an adversary must already be an onboarded tenant in a multi-tenant HTTP deployment and hit a specific edge case in tenant-context resolution. Impact is limited to confidentiality and integrity of workflow-version backups (C:L/I:L) with no availability impact, and only affects the subset of deployments running ENABLE_MULTI_TENANT=true over HTTP rather than stdio or single-tenant installs. No EPSS score, no KEV listing, no public PoC or scanner template exist, so real-world exploitation likelihood is currently low — but the package's poor OpenSSF Scorecard (6.6/10) and long CVE history (136 other CVEs) suggest broader hygiene concerns worth monitoring.

How does the attack unfold?

Initial Access

Adversary authenticates as a legitimate low-privilege tenant to an n8n-mcp multi-tenant HTTP deployment.

AML.T0012

Exploitation

Attacker issues workflow-version API calls that fail to be fully attributed to their own tenant, falling through to the default single-tenant scope.

Collection

Attacker reads workflow-version backups outside their tenant scope, potentially exposing sensitive workflow configuration or credential references.

AML.T0037

Impact

Attacker optionally deletes another tenant's or a legacy deployment's workflow-version backups, destroying recovery data.

AML.T0101

Initial Access

Adversary authenticates as a legitimate low-privilege tenant to an n8n-mcp multi-tenant HTTP deployment.

AML.T0012

Exploitation

Attacker issues workflow-version API calls that fail to be fully attributed to their own tenant, falling through to the default single-tenant scope.

Collection

Attacker reads workflow-version backups outside their tenant scope, potentially exposing sensitive workflow configuration or credential references.

AML.T0037

Impact

Attacker optionally deletes another tenant's or a legacy deployment's workflow-version backups, destroying recovery data.

AML.T0101

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	<= 2.57.3	`2.57.4`
206.1K OpenSSF 6.7 Pushed 5d ago 53% patched ~5d to patch Full package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

4.2 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 19% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR Low

UI None

S Unchanged

C Low

I Low

A None

What should I do?

1 step

Upgrade to n8n-mcp 2.57.4 or later, which requires a complete, verifiable tenant context for any workflow-version access and fails closed rather than defaulting to the shared scope. If immediate upgrade isn't possible: restrict network reachability to the MCP HTTP endpoint via firewall, reverse proxy, or VPN so only trusted callers can reach it; or switch affected deployments to stdio mode, which has no multi-tenant HTTP surface and is unaffected. Audit and, if unneeded, delete any default-scope workflow_versions backups left over from a prior single-tenant deployment or migration to eliminate the exposure window. For detection, review access logs on the multi-tenant HTTP endpoint for workflow-version read/delete calls whose tenant identifier doesn't match the requesting session's own tenant.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Leakage Agent Plugin AML.T0037 - Data from Local System AML.T0084 - Discover AI Agent Configuration AML.T0101 - Data Destruction via AI Agent Tool Invocation

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

Annex A.8 - Data for AI systems

NIST AI RMF

MANAGE-4.1 - Risk treatment for third-party/AI-enabled component vulnerabilities

OWASP LLM Top 10

LLM02 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-55608?

n8n-mcp's multi-tenant HTTP mode has an incorrect-authorization flaw (CWE-863) where an authenticated tenant can read or delete another tenant's default-scope workflow_versions backups instead of being confined to its own tenant — essentially a broken tenant-isolation bug in the MCP server that exposes AI-agent workflow configuration. The blast radius is bounded: only n8n-mcp deployments running ENABLE_MULTI_TENANT=true over HTTP are affected (stdio and single-tenant setups are safe), the CVSS score is a modest 4.2 (AC:H, PR:L, no availability impact), there's no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template — this is not an actively exploited or trivially weaponized bug. Still, with 16 downstream dependents and an OpenSSF Scorecard of only 6.6/10 for a package family carrying 136 other CVEs, organizations running n8n-mcp as a shared multi-tenant MCP gateway for AI agents should treat leaked workflow snapshots as a potential credential/config disclosure risk, not just noise. Upgrade to 2.57.4, which enforces a complete tenant context and fails closed when tenant attribution is ambiguous; until patched, firewall the HTTP endpoint to trusted callers or run in stdio mode, and purge any leftover default-scope backups from prior single-tenant deployments.

Is CVE-2026-55608 actively exploited?

No confirmed active exploitation of CVE-2026-55608 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-55608?

Upgrade to n8n-mcp 2.57.4 or later, which requires a complete, verifiable tenant context for any workflow-version access and fails closed rather than defaulting to the shared scope. If immediate upgrade isn't possible: restrict network reachability to the MCP HTTP endpoint via firewall, reverse proxy, or VPN so only trusted callers can reach it; or switch affected deployments to stdio mode, which has no multi-tenant HTTP surface and is unaffected. Audit and, if unneeded, delete any default-scope workflow_versions backups left over from a prior single-tenant deployment or migration to eliminate the exposure window. For detection, review access logs on the multi-tenant HTTP endpoint for workflow-version read/delete calls whose tenant identifier doesn't match the requesting session's own tenant.

What systems are affected by CVE-2026-55608?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP servers / tool gateways, multi-tenant SaaS orchestration.

What is the CVSS score for CVE-2026-55608?

CVE-2026-55608 has a CVSS v3.1 base score of 4.2 (MEDIUM). The EPSS exploitation probability is 0.28%.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP servers / tool gatewaysmulti-tenant SaaS orchestration

MITRE ATLAS Techniques

AML.T0037 Data from Local System

AML.T0084 Discover AI Agent Configuration

AML.T0101 Data Destruction via AI Agent Tool Invocation

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.8

NIST AI RMF: MANAGE-4.1

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

n8n-MCP is an MCP server that provides AI assistants access to n8n node documentation, properties, and operations. Prior to 2.57.4, multi-tenant HTTP mode with ENABLE_MULTI_TENANT=true could allow an authenticated tenant to access default-scope workflow_versions backups instead of being confined to the tenant scope, exposing or deleting workflow-version backups from prior single-tenant deployments or migrations. This issue is fixed in version 2.57.4.

Exploitation Scenario

An organization runs n8n-mcp in multi-tenant HTTP mode to let multiple customer AI agents orchestrate n8n workflows through a shared MCP server, and the deployment was previously single-tenant before being migrated. A malicious or compromised tenant account authenticates normally to the MCP HTTP endpoint, then issues workflow-version API calls that fail to fully resolve to its own tenant scope, landing instead in the default (legacy single-tenant) scope. The attacker reads workflow-version backups left behind from the pre-migration period, extracting configuration details, API references, or credential material embedded in those workflows, and/or deletes those backups to destroy another tenant's recovery snapshots — all without needing to compromise the underlying n8n instance itself.

Weaknesses (CWE)

CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Primary CWE-200 Exposure of Sensitive Information to an Unauthorized Actor Primary CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization Primary CWE-200 Exposure of Sensitive Information to an Unauthorized Actor CWE-863 Incorrect Authorization

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.