CVE-2026-77069: n8n before 1.123.69 SSRF Protection Bypass via OAuth2
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).
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
n8nto a version that resolves this vulnerability.Fixed in 1.123.69 - Upgrade
Upgrade
n8nto a version that resolves this vulnerability.Fixed in 2.33.4 - Upgrade
Upgrade
n8nto a version that resolves this vulnerability.Fixed in 2.34.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs permission to create credentials in n8n and must be able to complete an OAuth2 authorization-code flow. This is therefore primarily exposed where untrusted or lower-trust users can create OAuth2 credentials.
What internal access does the attacker gain?
The attacker can direct the OAuth2 access-token exchange to an internal address, causing n8n to issue a fixed-shape POST request to that target. The response body from the target is reflected back, but disclosure is limited to what the target returns for that specific request.
Which releases need to be updated?
Affected releases are n8n versions before 1.123.69, 2.33.4, and 2.34.1. Updating to the applicable listed release or later addresses the issue.
What can be done before patching?
Restrict credential-creation permissions to trusted users. This removes the stated prerequisite for configuring an internal access-token URL.