CVE-2026-77073: n8n MCP auth bypass grants

CISO Take

n8n's MCP integration lets an authenticated MCP client bypass credential-ownership validation in the create_workflow_from_code tool when the authentication type is set to an expression, allowing a workflow to reference a credential ID belonging to a project the caller does not own. Any CISO running n8n as an AI-agent orchestration backbone should treat this as a lateral-movement primitive rather than a cosmetic bug: with just a valid MCP Bearer API key and a guessed or leaked credential ID, an attacker — or an over-permissioned internal user — can pivot from their own project into another team's stored secrets and persist that access inside a workflow definition. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this is not an emergency-patch scenario, but n8n carries 201 other CVEs and a mediocre 6.6/10 OpenSSF Scorecard, pointing to broader hardening debt across the project. Upgrade to n8n 2.34.1 or later, restrict and rotate MCP Bearer API keys, and audit existing workflows for cross-project credential references — particularly any created via create_workflow_from_code with expression-based authentication.

Sources:NVDGitHub AdvisoryATLASOpenSSFvulncheck.com

What is the risk?

Medium risk overall: the vulnerability provides a real broken-access-control primitive (CWE-639, insecure direct object reference on credential IDs) but has meaningful preconditions — a valid MCP Bearer API key and prior knowledge of a target credential ID — that limit exploitation to insiders, compromised API-key holders, or attackers who have already gained partial foothold. No CVSS vector, EPSS score, KEV listing, or public exploit/scanner exists, so opportunistic mass exploitation is unlikely today. The risk is elevated by n8n's role as an AI agent/workflow orchestration platform (16 known downstream dependents) where credentials often gate access to LLM APIs, databases, and third-party SaaS — meaning a successful bypass can cascade into much higher-impact secondary compromises even though the initial CVE severity is medium.

How does the attack unfold?

Initial Access

Attacker obtains a valid MCP Bearer API key for the n8n instance, either through leakage, insider access, or a compromised integration.

AML.T0012

Target Discovery

Attacker identifies or guesses the credential ID of a high-value credential belonging to a different, unauthorized project.

AML.T0084

Exploitation

Attacker calls the create_workflow_from_code MCP tool with authentication type set to an expression, bypassing credential-ownership validation and persisting the cross-project credential reference.

AML.T0053

Impact

Attacker executes the malicious workflow, causing n8n to use the unauthorized credential and abuse the victim project's downstream service or data access.

AML.T0083

Initial Access

Attacker obtains a valid MCP Bearer API key for the n8n instance, either through leakage, insider access, or a compromised integration.

AML.T0012

Target Discovery

Attacker identifies or guesses the credential ID of a high-value credential belonging to a different, unauthorized project.

AML.T0084

Exploitation

Attacker calls the create_workflow_from_code MCP tool with authentication type set to an expression, bypassing credential-ownership validation and persisting the cross-project credential reference.

AML.T0053

Impact

Attacker executes the malicious workflow, causing n8n to use the unauthorized credential and abuse the victim project's downstream service or data access.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
209.2KOpenSSF 7.116 dependentsPushed today44% patched~19d to patchFull package profile →

Do you use n8n? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 28% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

1) Upgrade n8n to version 2.34.1 or later, which fixes the credential validation bypass in create_workflow_from_code. 2) Until patched, restrict which principals hold MCP Bearer API keys and avoid granting broad/shared keys across projects. 3) Audit existing workflows for credential references (authenticationType set to 'expression') that point to credential IDs outside the workflow's own project — treat any cross-project reference as a potential IOC. 4) Rotate credential IDs/secrets for any project where cross-project reference is found. 5) Monitor MCP API access logs for create_workflow_from_code calls using expression-based authentication as a detection signal. 6) Apply least-privilege project/credential scoping in n8n going forward so that even a successful bypass has minimal blast radius.

What does CISA's SSVC say?

DecisionTrack*

Exploitationnone

AutomatableYes

Technical Impacttotal

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

How is it classified?

Auth BypassPrivacy ViolationAgentPluginAML.T0012- Valid Accounts AML.T0053- AI Agent Tool Invocation AML.T0083- Credentials from AI Agent Configuration AML.T0091.000- Application Access Token

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

NIST AI RMF

MANAGE 4.1-Post-deployment monitoring for AI risks

OWASP LLM Top 10

LLM08-Excessive Agency

Frequently Asked Questions

What is CVE-2026-77073?

n8n's MCP integration lets an authenticated MCP client bypass credential-ownership validation in the create_workflow_from_code tool when the authentication type is set to an expression, allowing a workflow to reference a credential ID belonging to a project the caller does not own. Any CISO running n8n as an AI-agent orchestration backbone should treat this as a lateral-movement primitive rather than a cosmetic bug: with just a valid MCP Bearer API key and a guessed or leaked credential ID, an attacker — or an over-permissioned internal user — can pivot from their own project into another team's stored secrets and persist that access inside a workflow definition. There is no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template yet, so this is not an emergency-patch scenario, but n8n carries 201 other CVEs and a mediocre 6.6/10 OpenSSF Scorecard, pointing to broader hardening debt across the project. Upgrade to n8n 2.34.1 or later, restrict and rotate MCP Bearer API keys, and audit existing workflows for cross-project credential references — particularly any created via create_workflow_from_code with expression-based authentication.

Is CVE-2026-77073 actively exploited?

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

How to fix CVE-2026-77073?

1) Upgrade n8n to version 2.34.1 or later, which fixes the credential validation bypass in create_workflow_from_code. 2) Until patched, restrict which principals hold MCP Bearer API keys and avoid granting broad/shared keys across projects. 3) Audit existing workflows for credential references (authenticationType set to 'expression') that point to credential IDs outside the workflow's own project — treat any cross-project reference as a potential IOC. 4) Rotate credential IDs/secrets for any project where cross-project reference is found. 5) Monitor MCP API access logs for create_workflow_from_code calls using expression-based authentication as a detection signal. 6) Apply least-privilege project/credential scoping in n8n going forward so that even a successful bypass has minimal blast radius.

What systems are affected by CVE-2026-77073?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration / automation pipelines, multi-tenant AI platforms.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration / automation pipelinesmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0053AI Agent Tool Invocation

AML.T0083Credentials from AI Agent Configuration

AML.T0091.000Application Access Token

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n versions before 2.34.1 contain a credential validation bypass in the MCP create_workflow_from_code tool when authentication type is set to an expression. Attackers with a valid MCP Bearer API key and knowledge of a target credential ID can persist unauthorized cross-project credential references on workflows in different projects.

Exploitation Scenario

An attacker (a disgruntled contractor, a compromised CI system, or an external party who obtained a leaked MCP Bearer API key) has legitimate but scoped access to Project A in a shared n8n instance. Through reconnaissance — social engineering, log exposure, or predictable credential naming — they learn the credential ID used by Project B, which holds a high-value API key (e.g., an LLM provider key or a payment gateway secret). Using their valid MCP API key, the attacker invokes the create_workflow_from_code tool, setting the authentication type to an expression and supplying Project B's credential ID. Because the tool fails to validate that the credential belongs to the caller's project, the malicious workflow is persisted in Project A with an active reference to Project B's credential. The attacker then executes the workflow, causing n8n to use Project B's credential on the attacker's behalf — exfiltrating data or abusing the third-party service without ever directly accessing Project B.

Weaknesses (CWE)

CWE-639Authorization Bypass Through User-Controlled KeyPrimary CWE-639Authorization Bypass Through User-Controlled Key

CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.

[Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
[Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.

Source: MITRE CWE corpus.