n8n is an open source workflow automation platform.

CVE-2026-33696 is a prototype pollution flaw in n8n's GSuiteAdmin and XML node parameter handling. An authenticated user with member-role permissions — the *default* for any registered n8n user — can supply crafted keys (__proto__, constructor, prototype) in node configuration parameters. This pollutes Object.prototype in the server-side Node.js process. Combined with gadget chains available in n8n's dependency tree, this escalates to full remote code execution on the n8n host. Affected versions span n8n < 1.123.27 on the 1.x branch, >= 2.0.0-rc.0 and < 2.13.3 on the 2.x stable branch, and 2.14.0 on the 2.x beta. Fixes landed in 1.123.27, 2.13.3, and 2.14.1.

The vendor assigned CVSS 4.0 of 9.4 (Critical) and CVSS 3.1 of 8.8 (High). The 8.8 is *directionally correct* but slightly generous given two friction factors: no public proof-of-concept exists yet and exploitation requires authenticated access. However, the 'authenticated' bar is thinner than it sounds — n8n's default member role is sufficient, and many self-hosted instances allow open registration. With 100,000+ n8n instances exposed on the internet per Censys scans, the reachable population is large. noisgate downgrades slightly to 7.8 HIGH: auth and no-PoC provide real but modest friction, while n8n's role as a credential-laden automation hub keeps the floor firmly at HIGH.

Why this verdict

• Authentication friction is real but thin. CVSS PR:L is accurate, but n8n's member role — the minimum needed — is the *default* for any registered user. Self-hosted instances with open registration reduce this to near-zero friction. This provides a modest downward adjustment (~0.5 points) from the vendor's 8.8.
• No public PoC dampens immediate risk. Without published exploit code, mass exploitation requires independent gadget-chain research. The sister CVE-2026-33660 AlaSQL writeup lowers this bar for motivated attackers but has not yet been adapted publicly. Another ~0.5-point downward adjustment.
• Role multiplier: n8n is a credential store and automation hub. By definition, n8n instances hold OAuth tokens, API keys, database credentials, and webhook secrets for every connected service. RCE on the n8n host means the attacker inherits all stored credentials and can pivot to downstream systems (databases, SaaS platforms, cloud accounts). This is functionally equivalent to compromising a CI/CD server. The blast radius is not 'one application' — it is 'every system n8n integrates with.' This floors the verdict at HIGH regardless of auth friction.
• Role multiplier (high-value role check): n8n occupies the CI/CD + automation category. ≥80% of n8n installs *are* the automation hub — the component is its role. Chain success in this role yields credential theft across all integrations → supply-chain-scale blast radius. Floor = HIGH.
• 100K+ internet-exposed instances. The reachable attack surface is massive. Even requiring auth, the sheer volume of exposed instances — 58% running vulnerable versions — means the exposure population is substantial.

Why not higher?

Upgrading to CRITICAL would require either active exploitation (not observed), a public weaponized PoC (none exists), or unauthenticated access (auth is required). The authentication barrier, while thin, is nonzero and prevents mass automated exploitation. The CVSS 4.0 score of 9.4 with changed scope is aggressive; real-world conditions do not yet support CRITICAL urgency.

Why not lower?

Dropping to MEDIUM would ignore n8n's canonical role as an automation and credential hub. RCE on an n8n instance is not an isolated application compromise — it is a supply-chain pivot point granting access to every connected service's credentials. The 100K+ exposed instance population and the existence of sister CVE gadget-chain research (lowering the PoC development barrier) prevent any further downgrade.

1. Disable the XML node via NODES_EXCLUDE — Set NODES_EXCLUDE=n8n-nodes-base.xml in your n8n environment configuration to remove the XML node from the available node palette. This eliminates one of the two attack vectors. Deploy within 30 days per noisgate mitigation SLA for HIGH.
2. Restrict workflow permissions to trusted users only — Remove member-role workflow creation/editing permissions. Limit workflow authoring to a named set of trusted operators. This directly blocks the authenticated attack path. Deploy within 30 days.
3. Disable open self-registration — Set N8N_USER_MANAGEMENT_DISABLED=true or configure SSO/SAML to control who can register. Open registration is the primary reason the auth barrier is thin. Deploy within 30 days.
4. Place n8n behind VPN or IP-allowlisted reverse proxy — Remove direct internet exposure. This eliminates remote attacker access entirely. If n8n must be accessible externally, enforce MFA via an identity-aware proxy (e.g., Cloudflare Access, Tailscale). Deploy within 30 days.
5. Run n8n in a container with minimal privileges — Use a read-only root filesystem, drop all capabilities, and run as a non-root user. This limits post-exploitation blast radius even if RCE is achieved. Secrets should be injected via mounted volumes or secret managers, not environment variables.

Run this script on each n8n host (or against the n8n API endpoint from an auditor workstation). It checks the running n8n version against the patched thresholds. No special privileges required — just curl and network access to the n8n instance. Example: bash check_cve_2026_33696.sh https://n8n.internal.corp:5678

#!/usr/bin/env bash
# check_cve_2026_33696.sh — Detect CVE-2026-33696 in n8n
# Usage: bash check_cve_2026_33696.sh <n8n_base_url>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

if [ $# -lt 1 ]; then
  echo "Usage: $0 <n8n_base_url>"
  echo "Example: $0 https://n8n.example.com:5678"
  exit 2
fi

BASE_URL="${1%/}"

# Attempt to retrieve version from n8n REST API
VERSION=$(curl -sk --max-time 10 "${BASE_URL}/rest/settings" 2>/dev/null | grep -oP '"versionCli"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+' || true)

if [ -z "$VERSION" ]; then
  # Fallback: try the healthcheck or version endpoint
  VERSION=$(curl -sk --max-time 10 "${BASE_URL}/healthz" -D- 2>/dev/null | grep -oiP 'n8n/\K[0-9]+\.[0-9]+\.[0-9]+' || true)
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — could not determine n8n version at ${BASE_URL}"
  exit 2
fi

echo "Detected n8n version: ${VERSION}"

# Parse major.minor.patch
IFS='.' read -r MAJOR MINOR PATCH <<< "$VERSION"

vulnerable=false

if [ "$MAJOR" -eq 1 ]; then
  # 1.x branch: vulnerable if < 1.123.27
  if [ "$MINOR" -lt 123 ]; then
    vulnerable=true
  elif [ "$MINOR" -eq 123 ] && [ "$PATCH" -lt 27 ]; then
    vulnerable=true
  fi
elif [ "$MAJOR" -eq 2 ]; then
  # 2.x branch: vulnerable if < 2.13.3 OR == 2.14.0
  if [ "$MINOR" -lt 13 ]; then
    vulnerable=true
  elif [ "$MINOR" -eq 13 ] && [ "$PATCH" -lt 3 ]; then
    vulnerable=true
  elif [ "$MINOR" -eq 14 ] && [ "$PATCH" -eq 0 ]; then
    vulnerable=true
  fi
fi

if [ "$vulnerable" = true ]; then
  echo "VULNERABLE — n8n ${VERSION} is affected by CVE-2026-33696"
  echo "Upgrade to 1.123.27 (1.x) or 2.13.3 / 2.14.1 (2.x)"
  exit 1
else
  echo "PATCHED — n8n ${VERSION} is not affected by CVE-2026-33696"
  exit 0
fi

Sources

1. GitHub Security Advisory GHSA-mxrg-77hm-89hv
2. Geordie Technical Advisory — n8n March 2026 CVEs
3. Censys Advisory — n8n Exposure Data
4. SentinelOne Vulnerability Database — CVE-2026-33696
5. GBHackers — 103K+ n8n Instances Exposed
6. AnonHaven — n8n RCE via AlaSQL and Prototype Pollution (CVE-2026-33660)
7. CCB Belgium — Critical n8n Vulnerabilities Advisory