CVE-2026-77072 in n8n
Summary
by MITRE • 08/20/2026
n8n before 1.123.69, 2.33.4, and 2.34.1 contains a stored cross-site scripting vulnerability in the Form node's completion page. The completion page applied its sandboxing Content-Security-Policy only when respondWith was not set to 'redirect', but responseText was always rendered as raw HTML. An authenticated member could set respondWith to 'redirect' via an expression while keeping responseText populated, causing the completion page to serve unsanitized HTML and script from the n8n origin. Any visitor who submitted the resulting public form would have that script execute same-origin with their session.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in versions of n8n prior to 1.123.69, 2.33.4, and 2.34.1 represents a critical stored cross-site scripting flaw within the Form node's completion page logic. This issue stems from an inconsistent application of security controls regarding Content-Security-Policy headers. Specifically, the system was designed to enforce strict sandboxing by applying restrictive CSP directives only when the respondWith configuration option was not set to redirect. However, a logical error in this conditional branching allowed for a bypass scenario where responseText remained populated with raw HTML content even when the redirect mode was active. This architectural oversight meant that while the security header intended to prevent script execution was suppressed or omitted under specific conditions, the underlying mechanism continued to render user-supplied input as executable code without adequate sanitization.
From an operational perspective, this flaw allows for a sophisticated attack vector involving authenticated users and public-facing forms. An attacker with valid credentials can manipulate the workflow configuration by setting respondWith to redirect via an expression while simultaneously populating responseText with malicious script payloads. Because n8n is often deployed in environments where workflows are shared or used to generate public-facing interfaces, this misconfiguration results in the completion page serving unsanitized HTML and scripts directly from the trusted n8n origin. The severity of this vulnerability is amplified by its stored nature; once an authenticated user configures such a workflow, the malicious payload becomes persistent within the application's state rather than being transient or dependent on immediate interaction with the attacker.
The impact extends to any visitor who submits the resulting public form generated by the compromised workflow. Upon submission, the browser executes the injected scripts in the context of the n8n origin due to same-origin policy rules. This effectively grants the malicious script full access to the application's session cookies, local storage, and DOM elements associated with that domain. Consequently, an attacker can perform actions on behalf of the victim user, steal sensitive authentication tokens, or manipulate data within the n8n instance without requiring further interaction from the target beyond form submission. This scenario aligns closely with CWE-79, which classifies improper neutralization of input during web page generation as a stored cross-site scripting vulnerability, and maps to MITRE ATT&CK techniques related to client-side code injection and session hijacking through trusted domains.
Mitigation for this issue requires an immediate upgrade to n8n version 1.123.69 or later, where the logic governing Content-Security-Policy application has been corrected to ensure consistent enforcement regardless of the respondWith setting. In environments where upgrading is not immediately feasible, administrators should implement strict input validation and output encoding for all fields that contribute to responseText within Form nodes. Additionally, deploying a Web Application Firewall with rules capable of detecting and blocking script injection attempts in form submissions can provide an additional layer of defense. It is also advisable to review existing workflows for any configurations that utilize redirect responses combined with custom HTML content, ensuring that such patterns are either removed or strictly sanitized before deployment to production environments.