CVE-2026-72771: n8n allowlist bypass

CISO Take

n8n fails to enforce its 'Allowed HTTP Request Domains' allowlist inside AI and LLM nodes whenever a workflow editor can set a custom base or endpoint URL, letting that user redirect outbound requests to a host they control and capture shared credential secrets in transit. This isn't a remote, unauthenticated bug — it requires a low-privileged workflow editor with only use-only access to shared credentials, but that's exactly the kind of internal, semi-trusted access common in n8n's collaborative automation setups, so the practical blast radius is any org that relies on the allowlist as a security boundary between editors and credential owners. No public exploit or scanner template exists yet and EPSS sits at 0.00215 (top 88th percentile relative to other CVEs, but still a low absolute probability), so this is not an active-exploitation emergency — CISA SSVC rates it TRACK. Patch to n8n 2.32.1 or later; until then, audit which users have use-only credential access on AI/LLM nodes, tighten the Allowed HTTP Request Domains policy at the network egress layer (not just app-level), and review workflow execution logs for AI nodes pointed at unexpected external hosts.

Sources: NVD GitHub Advisory EPSS ATLAS vulncheck.com

What is the risk?

Medium risk. The vulnerability requires an authenticated, low-privileged workflow-editor role rather than unauthenticated remote access, which limits exposure to orgs that already grant broad editor access or run multi-tenant n8n instances. However, impact is significant where it applies: credential secrets (API keys, tokens) tied to shared credentials can be exfiltrated and reused directly against the underlying AI/LLM services or other integrated systems, enabling lateral movement beyond n8n itself. No KEV listing, no public PoC, and a low EPSS score keep near-term mass-exploitation likelihood low, but the CWE-863 (incorrect authorization) root cause is trivial to exploit once an attacker has the required role, so insider-threat and compromised-low-priv-account scenarios deserve attention.

How does the attack unfold?

Initial Access

A low-privileged workflow editor with use-only access to a shared credential logs into the n8n instance.

Allowlist Bypass

The editor sets a malicious base or endpoint URL on an AI/LLM node, which n8n executes without enforcing the Allowed HTTP Request Domains allowlist.

AML.T0106

Credential Exfiltration

The node sends the outbound request to the attacker-controlled host, leaking the shared credential secret in the process.

AML.T0086

Credential Reuse

The attacker reuses the harvested credential directly against the underlying AI/LLM service or other systems it grants access to.

AML.T0091.000

Initial Access

A low-privileged workflow editor with use-only access to a shared credential logs into the n8n instance.

Allowlist Bypass

The editor sets a malicious base or endpoint URL on an AI/LLM node, which n8n executes without enforcing the Allowed HTTP Request Domains allowlist.

AML.T0106

Credential Exfiltration

The node sends the outbound request to the attacker-controlled host, leaking the shared credential secret in the process.

AML.T0086

Credential Reuse

The attacker reuses the harvested credential directly against the underlying AI/LLM service or other systems it grants access to.

AML.T0091.000

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

1) Upgrade n8n to version 2.32.1 or later, which enforces the allowlist correctly in AI/LLM nodes. 2) Until patched, restrict or remove use-only shared-credential access for non-trusted workflow editors, since the allowlist cannot currently be relied upon as a boundary. 3) Enforce network-level egress controls (firewall/proxy allowlisting) on the n8n host so outbound requests from AI nodes cannot reach attacker-controlled domains regardless of app-level config. 4) Rotate credentials used in shared AI/LLM node connections as a precaution, especially in instances with broad editor populations. 5) Monitor n8n execution logs for AI/LLM nodes configured with unexpected or externally-resolving base/endpoint URLs as a detection signal.

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.T0025 - Exfiltration via Cyber Means AML.T0086 - Exfiltration via AI Agent Tool Invocation 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

NIST AI RMF

MEASURE 2.7 - AI system security and resilience evaluation

OWASP LLM Top 10

LLM07 - Insecure Plugin/Tool Design

Frequently Asked Questions

What is CVE-2026-72771?

n8n fails to enforce its 'Allowed HTTP Request Domains' allowlist inside AI and LLM nodes whenever a workflow editor can set a custom base or endpoint URL, letting that user redirect outbound requests to a host they control and capture shared credential secrets in transit. This isn't a remote, unauthenticated bug — it requires a low-privileged workflow editor with only use-only access to shared credentials, but that's exactly the kind of internal, semi-trusted access common in n8n's collaborative automation setups, so the practical blast radius is any org that relies on the allowlist as a security boundary between editors and credential owners. No public exploit or scanner template exists yet and EPSS sits at 0.00215 (top 88th percentile relative to other CVEs, but still a low absolute probability), so this is not an active-exploitation emergency — CISA SSVC rates it TRACK. Patch to n8n 2.32.1 or later; until then, audit which users have use-only credential access on AI/LLM nodes, tighten the Allowed HTTP Request Domains policy at the network egress layer (not just app-level), and review workflow execution logs for AI nodes pointed at unexpected external hosts.

Is CVE-2026-72771 actively exploited?

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

How to fix CVE-2026-72771?

1) Upgrade n8n to version 2.32.1 or later, which enforces the allowlist correctly in AI/LLM nodes. 2) Until patched, restrict or remove use-only shared-credential access for non-trusted workflow editors, since the allowlist cannot currently be relied upon as a boundary. 3) Enforce network-level egress controls (firewall/proxy allowlisting) on the n8n host so outbound requests from AI nodes cannot reach attacker-controlled domains regardless of app-level config. 4) Rotate credentials used in shared AI/LLM node connections as a precaution, especially in instances with broad editor populations. 5) Monitor n8n execution logs for AI/LLM nodes configured with unexpected or externally-resolving base/endpoint URLs as a detection signal.

What systems are affected by CVE-2026-72771?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM API integrations.

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

CVE-2026-72771 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 frameworksLLM API integrations

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0086 Exfiltration via AI Agent Tool Invocation

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n versions before 2.32.1 fail to enforce the Allowed HTTP Request Domains allowlist in multiple AI and LLM nodes when user-supplied base or endpoint URLs are configured. Low-privileged workflow editors with use-only access to shared credentials can redirect requests to attacker-controlled hosts and exfiltrate credential secrets for reuse against underlying services.

Exploitation Scenario

An attacker with (or who compromises) a low-privileged n8n workflow-editor account — granted use-only access to a shared LLM API credential for legitimate automation work — edits an AI/LLM node's base or endpoint URL field to point at an attacker-controlled server instead of the intended provider. Because the Allowed HTTP Request Domains allowlist isn't enforced for this field, n8n executes the request as configured, sending the credential secret (API key/token) to the attacker's host in the process (e.g., via Authorization header or query parameter). The attacker captures the credential from their server logs and reuses it directly against the real LLM provider or other underlying service the credential was scoped to, exceeding their original use-only permissions and potentially incurring cost, data exposure, or further pivoting through that service.

Weaknesses (CWE)

CWE-863 Incorrect Authorization Primary CWE-863 Incorrect Authorization

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

[Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
[Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.