CVE-2026-25051: 
NixOS vulnerability analysis and mitigation

CVE-2026-25051 is a stored Cross-Site Scripting (XSS) vulnerability in n8n, an open-source workflow automation platform, caused by improper enforcement of Content Security Policy (CSP) sandbox protections on webhook responses and related HTTP endpoints. It affects all n8n versions prior to 1.122.5 and versions 1.123.0 through 1.123.1 (i.e., < 1.122.5 and >= 1.123.0, < 1.123.2). The vulnerability was disclosed on February 4, 2026, and credited to researcher weblover12. It carries a CVSS v4.0 base score of 8.5 (High) and a CVSS v3.1 base score of 5.4 (Medium) (Github Advisory, n8n Security Advisory).

The root cause (CWE-79) lies in the isHtmlRenderedContentType function within packages/core/src/html-sandbox.ts, which determines whether a webhook response should be served with a CSP sandbox header. The function failed to call .trim() before .toLowerCase() on the Content-Type header value, meaning a response with a leading space in the content type (e.g., " text/html") would bypass the HTML detection logic and be served without the CSP sandbox — allowing the HTML to render with full same-origin privileges rather than in an isolated sandbox (n8n Security Advisory, Patch Commit). An authenticated attacker with workflow creation or modification permissions can craft a workflow whose webhook response returns HTML with embedded malicious JavaScript and a subtly malformed Content-Type header, causing the CSP sandbox to be skipped. Exploitation requires another user to interact with the crafted workflow endpoint.

Successful exploitation allows an authenticated attacker to inject persistent malicious scripts that execute with same-origin privileges in the browsers of other users who interact with the crafted workflow. The primary consequences are session hijacking and full account takeover, as the scripts can steal session tokens or perform authenticated actions on behalf of victims. Confidentiality and integrity of user accounts and session data are both at high risk; availability is not directly impacted (Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.016% (4th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires low-privilege authenticated access and passive user interaction, limiting opportunistic mass exploitation but making it relevant in multi-tenant or shared n8n deployments.

1. Gain authenticated access: Obtain or register an account on the target n8n instance with at least workflow creation or modification permissions.
2. Create a malicious workflow: Design a workflow that includes an HTTP webhook trigger node configured to return an HTML response containing a malicious JavaScript payload (e.g., a script that exfiltrates document.cookie or session tokens to an attacker-controlled server).
3. Craft the Content-Type bypass: Configure the webhook response to return a Content-Type header with a leading space (e.g., " text/html" or " text/html; charset=utf-8"). This causes the isHtmlRenderedContentType check to fail to recognize the response as HTML, skipping the CSP sandbox header injection.
4. Distribute the workflow link: Share the webhook URL with target users (e.g., via phishing, internal chat, or embedding in a shared dashboard), or wait for other users to interact with the workflow in a shared environment.
5. Harvest session data: When a victim user's browser loads the webhook response, the malicious script executes with same-origin privileges, enabling the attacker to steal session cookies, perform authenticated API calls, or take over the victim's account (n8n Security Advisory, Patch Commit).

• Network: Outbound HTTP requests from users' browsers to unexpected external domains shortly after accessing n8n webhook URLs; unusual POST requests to attacker-controlled endpoints containing encoded session tokens or cookies.
• Logs: n8n access logs showing requests to webhook endpoints returning Content-Type headers with leading/trailing whitespace (e.g., " text/html"); repeated access to the same webhook URL by multiple distinct user accounts.
• Application Behavior: Webhook responses served without the expected Content-Security-Policy: sandbox header for HTML content types; unexpected JavaScript execution or redirects when accessing workflow webhook URLs.
• User Activity: Reports of unauthorized actions performed under legitimate user accounts; unexpected session invalidations or password changes not initiated by the account owner.

The vulnerability is patched in n8n versions 1.122.5 and 1.123.2; all users should upgrade to one of these versions or later immediately (Github Advisory). The fix applies .trim() before .toLowerCase() in the isHtmlRenderedContentType function, ensuring whitespace-padded Content-Type headers are correctly identified and sandboxed (Patch Commit). If immediate upgrade is not possible, administrators should restrict workflow creation and modification permissions to fully trusted users only, avoid executing untrusted workflows, and audit existing workflows — especially those receiving data via webhooks, forms, or MCP servers — for potentially malicious content.

The vulnerability was covered by CSO Online and The Hacker News as part of broader reporting on multiple n8n security issues disclosed around the same time (CSO Online, The Hacker News). Belgium's Centre for Cybersecurity (CCB) issued an advisory warning about multiple critical vulnerabilities in n8n, including this issue (CCB Advisory). Checkmarx published a technical write-up examining CSP sandbox bypass techniques in n8n, providing additional context on the vulnerability class (Checkmarx). Community reaction was moderate, with the vulnerability noted as part of a cluster of n8n security issues rather than as a standalone critical finding.