CVE-2026-77069 in n8n
Summary
by MITRE • 08/20/2026
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).
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in versions of n8n prior to 1.123.69, 2.33.4, and 2.34.1 represents a critical Server-Side Request Forgery (SSRF) flaw rooted in an inconsistent implementation of security controls within the OAuth2 authentication workflow. Specifically, while the platform correctly applies SSRF protection mechanisms to HTTP requests involved in OAuth2 discovery and dynamic client registration processes, it fails to extend these safeguards to the token exchange phase. This architectural inconsistency creates a distinct attack vector where the application's internal network boundaries can be circumvented during the authorization-code-to-access-token step of the standard OAuth2 flow.
The technical root cause lies in the use of separate HTTP clients for different stages of the authentication process. The discovery and registration endpoints utilize an HTTP client equipped with SSRF mitigation logic, which typically validates URLs against a whitelist or blocks requests to private IP ranges. However, the token exchange endpoint relies on a distinct HTTP client instance that lacks these protective measures. Consequently, when a user initiates the OAuth2 flow by providing their own credentials within n8n, they gain control over specific configuration parameters associated with this step, most notably the access-token URL.
An attacker possessing credential-creation permissions can exploit this flaw by configuring an integration to point its access-token URL toward internal network addresses or local services that are otherwise inaccessible from the public internet. By doing so, the n8n instance is compelled to send a POST request containing OAuth2 token exchange data directly to these internal targets. The vulnerability allows for blind SSRF as well as reflected responses; if the target service returns an HTTP response body, n8n reflects this content back to the attacker through its own API or interface. This capability effectively turns the vulnerable application into a proxy that can probe and interact with internal infrastructure services such as metadata endpoints, database interfaces, or administrative panels.
The operational impact of this vulnerability is significant, particularly in environments where n8n instances are deployed within cloud networks or behind firewalls protecting sensitive backend systems. The ability to reflect response bodies means an attacker can not only verify the existence of internal hosts but also extract data returned by those services. This could lead to the exposure of sensitive configuration details, authentication tokens from other internal services, or even further exploitation if the reflected content reveals exploitable vulnerabilities in the targeted internal applications. Although the attack is limited to what the target returns for this specific request type, the ability to pivot through n8n significantly expands the attacker's reach within the network topology.
This issue aligns with CWE-918, which describes Server-Side Request Forgery (SSRF) flaws resulting from improper validation of user-supplied URLs or IP addresses before server-side processing. Furthermore, in terms of offensive security frameworks, this vulnerability facilitates techniques categorized under MITRE ATT&CK T1560, specifically Archive Collected Data via SSRF, as it allows an attacker to collect data from internal resources by leveraging the application's outbound request capabilities. It also relates to T1498, Network Denial of Service via Resource Exhaustion if the reflected responses are large or numerous, though the primary concern remains unauthorized network access and data exfiltration.
To mitigate this vulnerability, organizations must immediately upgrade n8n to version 1.123.69, 2.33.4, or later, where the token exchange HTTP client has been patched with SSRF protection logic consistent with other parts of the application. For environments that cannot be upgraded instantly due to compatibility constraints, network-level controls should be implemented to restrict outbound traffic from n8n instances to only known and necessary external endpoints. Additionally, implementing strict input validation on credential configuration fields at a reverse proxy or WAF layer can help block requests targeting private IP ranges before they reach the application logic. Regular audits of integration configurations are also recommended to ensure that no existing workflows have been configured with malicious internal URLs prior to patching.