CVE-2026-85170 in n8n
Summary
by MITRE • 09/03/2026
n8n versions before 1.123.73, 2.35.4, and 2.36.2 pass message content in the Gmail (v1) and Brevo nodes to the mail composer without verifying it is a string. An authenticated user able to run a workflow can supply an expression that resolves to an object carrying a path or href property, causing the composer to read a local file accessible to the n8n process or fetch an internal URL (SSRF) and attach the result to the outgoing message.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in n8n versions prior to 1.123.73, 2.35.4, and 2.36.2 represents a critical server-side request forgery (SSRF) and local file inclusion flaw embedded within the Gmail v1 and Brevo integration nodes. This security defect arises from insufficient input validation regarding message content passed to the mail composer component. Specifically, the application fails to verify that incoming data structures are strictly strings before processing them for email composition. In a typical workflow execution scenario, an authenticated user who possesses the permission to create or execute workflows can exploit this lack of type checking by injecting complex expressions rather than simple text values.
When such an expression is evaluated, it may resolve into an object structure containing specific properties such as path or href. The mail composer, designed primarily to handle string-based message bodies and attachments, does not adequately sanitize these objects. Instead of rejecting the malformed input, the underlying logic interprets the presence of a path property as an instruction to read local files accessible by the n8n process user account. Alternatively, if an href property is present, the system initiates an HTTP request to the specified URL. This behavior effectively transforms the email sending functionality into a vector for SSRF attacks or unauthorized file reads, depending on how the payload is constructed and what resources are exposed to the application runtime environment.
The operational impact of this vulnerability is severe due to its potential for data exfiltration and internal network reconnaissance. An attacker with authenticated access can leverage this flaw to read sensitive configuration files, source code, or credentials stored within the server's filesystem if they align with the permissions of the n8n process. Furthermore, by directing requests toward internal IP addresses or localhost services that are not exposed to the public internet, an adversary can map out the internal network topology and interact with backend services such as databases, admin panels, or other microservices running on the same host or within the private subnet. This capability bypasses traditional perimeter defenses since the traffic originates from a trusted application process.
From a classification perspective, this vulnerability aligns closely with CWE-918 Server-Side Request Forgery (SSRF), as it allows an attacker to manipulate server-side functionality to make requests on their behalf. It also relates to CWE-20 Improper Input Validation, specifically the failure to enforce type constraints and sanitize complex data structures before processing. In terms of offensive security frameworks, this exploit maps to ATT&CK technique T1598 Phishing for Information, as it facilitates the creation of emails containing maliciously sourced content or stolen data, and potentially T1071 Application Layer Protocol if used to exfiltrate data via email channels.
Mitigation strategies must prioritize immediate version upgrades to n8n 1.123.73, 2.35.4, or later releases where this input validation logic has been corrected. Until an upgrade is feasible, organizations should restrict workflow execution permissions strictly to trusted administrators and isolate the n8n instance within a restricted network segment with limited outbound connectivity. Implementing strict egress filtering rules can also mitigate SSRF risks by blocking requests to private IP ranges or localhost addresses from the application server. Additionally, running the n8n process under a dedicated user account with minimal filesystem permissions reduces the impact of potential local file inclusion attempts.