n8n EUVD-2026-63273

Three conditions must all be true simultaneously: (1) the n8n instance must be running with the environment variable N8N_SSRF_PROTECTION_ENABLED=true explicitly set - this is a non-default opt-in flag; (2) the attacker must have an authenticated n8n account with permission to create SearXNG-type credentials; and (3) that same account must have permission to create and configure a personal agent. Exploitation is bounded by the n8n server's network reachability - the attacker can only probe hosts accessible to the n8n process, not arbitrary internet addresses (which would be reachable regardless). Unauthenticated exploitation is not possible based on the PR:L CVSS metric. The irony of the exploitation condition is that instances without SSRF protection enabled (the majority, as it is opt-in) do not expose this specific bypass, though they may have broader SSRF exposure.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:H/SI:N/SA:N, score 6.3) captures the key tension in this vulnerability: exploitation is network-accessible and low-complexity, but gated behind authenticated low-privilege access (PR:L), which meaningfully limits the attack surface. The SC:H metric for subsequent-system confidentiality reflects the SSRF's ability to expose internal services well beyond n8n itself - cloud metadata APIs (e.g., IMDSv1), internal REST services, and private network hosts. Exploitation is further scoped to instances where SSRF protection has been explicitly enabled, which is a non-default opt-in; operators who have not set N8N_SSRF_PROTECTION_ENABLED=true are not protected by the flag but are also not specifically targeted by this bypass. No EPSS score was provided in the input data, and there is no KEV listing or confirmed POC, suggesting no observed opportunistic exploitation at this time. Real-world priority is moderate: high in multi-tenant n8n deployments or cloud-hosted instances where credential-creation permissions are broadly granted; lower in single-user or tightly permissioned deployments.

An authenticated n8n user with credential-creation rights creates a SearXNG credential and sets the API URL to an internal address - for example, http://169.254.169.254/latest/meta-data/ on an AWS-hosted instance or http://internal-db-service:5432. They attach this credential to a personal agent and initiate a chat session; when the agent invokes the SearXNG tool, the n8n server issues an HTTP request directly to the internal address and streams the response back through the chat output, exposing cloud instance metadata, internal API responses, or service banners. No public exploit identified at time of analysis.