CVE-2026-77075 in n8n
Summary
by MITRE • 08/20/2026
n8n before 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 contain an expression injection vulnerability in resource-locator field link preview rendering. The editor spliced the field's stored value directly into the node type's URL template without checking for expression syntax. An authenticated member can store a malicious value so that when another user opens the affected node in the editor, the injected expression is evaluated as JavaScript in the victim's authenticated session (cross-user script execution).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in n8n versions prior to 1.123.69, 2.x before 2.33.4, and 2.34.x before 2.34.1 represents a critical server-side expression injection flaw within the resource-locator field's link preview rendering mechanism. This security defect arises from an improper neutralization of special elements during data processing, specifically where the application fails to validate or sanitize user-supplied input before incorporating it into executable code contexts. The core technical failure lies in how the editor handles stored values for specific fields; rather than treating these inputs as static strings, the system directly splices them into a node type's URL template without performing any checks for expression syntax indicators such as double curly braces or other delimiters used by n8n to denote executable expressions. This lack of input validation allows an attacker to embed malicious code within what appears to be benign data fields, effectively bypassing standard security controls that rely on context-aware escaping.
From a technical perspective, this vulnerability is classified under CWE-95 as Improper Neutralization of Special Elements used in an Command, specifically involving expression injection rather than traditional command execution. The attack vector relies heavily on the interaction between different users within the n8n environment. An authenticated member with permission to create or edit workflows can store a specially crafted value containing malicious JavaScript code disguised as part of a URL preview string. When another user subsequently opens this workflow in the editor, the application attempts to render the link preview by evaluating the stored field content. Because the system interprets the injected syntax as valid n8n expressions, it executes the embedded JavaScript within the context of the victim's authenticated session. This mechanism transforms what might seem like a simple data entry error into a potent cross-user script execution vulnerability, allowing for arbitrary code execution on behalf of the user viewing the workflow.
The operational impact of this flaw is severe due to its potential for cross-site scripting and account takeover scenarios. Since the malicious expression executes in the victim's browser with their active authentication tokens and session cookies, an attacker can manipulate the victim's actions without their knowledge or consent. This capability enables a range of hostile activities including but not limited to stealing sensitive workflow data exfiltrating credentials by sending them to external servers, modifying existing workflows to introduce persistent backdoors, or performing unauthorized API calls using the victim's permissions. The vulnerability is particularly dangerous because it does not require direct interaction with the vulnerable component at the moment of exploitation; instead, it relies on social engineering tactics where an attacker tricks a privileged user into opening a maliciously crafted workflow node. This aligns closely with ATT&CK technique T1059 Command and Scripting Interpreter, specifically JavaScript execution, as well as T1204 User Execution if viewed through the lens of requiring user interaction to trigger the payload evaluation during rendering.
Mitigation strategies for this vulnerability must prioritize immediate software updates alongside robust input validation practices. The most effective remediation is upgrading n8n to version 1.123.69 or later, or specifically updating major versions to 2.33.4 and 2.34.1 respectively, as these releases contain patches that properly sanitize expression syntax within the resource-locator field before rendering. For organizations unable to patch immediately due to operational constraints, implementing a Web Application Firewall rule set designed to detect and block n8n-specific expression delimiters in input fields can provide temporary protection against exploitation attempts. Additionally, enforcing strict Content Security Policy headers can help mitigate the impact of any successful script execution by restricting inline JavaScript evaluation and limiting data exfiltration channels. Long-term architectural improvements should include adopting a whitelist approach for allowed characters in preview fields or ensuring that all user inputs are treated as plain text unless explicitly validated against safe expression patterns, thereby eliminating the possibility of unintended code interpretation during UI rendering processes.