CVE-2026-72774: n8n credential auth bypass

CISO Take

A flaw in n8n's HTTP Request node lets any authenticated user with edit access to a shared workflow reference and load another user's stored credential, because the pre-execution permission check validates the unresolved expression string rather than the credential type actually resolved at runtime — so the ownership check is silently skipped and the credential is loaded at execution time. This matters most for organizations running n8n as an internal AI agent orchestration layer, since credentials on shared workflows frequently include LLM API keys, vector database tokens, and third-party SaaS secrets used across teams. The EPSS score sits in the top 78th percentile for exploitation likelihood despite no public PoC or Nuclei template existing yet, and CISA's SSVC decision is TRACK rather than ACT, reflecting that this is an insider-privilege-escalation bug rather than an unauthenticated remote exploit. Exploitation requires the attacker to already hold workflow edit access and to know or guess the target credential's identifier, which bounds the blast radius to malicious or compromised insiders and collaborators on multi-tenant instances. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately, and in the interim audit workflow-sharing permissions and credential-to-workflow bindings, especially any shared automation wired to AI/LLM credentials or API keys.

Sources: NVD EPSS GitHub Advisory ATLAS

What is the risk?

Moderate risk overall: the vulnerability is not remotely exploitable by an unauthenticated party and requires the attacker to already have edit access to a shared workflow plus knowledge of the target credential's identifier, which limits it to an insider-threat or lateral-movement scenario. However, impact is high where exploited — full use or exfiltration of another user's credential (including LLM API keys, cloud tokens, or database secrets) with no CVSS score yet published, no CISA KEV listing, and no public exploit or scanner template observed. EPSS at the 78th percentile suggests meaningful attacker interest in n8n as a target class even without weaponized tooling today. Risk rises sharply in n8n deployments that broadly share workflow edit permissions across teams or use n8n as a central credential vault for AI agent tool integrations.

How does the attack unfold?

Initial Access

Attacker holds legitimate edit access to a shared n8n workflow, either as an insider or via a compromised low-privilege account.

AML.T0012

Discovery

Attacker identifies the internal identifier of a target credential they are not authorized to use, e.g. through the workflow UI or prior workflow history.

AML.T0084

Exploitation

Attacker configures the HTTP Request node to reference the target credential while specifying its type via an expression, causing the flawed pre-execution check to skip the ownership validation.

AML.T0083

Impact

The unauthorized credential is loaded at execution time, letting the attacker use it to call the underlying API or exfiltrate the secret via the workflow's output.

AML.T0098

Initial Access

Attacker holds legitimate edit access to a shared n8n workflow, either as an insider or via a compromised low-privilege account.

AML.T0012

Discovery

Attacker identifies the internal identifier of a target credential they are not authorized to use, e.g. through the workflow UI or prior workflow history.

AML.T0084

Exploitation

Attacker configures the HTTP Request node to reference the target credential while specifying its type via an expression, causing the flawed pre-execution check to skip the ownership validation.

AML.T0083

Impact

The unauthorized credential is loaded at execution time, letting the attacker use it to call the underlying API or exfiltrate the secret via the workflow's output.

AML.T0098

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

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 36% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 immediately, which fixes the permission check to compare the resolved credential type rather than the unresolved expression. Until patched, restrict workflow edit/sharing permissions to trusted users only and avoid granting broad edit access to workflows that reference sensitive credentials (LLM API keys, database secrets, cloud tokens). Rotate any credentials that were accessible to users with shared workflow edit rights during the vulnerable window, and audit n8n execution logs for HTTP Request node calls using unexpected or dynamically-resolved credential types. Where possible, scope credentials per-workflow or per-team rather than sharing broad organizational credentials across many collaborators.

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 Privacy Violation Data Leakage Agent Plugin AML.T0012 - Valid Accounts AML.T0083 - Credentials from AI Agent Configuration AML.T0098 - AI Agent Tool Credential Harvesting

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, robustness and cybersecurity

ISO 42001

A.6.2 - AI system resource access controls

NIST AI RMF

GOVERN 1.5 - Risk monitoring and access control mechanisms

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-72774?

A flaw in n8n's HTTP Request node lets any authenticated user with edit access to a shared workflow reference and load another user's stored credential, because the pre-execution permission check validates the unresolved expression string rather than the credential type actually resolved at runtime — so the ownership check is silently skipped and the credential is loaded at execution time. This matters most for organizations running n8n as an internal AI agent orchestration layer, since credentials on shared workflows frequently include LLM API keys, vector database tokens, and third-party SaaS secrets used across teams. The EPSS score sits in the top 78th percentile for exploitation likelihood despite no public PoC or Nuclei template existing yet, and CISA's SSVC decision is TRACK rather than ACT, reflecting that this is an insider-privilege-escalation bug rather than an unauthenticated remote exploit. Exploitation requires the attacker to already hold workflow edit access and to know or guess the target credential's identifier, which bounds the blast radius to malicious or compromised insiders and collaborators on multi-tenant instances. Patch to n8n 1.123.67, 2.31.5, or 2.32.1 immediately, and in the interim audit workflow-sharing permissions and credential-to-workflow bindings, especially any shared automation wired to AI/LLM credentials or API keys.

Is CVE-2026-72774 actively exploited?

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

How to fix CVE-2026-72774?

Upgrade to n8n 1.123.67, 2.31.5, or 2.32.1 immediately, which fixes the permission check to compare the resolved credential type rather than the unresolved expression. Until patched, restrict workflow edit/sharing permissions to trusted users only and avoid granting broad edit access to workflows that reference sensitive credentials (LLM API keys, database secrets, cloud tokens). Rotate any credentials that were accessible to users with shared workflow edit rights during the vulnerable window, and audit n8n execution logs for HTTP Request node calls using unexpected or dynamically-resolved credential types. Where possible, scope credentials per-workflow or per-team rather than sharing broad organizational credentials across many collaborators.

What systems are affected by CVE-2026-72774?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, workflow orchestration / low-code AI automation, multi-tenant credential management.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration / low-code AI automationmulti-tenant credential management

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0083 Credentials from AI Agent Configuration

AML.T0098 AI Agent Tool Credential Harvesting

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: GOVERN 1.5

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

n8n before 1.123.67, 2.31.5, and 2.32.1 contains a credential authorization bypass in the HTTP Request node. An authenticated member with edit access to a shared workflow can reference another user's credential while specifying the credential type via an expression. Because the pre-execution permission check compares the unresolved expression instead of the resolved credential type, the ownership check is skipped and the credential is loaded at execution time, allowing the member to use or exfiltrate a credential they were not granted. Exploitation requires knowing the target credential's identifier.

Exploitation Scenario

A malicious or compromised insider with edit access to a shared n8n workflow — for example a contractor or team member on a collaborative AI-agent automation project — identifies the internal identifier of a colleague's high-privilege credential (such as an admin-level LLM API key or a production database token) through workflow UI enumeration or prior legitimate access. They modify an HTTP Request node to reference that credential ID while specifying the credential type via an expression rather than a static value. Because n8n's pre-execution check validates the unresolved expression instead of the type resolved at runtime, the ownership check passes incorrectly, and the credential is loaded and used when the workflow executes. The attacker then routes the HTTP Request node's response back into workflow output or a connected node to exfiltrate the secret, or simply rides the credential to make unauthorized calls to the LLM API or downstream service on the victim's behalf.

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.