Same Origin, Same Tricks: Bypassing n8n’s CSP Sandbox (CVE-2026-27578)

Overview of CVE-2026-27578: Stored XSS in open-source workflow platform n8n

Checkmarx Zero has discovered a stored cross-site scripting (XSS) vulnerability (CVE-2026-27578) in n8n, the popular open-source workflow automation platform. The vulnerability allows an authenticated attacker to bypass n8n’s existing Content Security Policy (CSP) sandbox protections by abusing the Webhook Response functionality with content types not on the denylist (e.g., image/svg+xml).

Impact

Successful exploitation enables arbitrary JavaScript execution in the context of a victim’s authenticated n8n session. This can lead to session hijacking, credential theft, and full account takeover.

Affected Users

Users running n8n versions:

• < 1.123.22
• >= 2.0.0 < 2.9.3
• >= 2.10.0 < 2.10.1

The issue is tracked as CVE-2026-27578(Stored XSS via Various Nodes, CVSS=8.5) and was addressed in versions:

• 2.10.1
• 2.9.3
• 1.123.22

Remediation

The issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability.

Get e-mail updates about new Checkmarx Zero research

Subscribe to our newsletter

Never Miss Checkmarx
Zero Research Updates. Subscribe today!

By submitting my information to Checkmarx, I hereby consent to the terms and conditions found in the Checkmarx Privacy Policy and to the processing of my personal data as described therein. By clicking submit above, you consent to allow Checkmarx to store and process the personal information submitted above to provide you the content requested.

n8n CVE-2026-27578 Vulnerability Technical Drilldown

Introduction

n8n is an open-source workflow automation platform that has become one of the most widely adopted tools in its category, with over 178K GitHub stars, and a rapidly growing community of self-hosted and cloud users. It enables developers, DevOps engineers, and increasingly non-technical teams to connect APIs, automate business processes, and build internal tooling through a visual, node-based interface.

Its flexibility is a double-edged sword. n8n workflows can receive external HTTP requests via webhooks, execute arbitrary code, interact with databases, and return custom HTTP responses, all configured through the UI. This power makes n8n a compelling target, especially in multi-user or shared environments.

Checkmarx Zero discovered and responsibly disclosed a Cross-Site Scripting (XSS) vulnerability in some versions of n8n via the “Respond to Webhook” node.

n8n’s maintainers had already recognized the risk of XSS via webhook responses and implemented a mitigation in the form of a “CSP Sandbox” control, attempting to isolate untrusted data from the page. However, the vulnerability Checkmarx Zero uncovered in our research allows attackers to bypass that sandbox and conduct an XSS attack anyway.

We explain below how that mitigation was bypassed, and why the previous underlying design choice, a denylist of dangerous content types, leaves the door open to further abuse.

High-Level Flow

n8n’s “Respond to Webhook” node allows a workflow author to define a custom HTTP response, including headers, status code, and body, that is returned to the caller when a webhook is triggered.

The problem arises because this response is served from the n8n application’s own origin. If an attacker can control the response body and Content-Type header, and if the browser interprets that response as renderable content, any embedded scripts will execute with full access to the n8n browser context, including cookies, session storage, and the Document Object Model (DOM).

The attack flow is straightforward:

1. An authenticated attacker creates (or modifies) a workflow containing a Webhook trigger and a “Respond to Webhook” node.
2. The response is configured to return a body containing a malicious SVG with embedded JavaScript, and a Content-Type of image/svg+xml.
3. The attacker waits for the privileged user to access the webhook URL from the tampered workflow, or just shares the webhook URL with a victim (a legitimate n8n user or administrator).
4. When the victim visits the URL in their browser, the SVG is rendered, the JavaScript executes on the n8n origin, and the attacker can exfiltrate session data or perform actions on the victim’s behalf.

The CSP Sandbox

The Content Security Policy (CSP) header is a browser security mechanism that controls how web content behaves and interacts with external resources. The CSP’s sandbox directive places the requested resource into a restricted environment, similar to the sandbox attribute on an <iframe>. This allows the developer to add strict limitations on the page’s capabilities, such as blocking pop-ups, preventing the execution of plugins and scripts, and assigning a unique opaque origin to the content (effectively restricting access to the original origin resources).

In scenarios like this, where n8n needs to prevent webhook-served content from accessing resources on the same origin (where the “Respond to Webhook” node runs), the CSP sandbox directive is the way to go.

The Existing Mitigation and Why It Failed

n8n’s developers were aware of the risk. The codebase includes a function called isHtmlRenderedContentType that checks the Content-Type of a webhook response against a denylist of MIME types known to be rendered as HTML by browsers. When a match is found, n8n adds a CSP sandbox to the response, which should theoretically protect users from malicious content served through the “Respond to Webhook” node.

For example, a response with Content-Type: text/html is correctly intercepted. The CSP sandbox prevents scripts served by the “Respond to Webhook” node from accessing resources, such as cookies, that belong to the user on the same origin.

However, image/svg+xml was not included in this denylist. SVG is a first-class citizen in the browser rendering engine. It is an XML document that is rendered inline as an image, but it supports the full SVG DOM which, critically, can contain <script> elements that execute JavaScript in the context of the document’s origin. By setting the response Content-Type to image/svg+xml and embedding a script payload in the SVG body, the CSP sandbox was bypassed entirely:

The Deeper Problem: Denylist vs. Allowlist

The SVG bypass is a clear and practical vulnerability, but it is symptomatic of a more fundamental design issue: the use of a denylist to identify dangerous content types.

The old mitigation resides in the html-sandbox.ts file.

A denylist approach requires the developers to anticipate every MIME type a browser might render as executable content, now and in the future. This is a losing game. Browser behavior around content types is complex, inconsistent across vendors, and subject to change. Two areas illustrate this risk:

• Content-Type interpretation quirks: Different browsers handle unusual or malformed Content-Type values differently, and some of these discrepancies can be exploited to execute scripts. BlackFan’s content-type research catalogs numerous such cases, including types and payloads that trigger XSS across specific browser versions.
• MIME type sniffing: Browsers may ignore the declared Content-Type header and infer the actual type from the response body. This behavior can cause a response declared as a benign type to be rendered as HTML or script. A detailed treatment of MIME sniffing edge cases is available in Huli’s “Beyond XSS” research.

Any of these edge cases could yield additional bypasses of the denylist. The recommended approach is to replace the denylist with a strict allowlist of known-safe MIME types (for instance, based on MDN’s common MIME types reference and the references mentioned above). All content types not explicitly on the allowlist should be treated as potentially dangerous and served within the CSP sandbox.

An even better solution, though, is to simply add the CSP sandbox header to any webhook response returned by the “Respond to Webhook” node. This is the mitigation chosen by the n8n team, as there are no real benefits in having specific webhook responses without the sandbox.

The function isHtmlRenderedContentType was removed from html-sandbox.ts, and now the header is set in every response, unless protection is explicitly disabled.

Could AI have found the n8n CVE-2026-27578?

The short answer is maybe: it’s possible, but definitely not guaranteed.

As you may know, our team recently conducted a deep dive into zero-day identification using LLMs (Hunting 0-days with Opus 4.6, The Unearned Confidence).

One of the techniques we explored was asking Claude to analyze historical CVE patches to determine whether the fix truly resolved the vulnerability, or quietly introduced a new one.

This Stored XSS was one such example. We provided Claude with a previous CVE, its fix, and some additional context:

• CVE-2026-25051
• The corresponding commit & and full file contents (of those that changed)

We did this a few times with different models and got a bunch of different, inconsistent results.
Here are just two examples (prompts were identical):

Opus 4.6 – First Try

Opus 4.6 – Second Try

Sonnet Analysis

So was AI right? Not really…

Let’s be clear: the pattern in that code sample, a denylist, is something most security professionals would at least have a gut feeling about. Denylists are notoriously difficult to implement correctly in many contexts, especially when combined with the well-known SVG bypass technique for XSS.

Yet when this single file was analyzed by multiple LLMs, the denylist was often not flagged. Even when the same file was analyzed multiple times by the same model, it did not consistently identify the vulnerable pattern. Honestly? We expected it to catch this.

This is another reminder that an autonomous AI agent, operating without a security professional applying critical thinking and domain expertise, is not enough. In some cases, it can even create a false sense of security while real issues remain undetected.

Summary of n8n CVE-2026-27578

A CSP sandbox bypass in n8n’s webhook response handling was found and fixed. The platform’s existing XSS mitigation relied on a denylist of content types deemed capable of rendering HTML. By responding with Content-Types absent from the denylist but capable of executing JavaScript in the browser, an authenticated attacker could run arbitrary scripts on the n8n origin, leading to session hijacking and account takeover.

Beyond the specific SVG vector, this research highlights the inherent fragility of denylist-based content type filtering. Browser MIME sniffing behavior and cross-browser content type interpretation quirks present an open-ended set of potential bypass vectors.

Organizations running affected versions of n8n should upgrade to 2.10.1, 2.9.3, or 1.123.22 immediately.

CVE-2026-27578 Responsible Disclosure Timeline