n8n: Same-Origin XSS in Respond to Webhook Node

Vulnerability

An authenticated n8n user with workflow edit access can configure a Respond to Webhook node to serve binary content with an attacker-controlled Content-Type header. The binary response path bypasses the central Content-Security-Policy sandbox header, enabling a public webhook to execute arbitrary JavaScript in the n8n origin.[1][2] The vulnerability affects n8n versions prior to 1.123.55, 2.25.7, and 2.26.2.[1]

Exploitation

An attacker must have valid credentials for an n8n account with workflow creation or editing privileges. The attacker then configures a Respond to Webhook node to serve binary content and sets the Content-Type to a value that allows JavaScript execution (e.g., text/html). When another authenticated user visits the public webhook URL, the browser loads the response and executes the attacker-controlled JavaScript in the context of the n8n origin, bypassing the CSP sandbox.[1][2]

Impact

Successful exploitation allows an attacker to execute arbitrary JavaScript in the n8n origin when a victim views the webhook. The attacker gains access to the victim's active n8n session, enabling actions such as viewing, modifying, or exporting workflows, and potentially compromising additional sensitive data accessible through the victim's account.[1][2]

Mitigation

The issue is fixed in n8n versions 1.123.55, 2.25.7, and 2.26.2 (released 2026-06-16). Users should upgrade promptly. If immediate upgrade is not possible, administrators can limit workflow creation and editing permissions to fully trusted users and disable the Respond to Webhook node by adding n8n-nodes-base.respondToWebhook to the NODES_EXCLUDE environment variable. These workarounds reduce but do not eliminate the risk.[1][2]