CVE-2026-25051: N8n Workflow Automation XSS Vulnerability

CVE-2026-25051 Overview

A Cross-Site Scripting (XSS) vulnerability has been identified in n8n, the popular open source workflow automation platform. This vulnerability exists in the handling of webhook responses and related HTTP endpoints, where the Content Security Policy (CSP) sandbox protection intended to isolate HTML responses may not be applied correctly under certain conditions.

An authenticated user with permission to create or modify workflows could exploit this flaw to execute malicious scripts with same-origin privileges when other users interact with the crafted workflow. The vulnerability stems from improper input validation in the content-type header parsing, allowing attackers to bypass security controls designed to prevent script execution.

Critical Impact

This vulnerability could lead to session hijacking and complete account takeover, compromising user credentials and potentially granting attackers full control over n8n workflow automation systems.

Affected Products

• n8n workflow automation platform versions prior to 1.123.2
• n8n for Node.js (all vulnerable versions)
• Self-hosted and cloud instances running unpatched versions

Discovery Timeline

• 2026-02-04 - CVE-2026-25051 published to NVD
• 2026-02-05 - Last updated in NVD database

Technical Details for CVE-2026-25051

Vulnerability Analysis

This Cross-Site Scripting (XSS) vulnerability occurs due to improper validation of the Content-Type header in n8n's HTML sandbox functionality. The isHtmlRenderedContentType function in packages/core/src/html-sandbox.ts failed to properly sanitize the content-type string before processing, allowing attackers to craft malicious inputs that bypass CSP sandbox protections.

When webhook responses are processed, the application checks whether content should be rendered as HTML. However, the original implementation did not account for leading whitespace in the content-type header. An attacker could prepend whitespace characters to the content-type value, causing the security check to fail and allowing HTML content to be rendered without proper CSP sandbox isolation.

This oversight enables stored XSS attacks where malicious JavaScript can execute in the context of other authenticated users who interact with the compromised workflow, inheriting their session privileges.

Root Cause

The root cause lies in the isHtmlRenderedContentType function's failure to trim whitespace from the content-type header before performing the lowercase comparison. The original code directly called toLowerCase() on the content-type string without first removing leading or trailing whitespace characters. This seemingly minor oversight allowed attackers to craft content-type headers with leading spaces (e.g., " text/html") that would not match the expected patterns, bypassing the HTML sandbox protection mechanism entirely.

Attack Vector

The attack requires network access and an authenticated user account with workflow creation or modification permissions. The attacker crafts a malicious workflow containing a webhook node configured to return HTML content with a specially formatted content-type header. When another authenticated user interacts with this workflow or views its output, the malicious JavaScript executes with same-origin privileges, enabling session token theft and subsequent account takeover.

// Vulnerable code - packages/core/src/html-sandbox.ts
// The original implementation did not trim whitespace before comparison
export const isHtmlRenderedContentType = (contentType: string) => {
	const contentTypeLower = contentType.toLowerCase();
	// Leading whitespace in contentType would bypass this check
	return (
		// The content-type can also contain a charset, e.g. "text/html; charset=utf-8"

Source: GitHub Commit Change

// Fixed code - packages/core/src/html-sandbox.ts
// The patch adds .trim() to properly sanitize the content-type header
export const isHtmlRenderedContentType = (contentType: string) => {
	const contentTypeLower = contentType.trim().toLowerCase();
	// Now properly handles whitespace-prefixed content-type headers
	return (
		// The content-type can also contain a charset, e.g. "text/html; charset=utf-8"

Source: GitHub Commit Update

Detection Methods for CVE-2026-25051

Indicators of Compromise

• Unusual webhook responses containing JavaScript payloads with whitespace-prefixed content-type headers
• Workflow modifications by users who don't typically edit automation configurations
• Unexpected session activity or authentication tokens being used from unfamiliar IP addresses
• Browser console errors indicating CSP violations that were subsequently bypassed

Detection Strategies

• Monitor n8n audit logs for workflow modifications that include webhook nodes with custom response headers
• Implement network-level inspection for HTTP responses containing content-type headers with leading whitespace
• Deploy web application firewall (WAF) rules to detect XSS payload patterns in webhook configurations
• Review user activity logs for signs of session hijacking or unauthorized account access

Monitoring Recommendations

• Enable comprehensive logging for all workflow creation and modification events
• Set up alerts for unusual authentication patterns that may indicate session token theft
• Monitor for bulk data exports or permission changes that could follow account compromise
• Implement anomaly detection for webhook response sizes and content patterns

How to Mitigate CVE-2026-25051

Immediate Actions Required

• Upgrade n8n to version 1.123.2 or later immediately
• Audit all existing workflows for suspicious webhook configurations
• Review recent workflow modifications and validate their legitimacy
• Force session invalidation for all users and require re-authentication
• Enable additional authentication factors where available

Patch Information

n8n has released version 1.123.2 which addresses this vulnerability by adding proper input sanitization to the content-type header parsing. The fix adds a .trim() call before the .toLowerCase() operation in the isHtmlRenderedContentType function, ensuring that whitespace-prefixed content-type headers are properly normalized before security checks are applied.

For detailed patch information, review the GitHub Security Advisory GHSA-825q-w924-xhgx.

Workarounds

• Restrict workflow creation and modification permissions to trusted administrators only until patching is complete
• Implement network-level filtering to block webhook responses with suspicious content-type headers
• Deploy a reverse proxy with strict Content Security Policy headers as an additional defense layer
• Temporarily disable webhook functionality if not business-critical until the patch can be applied

# Upgrade n8n to patched version
npm update n8n@1.123.2

# Or using Docker
docker pull n8nio/n8n:1.123.2
docker-compose down && docker-compose up -d

# Verify installed version
n8n --version