CVE-2026-77085 in n8n
Summary
by MITRE • 08/20/2026
n8n before 2.34.1 and 2.33.x before 2.33.4 contains an SSRF protection bypass in the SearXNG Agent tool. The tool sent requests to the user-supplied API URL using a raw HTTP client that did not route through n8n's centralized SSRF protection. On instances with N8N_SSRF_PROTECTION_ENABLED=true, an authenticated user with permission to create SearXNG credentials and configure a personal agent could set the API URL to an internal host, causing the n8n server to connect to that host and return the response content through the Agent chat output.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in versions of n8n prior to 2.34.1 and specifically within the 2.33.x series before version 2.33.4 represents a critical Server-Side Request Forgery (SSRF) protection bypass. This flaw is localized to the SearXNG Agent tool, which serves as an interface for interacting with search engine APIs through automated workflows. The core technical deficiency lies in how HTTP requests are dispatched when utilizing this specific agent feature. Instead of routing outbound network connections through n8n’s centralized SSRF mitigation layer, the implementation utilizes a raw HTTP client that operates independently of these security controls. This architectural oversight allows an attacker to circumvent standard perimeter defenses designed to restrict internal network access from server-side applications.
The operational impact of this vulnerability is significant for environments where Server-Side Request Forgery protection has been explicitly enabled via the N8N_SSRF_PROTECTION_ENABLED configuration flag. In such configurations, authenticated users who possess the necessary permissions to create SearXNG credentials and configure personal agents can exploit this bypass. By manipulating the API URL parameter within their agent settings, an attacker can direct the n8n server to initiate connections against internal hosts that are otherwise inaccessible from external networks or blocked by firewall rules. The vulnerability allows for both connection attempts and data exfiltration, as the response content generated by these internal services is returned through the Agent chat output interface, effectively providing a tunnel into the private network infrastructure.
This issue aligns with Common Weakness Enumeration (CWE) category CWE-918, which describes Server-Side Request Forgery where the server makes requests to unintended destinations due to insufficient validation of user-supplied input. Furthermore, from an adversary perspective, this technique corresponds to ATT&CK tactic T1557, specifically subtechnique Lateral Tool Transfer or Adversary-in-the-Middle scenarios if used for interception, but more accurately fits within the broader context of network reconnaissance and internal service exploitation enabled by SSRF capabilities such as those categorized under T1046 Network Service Discovery. The ability to reach internal services can facilitate further attacks including credential harvesting from local authentication endpoints or accessing sensitive data stored on internal databases that are not exposed publicly.
Mitigation strategies must prioritize immediate version upgrades for all affected instances. Organizations running n8n versions 2.33.x should upgrade immediately to version 2.33.4, while those using earlier major branches should update to at least version 2.34.1 where the centralized SSRF protection logic has been correctly integrated into the SearXNG Agent HTTP client implementation. For environments that cannot be patched instantly due to operational constraints, temporary mitigations include restricting network egress from n8n servers via firewall rules to only allow connections to known external API endpoints and blocking access to internal IP ranges such as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 at the network perimeter level. Additionally, enforcing strict role-based access control (RBAC) to limit who can create credentials or configure agents reduces the attack surface by ensuring only trusted administrators have the privileges required to trigger this code path until a permanent fix is deployed.