n8n CVE-2026-77069

The attacker must hold a valid n8n user account that has been granted the credential-creation permission - this is a non-default, operator-assigned permission level, not available to anonymous or read-only users. The attacker must be able to configure an OAuth2 credential object with a custom access-token URL and then trigger the OAuth2 authorization code exchange flow, which requires the OAuth2 authorization server step to complete (or be simulated). Exploitation is bounded by the fixed shape of the token-exchange POST that n8n sends; internal services that do not respond meaningfully to this specific request shape will return little useful data. The AT:P metric in the CVSS 4.0 vector confirms that specific preconditions - namely credential-creation access and the ability to complete the OAuth2 flow - must be satisfied. Exploitation is further constrained to read-only reconnaissance (VC:L, VI:N, VA:N); there is no write or denial-of-service capability through this vector.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N) scores only 2.3, accurately reflecting several mitigating factors: exploitation requires an authenticated user account with credential-creation privileges (PR:L), the attack requirements metric AT:P signals that a specific configuration step - setting a malicious access-token URL and completing the OAuth2 authorization code flow - must be carried out, and the impact is limited to low-confidence reads of what internal services return to a fixed-shape POST body. The subsequent-system confidentiality impact (SC:L) captures that the real damage surface is internal services behind n8n's network boundary, not n8n itself. The EPSS score is not provided in the input data; given the lack of KEV listing and absence of public exploit code, real-world exploitation probability is assessed as low-to-moderate, confined to insider threat or compromised low-privileged account scenarios. This is not a 'spray-and-pray' SSRF - it cannot be triggered without an account, and the SSRF response is gated by what the internal endpoint returns to the token-exchange POST shape, limiting reconnaissance value compared to a general-purpose SSRF. Organizations exposing n8n to untrusted users with credential-creation permissions face the most realistic risk.

An attacker holding a low-privileged n8n account with credential-creation rights creates a new OAuth2 credential and sets the access-token URL to an internal address such as http://169.254.169.254/latest/meta-data/ (cloud instance metadata) or an internal microservice endpoint. The attacker then initiates the OAuth2 authorization-code flow within n8n; when n8n reaches the token-exchange step, it issues an unguarded POST to the configured internal URL and returns the response body to the attacker's browser, exposing whatever the internal service returns to that request shape. No public proof-of-concept code has been identified at the time of this analysis.