CVE-2026-85172 in n8n
Summary
by MITRE • 09/03/2026
n8n versions before 2.34.1 contain a server-side request forgery vulnerability in the legacy request helper function exposed to Code and Function nodes. The validation logic checks the uri property for SSRF safety while the underlying HTTP client uses the url property when both are present, allowing attackers to bypass validation by supplying a safe uri alongside a malicious url to access internal addresses.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in n8n versions prior to 2.34.1 represents a critical server-side request forgery flaw rooted in an inconsistency within the application's input validation logic. This specific weakness is exposed through the legacy request helper function, which serves as the underlying mechanism for HTTP interactions initiated by Code and Function nodes. These nodes are central to n8n’s workflow automation capabilities, allowing users to execute custom JavaScript or TypeScript code that can trigger external network requests. The security failure occurs because the validation layer operates on a different property than the actual transport layer used by the HTTP client library. Specifically, the application performs safety checks exclusively against the uri property of the request configuration object. However, when both the uri and url properties are present in the input payload, the underlying HTTP client prioritizes and utilizes the url property for establishing the connection. This discrepancy creates a bypass vector where an attacker can supply a benign value in the validated uri field to satisfy the security checks while simultaneously providing a malicious target address in the unchecked url field.
From a technical perspective, this flaw is classified under CWE-918 Server-Side Request Forgery (SSRF). The core issue lies in the lack of canonicalization or strict enforcement of which property dictates the destination endpoint during validation versus execution. In many web frameworks and HTTP libraries, uri and url are often treated as synonyms or aliases for one another, leading developers to assume that validating one validates both. However, certain implementations maintain distinct internal states for these fields, particularly when dealing with relative path resolution or legacy API compatibility layers. By exploiting this divergence, an attacker can effectively trick the server into making requests to arbitrary destinations on behalf of the n8n instance. This is not merely a logic error but a fundamental failure in input sanitization where the defense mechanism does not align with the actual code execution path.
The operational impact of this vulnerability is significant for organizations relying on n8n for integrating internal services, databases, or cloud resources. An authenticated attacker who has access to Code or Function nodes can leverage this SSRF flaw to probe and interact with internal network infrastructure that is otherwise inaccessible from the public internet. This includes accessing local metadata endpoints such as AWS EC2 instance metadata service (IMDSv1), Kubernetes API servers, Docker daemon sockets, or internal microservices running on localhost or private subnets. The ability to reach these internal resources can lead to further compromise scenarios, including credential theft via cloud provider metadata APIs, unauthorized data exfiltration from internal databases, and potential remote code execution if the targeted internal services have their own vulnerabilities that allow command injection based on SSRF interactions.
This vulnerability aligns with MITRE ATT&CK technique T1598, specifically Phishing for Information within a Multi-tenant Environment or more broadly under T1046 Network Service Discovery when used to map internal networks. It also relates to T1071 Application Layer Protocol if the attacker uses standard HTTP methods to exfiltrate data back to an external controller. The severity is heightened by the fact that Code and Function nodes are often granted elevated privileges within workflow definitions, assuming they run with sufficient permissions to interact with various integrations. Consequently, this flaw allows a lower-privileged user or a compromised workflow step to escalate their impact significantly by pivoting through the n8n server into protected network segments.
To mitigate this risk, organizations must immediately upgrade n8n to version 2.34.1 or later, where the validation logic has been corrected to ensure that both uri and url properties are subject to consistent security checks. Until an upgrade is feasible, administrators should restrict access to Code and Function nodes to only those users who absolutely require such capabilities for workflow automation. Implementing strict network segmentation can also help limit the blast radius; ensuring that n8n instances cannot reach sensitive internal services via direct IP addresses or localhost connections reduces the utility of any SSRF exploit. Additionally, deploying a Web Application Firewall with rules designed to detect and block outbound requests to known malicious IPs or non-whitelisted domains can provide an additional layer of defense against exploitation attempts targeting this specific vulnerability pattern.