CVE-2026-72763: n8n Editor role bypasses credential

CISO Take

n8n fails to validate credential-access permissions for credentials referenced inside an Execute Sub-workflow node's inline JSON, checking only a node's top-level credentials — a classic CWE-639 authorization-bypass-through-user-controlled-key flaw. Any user with Editor access to a shared workflow who simply knows (or guesses/enumerates) a target credential's ID can embed a reference to it in inline sub-workflow JSON, and it resolves normally at save and runtime inside the parent workflow's project context, effectively letting them use or exfiltrate credentials they were never granted. Blast radius depends entirely on whether workflow sharing is enabled and how broadly Editor roles are handed out — in n8n instances orchestrating AI agents and integrations, those credentials are often high-value API keys (LLM providers, cloud, databases). There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits at 0.00215 with a TRACK-only CISA SSVC decision, so this reads as a lower-urgency insider-abuse path rather than an internet-facing emergency. Patch to n8n 1.123.67, 2.31.5, or 2.32.1; until then, audit and tighten who holds Editor access on shared workflows and review credential-usage logs for sub-workflow nodes referencing credentials outside their owning project.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

Moderate risk. Exploitation requires an authenticated internal actor with Editor-level access to a shared workflow (privileges required, low complexity beyond knowing/guessing a credential ID), so it is not remotely exploitable by an anonymous attacker. However, it is a clean logic flaw with no user interaction needed once the malicious sub-workflow reference is saved, and it directly defeats n8n's project/credential isolation model, which is the core control organizations rely on for multi-tenant or multi-team workflow sharing. Given n8n's role as an AI agent orchestration and automation hub, compromised credentials can cascade into LLM API abuse, data exfiltration from connected SaaS/cloud accounts, or lateral movement.

How does the attack unfold?

Privileged Editor Access

Attacker already holds Editor-level access to a shared workflow because workflow sharing is enabled in the n8n instance.

Inline Credential Injection

Attacker adds an Execute Sub-workflow node and crafts inline workflow JSON referencing a target credential ID they are not authorized to use directly.

AML.T0081

Validation Bypass and Resolution

Because n8n only checks top-level node credentials, the reference passes save-time and runtime validation and resolves within the parent workflow's project context.

AML.T0106

Credential Use / Exfiltration

The sub-workflow executes using the borrowed credential, letting the attacker use or exfiltrate data from the service the credential unlocks.

AML.T0083

Privileged Editor Access

Attacker already holds Editor-level access to a shared workflow because workflow sharing is enabled in the n8n instance.

Inline Credential Injection

Attacker adds an Execute Sub-workflow node and crafts inline workflow JSON referencing a target credential ID they are not authorized to use directly.

AML.T0081

Validation Bypass and Resolution

Because n8n only checks top-level node credentials, the reference passes save-time and runtime validation and resolves within the parent workflow's project context.

AML.T0106

Credential Use / Exfiltration

The sub-workflow executes using the borrowed credential, letting the attacker use or exfiltrate data from the service the credential unlocks.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
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

6.5 / 10

EPSS

0.4%

chance of exploitation in 30 days

Higher than 27% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Unchanged

C High

I None

A None

What should I do?

1 step

Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 (or later), where credential-access validation covers credentials referenced inside inline sub-workflow JSON, not just top-level node credentials. Until patched, minimize the number of users with Editor access on shared workflows and disable workflow sharing where not strictly necessary. Audit existing workflows for Execute Sub-workflow nodes with inline JSON that reference credential IDs outside the editor's own project/team scope. Enable and review credential-usage/execution audit logs to detect anomalous credential resolution across projects, and rotate any credentials suspected of exposure to unauthorized Editors.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable No

Technical Impact total

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.T0081 - Modify AI Agent Configuration AML.T0083 - Credentials from AI Agent Configuration AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.2 - Access control for AI system resources

OWASP LLM Top 10

LLM06 - Sensitive Information Disclosure

Frequently Asked Questions

What is CVE-2026-72763?

n8n fails to validate credential-access permissions for credentials referenced inside an Execute Sub-workflow node's inline JSON, checking only a node's top-level credentials — a classic CWE-639 authorization-bypass-through-user-controlled-key flaw. Any user with Editor access to a shared workflow who simply knows (or guesses/enumerates) a target credential's ID can embed a reference to it in inline sub-workflow JSON, and it resolves normally at save and runtime inside the parent workflow's project context, effectively letting them use or exfiltrate credentials they were never granted. Blast radius depends entirely on whether workflow sharing is enabled and how broadly Editor roles are handed out — in n8n instances orchestrating AI agents and integrations, those credentials are often high-value API keys (LLM providers, cloud, databases). There is no CISA KEV listing, no public exploit or Nuclei template, and EPSS sits at 0.00215 with a TRACK-only CISA SSVC decision, so this reads as a lower-urgency insider-abuse path rather than an internet-facing emergency. Patch to n8n 1.123.67, 2.31.5, or 2.32.1; until then, audit and tighten who holds Editor access on shared workflows and review credential-usage logs for sub-workflow nodes referencing credentials outside their owning project.

Is CVE-2026-72763 actively exploited?

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

How to fix CVE-2026-72763?

Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 (or later), where credential-access validation covers credentials referenced inside inline sub-workflow JSON, not just top-level node credentials. Until patched, minimize the number of users with Editor access on shared workflows and disable workflow sharing where not strictly necessary. Audit existing workflows for Execute Sub-workflow nodes with inline JSON that reference credential IDs outside the editor's own project/team scope. Enable and review credential-usage/execution audit logs to detect anomalous credential resolution across projects, and rotate any credentials suspected of exposure to unauthorized Editors.

What systems are affected by CVE-2026-72763?

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

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

CVE-2026-72763 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.36%.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration/automation pipelines

MITRE ATLAS Techniques

AML.T0081 Modify AI Agent Configuration

AML.T0083 Credentials from AI Agent Configuration

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2.2

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

n8n before 1.123.67, 2.31.5, and 2.32.1 validates credential-access only for a node's top-level credentials and not for credentials referenced inside an Execute Sub-workflow node's inline workflow JSON. A member with Editor access to a shared workflow (when workflow sharing is enabled) who knows a target credential's ID can reference that credential in the inline JSON; it passes save-time and runtime validation and resolves in the parent workflow's project context, allowing the attacker to use or exfiltrate credentials they are not permitted to access.

Exploitation Scenario

A contractor or team member is granted Editor access to a shared n8n workflow for a legitimate task. They notice (via UI enumeration, error messages, or prior knowledge) the ID of a high-value credential — say, the finance team's LLM API key or a production database credential — that they are not authorized to use directly. Instead of trying to attach that credential to a node directly (which would be blocked by the top-level access check), they add an Execute Sub-workflow node and hand-craft inline workflow JSON that references the target credential ID. Because n8n only validates top-level node credentials, this passes save-time and runtime checks, and the credential resolves in the parent workflow's project context when executed. The attacker now has the sub-workflow call the target service using the borrowed credential, letting them exfiltrate data, rack up API usage, or pivot into whatever system that credential unlocks.

Weaknesses (CWE)

CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization 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.