CVE-2026-77069: n8n SSRF bypass — LOW

CISO Take

n8n's OAuth2 credential flow relies on two separate HTTP clients: one for discovery and dynamic-client-registration requests, protected against SSRF, and a second one for the authorization-code-to-access-token exchange, which is not. A user who already has credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that internal target and reflect its response body back. This is rated low severity with no CVSS score, no CISA KEV listing, no EPSS data, and no public exploit or scanner template, so it is not an unauthenticated remote-takeover bug — it requires a privileged internal user, which caps the realistic blast radius. The concern for CISOs is architectural: n8n increasingly orchestrates AI agent workflows with stored credentials to internal systems and cloud APIs, and the package already carries 201 historical CVEs and a 69/100 risk score reflecting a fast-moving, security-relevant attack surface, so a low-trust internal user (contractor, junior admin) could pivot this into cloud metadata or internal service disclosure. Patch to n8n 1.123.69, 2.33.4, or 2.34.1, restrict credential-creation permissions to trusted admins in the interim, and apply egress filtering from the n8n host to block outbound requests to RFC1918 ranges and cloud metadata endpoints (169.254.169.254).

Sources:NVDGitHub AdvisoryOpenSSFvulncheck.com

What is the risk?

Low severity per vendor rating with no CVSS vector, no active exploitation signals (not in CISA KEV, no EPSS score, no public PoC or Nuclei template), and a privileged prerequisite (credential-creation permission) that meaningfully narrows the exploitable population versus an unauthenticated SSRF. However, the package-level risk profile is elevated: n8n carries 201 other CVEs, a package risk score of 69/100, and an OpenSSF Scorecard of only 6.6/10, indicating a broad and actively-probed attack surface even if this specific finding is low-severity in isolation. Impact is bounded — the response reflected to the attacker is limited to what the internal target returns for this one fixed-shape POST request, not arbitrary read/write access — but that is still enough to leak cloud IAM credentials from instance metadata services or probe internal service responses.

How does the attack unfold?

Malicious Credential Configuration

A user with credential-creation permissions in n8n configures an OAuth2 credential with the access-token URL pointed at an internal address (e.g., cloud metadata service).

AML.T0049

SSRF Protection Bypass

The user completes the OAuth2 authorization-code flow, triggering n8n's unguarded token-exchange HTTP client to send a fixed-shape POST request to the internal target.

Response Reflection

n8n reflects the internal target's response body back to the attacker, potentially disclosing cloud IAM credentials or internal service data limited to that single request/response.

Malicious Credential Configuration

A user with credential-creation permissions in n8n configures an OAuth2 credential with the access-token URL pointed at an internal address (e.g., cloud metadata service).

AML.T0049

SSRF Protection Bypass

The user completes the OAuth2 authorization-code flow, triggering n8n's unguarded token-exchange HTTP client to send a fixed-shape POST request to the internal target.

Response Reflection

n8n reflects the internal target's response body back to the attacker, potentially disclosing cloud IAM credentials or internal service data limited to that single request/response.

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 22% 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.69, 2.33.4, or 2.34.1 where the token-exchange client is SSRF-protected. Until patched, restrict credential-creation permissions to trusted administrators only and audit existing OAuth2 credentials for access-token URLs pointing at internal/private IP ranges. Apply network-level egress filtering from the n8n host to block outbound requests to RFC1918 address space and cloud metadata endpoints (169.254.169.254, metadata.google.internal). Monitor for anomalous OAuth2 credential creation or token-exchange requests targeting non-public hostnames/IPs.

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 LeakageAgentAPIAML.T0049- Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

NIST AI RMF

MANAGE-2.3-Procedures are followed to respond to and recover from a previously unknown risk when it is identified

OWASP LLM Top 10

LLM07-Insecure Plugin Design

Frequently Asked Questions

What is CVE-2026-77069?

n8n's OAuth2 credential flow relies on two separate HTTP clients: one for discovery and dynamic-client-registration requests, protected against SSRF, and a second one for the authorization-code-to-access-token exchange, which is not. A user who already has credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that internal target and reflect its response body back. This is rated low severity with no CVSS score, no CISA KEV listing, no EPSS data, and no public exploit or scanner template, so it is not an unauthenticated remote-takeover bug — it requires a privileged internal user, which caps the realistic blast radius. The concern for CISOs is architectural: n8n increasingly orchestrates AI agent workflows with stored credentials to internal systems and cloud APIs, and the package already carries 201 historical CVEs and a 69/100 risk score reflecting a fast-moving, security-relevant attack surface, so a low-trust internal user (contractor, junior admin) could pivot this into cloud metadata or internal service disclosure. Patch to n8n 1.123.69, 2.33.4, or 2.34.1, restrict credential-creation permissions to trusted admins in the interim, and apply egress filtering from the n8n host to block outbound requests to RFC1918 ranges and cloud metadata endpoints (169.254.169.254).

Is CVE-2026-77069 actively exploited?

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

How to fix CVE-2026-77069?

Upgrade to n8n 1.123.69, 2.33.4, or 2.34.1 where the token-exchange client is SSRF-protected. Until patched, restrict credential-creation permissions to trusted administrators only and audit existing OAuth2 credentials for access-token URLs pointing at internal/private IP ranges. Apply network-level egress filtering from the n8n host to block outbound requests to RFC1918 address space and cloud metadata endpoints (169.254.169.254, metadata.google.internal). Monitor for anomalous OAuth2 credential creation or token-exchange requests targeting non-public hostnames/IPs.

What systems are affected by CVE-2026-77069?

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

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksworkflow orchestration pipelines

MITRE ATLAS Techniques

AML.T0049Exploit Public-Facing Application

Compliance Controls Affected

NIST AI RMF: MANAGE-2.3

OWASP LLM Top 10: LLM07

What are the technical details?

Original Advisory

n8n before 1.123.69, 2.33.4, and 2.34.1 contains an SSRF protection bypass in the OAuth2 credential authorization-code-to-access-token exchange. While OAuth2 discovery and dynamic-client-registration requests use n8n's SSRF-protected HTTP client, the token exchange uses a separate client with no SSRF guard. A user with credential-creation permissions can set the access-token URL to an internal address and complete the OAuth2 flow, causing n8n to send a fixed-shape token-exchange POST to that target and reflect its response body back to the attacker (limited to what the target returns to this specific request).

Exploitation Scenario

An internal user who has been granted credential-creation permissions in n8n (e.g., a workflow builder or low-privilege admin) creates an OAuth2 credential and sets the access-token URL to an internal cloud metadata endpoint such as http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>. They complete the OAuth2 authorization flow; n8n's unguarded token-exchange client sends the fixed-shape POST request to that internal address on the attacker's behalf and reflects the response body back to them, potentially exposing IAM role credentials or other internal service data reachable only from the n8n host's network position.

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.