CVE-2026-85172: n8n SSRF bypass — MEDIUM

CISO Take

n8n's legacy HTTP request helper — reachable from Code and Function nodes used in nearly every automation workflow — validates the 'uri' field for SSRF safety but actually issues the request using 'url' when both are present, so an attacker who can author or edit a workflow simply supplies a safe-looking uri alongside a malicious internal url to reach systems that should be unreachable. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template yet, so this looks pre-mass-exploitation, but n8n is explicitly an AI-agent orchestration platform with 16 tracked downstream dependents and a mediocre 6.7/10 OpenSSF Scorecard, and this is the 211th CVE recorded against the package — a track record that argues for treating it as a when, not if. The real danger for AI automation shops is that Code/Function nodes are often where workflow builders (or, increasingly, LLM-generated workflow logic) paste in HTTP calls without security review, making this an easy pivot into cloud metadata endpoints or internal APIs. Patch to n8n 2.34.1 or later immediately; if you can't patch same-day, restrict who can create/edit Code and Function nodes, egress-filter outbound traffic from the n8n host (block 169.254.169.254 and RFC1918 ranges), and audit workflow HTTP request configurations for any node where 'uri' and 'url' both appear with differing hosts.

Sources:NVDGitHub AdvisoryOpenSSFATLASvulncheck.com

What is the risk?

No CVSS/EPSS scoring exists yet and there is no evidence of public exploitation, active scanning, or a Metasploit/Nuclei module, which keeps near-term opportunistic risk moderate. However, the underlying flaw (CWE-918 SSRF via validation/execution mismatch) is trivial to exploit once understood — it only requires crafting a request object with two differing fields — and the blast radius is amplified by n8n's role as an agent/automation hub that frequently sits with network access to internal services, databases, and cloud provider metadata APIs. Given the package's long CVE history (211 prior issues) and below-average supply-chain hygiene score, treat this as high-priority-to-patch even without a severity score attached.

How does the attack unfold?

Initial Access

Attacker gains the ability to author or modify an n8n workflow, via a compromised editor account, an exposed public n8n instance, or a malicious imported workflow template.

AML.T0049

Exploitation

Attacker adds a Code/Function node calling the legacy request helper with a benign 'uri' and a malicious internal 'url', bypassing the SSRF validation that only checks 'uri'.

Credential/Data Access

The underlying HTTP client dispatches the request to the internal 'url' target, such as cloud metadata services or internal admin APIs, returning sensitive data or credentials into the workflow execution.

AML.T0106

Exfiltration

Attacker retrieves the sensitive response from the node's output or execution logs and uses it to pivot further into cloud or internal infrastructure.

Initial Access

Attacker gains the ability to author or modify an n8n workflow, via a compromised editor account, an exposed public n8n instance, or a malicious imported workflow template.

AML.T0049

Exploitation

Attacker adds a Code/Function node calling the legacy request helper with a benign 'uri' and a malicious internal 'url', bypassing the SSRF validation that only checks 'uri'.

Credential/Data Access

The underlying HTTP client dispatches the request to the internal 'url' target, such as cloud metadata services or internal admin APIs, returning sensitive data or credentials into the workflow execution.

AML.T0106

Exfiltration

Attacker retrieves the sensitive response from the node's output or execution logs and uses it to pivot further into cloud or internal infrastructure.

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
n8n	npm	—	No patch
209.2KOpenSSF 7.116 dependentsPushed yesterday44% 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 18% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade n8n to version 2.34.1 or later, where the uri/url validation mismatch is fixed. Until patched, restrict workflow-editing permissions so only trusted users can add or modify Code/Function nodes, and disable or tightly control import of third-party workflow templates. Apply network-level egress controls on the host running n8n: block outbound access to link-local addresses (169.254.169.254), RFC1918 internal ranges, and localhost from the n8n container/VM unless explicitly required. For detection, review n8n execution logs and any outbound request logging for Code/Function node HTTP calls where the target host doesn't match the workflow's documented uri, and monitor for unexpected traffic to internal-only endpoints originating from the n8n host.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

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

How is it classified?

Auth BypassData LeakageAgentPluginAML.T0049- Exploit Public-Facing Application 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

MANAGE 4.1-Post-deployment AI system risks are monitored and responded to

OWASP LLM Top 10

LLM07-Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-85172?

n8n's legacy HTTP request helper — reachable from Code and Function nodes used in nearly every automation workflow — validates the 'uri' field for SSRF safety but actually issues the request using 'url' when both are present, so an attacker who can author or edit a workflow simply supplies a safe-looking uri alongside a malicious internal url to reach systems that should be unreachable. There's no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template yet, so this looks pre-mass-exploitation, but n8n is explicitly an AI-agent orchestration platform with 16 tracked downstream dependents and a mediocre 6.7/10 OpenSSF Scorecard, and this is the 211th CVE recorded against the package — a track record that argues for treating it as a when, not if. The real danger for AI automation shops is that Code/Function nodes are often where workflow builders (or, increasingly, LLM-generated workflow logic) paste in HTTP calls without security review, making this an easy pivot into cloud metadata endpoints or internal APIs. Patch to n8n 2.34.1 or later immediately; if you can't patch same-day, restrict who can create/edit Code and Function nodes, egress-filter outbound traffic from the n8n host (block 169.254.169.254 and RFC1918 ranges), and audit workflow HTTP request configurations for any node where 'uri' and 'url' both appear with differing hosts.

Is CVE-2026-85172 actively exploited?

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

How to fix CVE-2026-85172?

Upgrade n8n to version 2.34.1 or later, where the uri/url validation mismatch is fixed. Until patched, restrict workflow-editing permissions so only trusted users can add or modify Code/Function nodes, and disable or tightly control import of third-party workflow templates. Apply network-level egress controls on the host running n8n: block outbound access to link-local addresses (169.254.169.254), RFC1918 internal ranges, and localhost from the n8n container/VM unless explicitly required. For detection, review n8n execution logs and any outbound request logging for Code/Function node HTTP calls where the target host doesn't match the workflow's documented uri, and monitor for unexpected traffic to internal-only endpoints originating from the n8n host.

What systems are affected by CVE-2026-85172?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow automation / orchestration pipelines

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

AML.T0106Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

NIST AI RMF: MANAGE 4.1

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n versions before 2.34.1 contain a server-side request forgery vulnerability in the legacy request helper function exposed to Code and Function nodes. The validation logic checks the uri property for SSRF safety while the underlying HTTP client uses the url property when both are present, allowing attackers to bypass validation by supplying a safe uri alongside a malicious url to access internal addresses.

Exploitation Scenario

An attacker with the ability to create or edit an n8n workflow — for example, a lower-privileged user, a compromised workflow-editor account, or an actor distributing a booby-trapped shared workflow template — adds a Code or Function node that calls the legacy HTTP request helper with uri set to an innocuous external address (satisfying the SSRF validator) but url set to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` or an internal admin API. The validation logic checks and approves the uri field, but the underlying HTTP client actually dispatches the request to the url field, reaching the cloud metadata service or internal system. The workflow's node output returns the response (e.g., temporary IAM credentials or internal API data) directly in the n8n UI or logs, which the attacker then exfiltrates and uses to pivot further into cloud infrastructure or internal services.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.