n8n XML Node prototype pollution patch bypass leading to host RCE

CVE-2026-44791 is an n8n XML node prototype-pollution *patch bypass*: an authenticated user who can create or modify workflows can still poison object prototypes in the XML node and, when chaining other nodes, reach code execution on the n8n host. Authoritative affected ranges published by GitHub/OSV are < 1.123.43, >= 2.0.0-rc.0, < 2.20.7, and >= 2.21.0, < 2.22.1; fixed versions are 1.123.43, 2.20.7, and 2.22.1.

In vacuum-CVSS terms this looks *critical*, and on May 13–14, 2026 GitHub/n8n did publish a CNA-backed 9.4 CVSS v4 score. In real enterprise operations, though, the decisive friction is that exploitation requires *authenticated remote access plus workflow creation/editing rights*—that is already a post-initial-access or privileged-insider condition in most serious deployments. That friction pulls this down from internet-worm panic into HIGH patch priority, while the blast radius stays severe because n8n commonly holds API tokens, database creds, and automation secrets.

Why this verdict

• Down from pure CVSS: the exploit chain starts with authenticated remote access *and* workflow create/modify rights, which implies prior compromise, insider access, or an already-privileged application user—not broad unauthenticated internet reach.
• Still serious: once that gate is passed, impact is host-level RCE plus likely exposure of n8n-stored credentials, API tokens, webhook secrets, and connected-system trust.
• Population narrows materially: many enterprises expose n8n only internally or restrict editor roles to admins/devops; that sharply reduces the fraction of deployments where a random internet attacker can directly exercise this bug.
• Controls should stop the first step: SSO, MFA, conditional access, RBAC, and IdP telemetry are modern controls that should intercept the required account takeover stage before the XML bug is even reachable.
• No field exploitation signal: no KEV listing and no public PoC found. That lowers immediate mass-exploitation pressure versus truly urgent externally reachable pre-auth RCE.

Why not higher?

This is not a pre-auth RCE and not a broad one-packet internet bug. Requiring a valid account plus workflow-edit capability compounds the friction: the attacker is either already inside, has already stolen a meaningful identity, or is an insider. That makes it a very dangerous *second-stage* vulnerability, not a universal emergency.

Why not lower?

Once exploited, the blast radius is bigger than a normal authenticated app bug because n8n often sits on a pile of secrets and integrations. Even with the access prerequisite, host compromise plus credential theft can cascade into cloud, SaaS, database, and internal API compromise, so backlog treatment would be irresponsible.

1. Restrict workflow editing now — Limit workflow creation and modification rights to fully trusted admins/operators only, and complete that access review within the HIGH noisgate mitigation window of 30 days. This directly removes the most important prerequisite in the exploit chain.
2. Disable the XML node where feasible — Set NODES_EXCLUDE=n8n-nodes-base.xml on affected self-hosted instances that do not need the XML node, and deploy that mitigation within 30 days if patching cannot happen first. This is the vendor-published short-term control and blocks the vulnerable feature path.
3. Harden the n8n runtime identity — Run n8n under a low-privilege OS account or tightly confined container profile, and finish that containment work within 30 days. It will not stop exploitation, but it reduces the value of a successful RCE and limits secret and filesystem reach.
4. Monitor for workflow and process abuse — Add detections for new or modified workflows using the XML node and for suspicious child processes or outbound connections from the n8n service account within 30 days. That gives you a realistic chance to catch post-auth exploitation and follow-on credential theft.
5. Scope and rotate sensitive credentials selectively — If your n8n instance is internet-reachable or has a broad editor population, identify high-value stored credentials and begin selective rotation within 30 days where business impact allows. This contains the most likely post-exploitation payoff path.

Run this on the target n8n host or container host. Invoke it as bash check-cve-2026-44791.sh for auto-detect, or pass an explicit version like bash check-cve-2026-44791.sh 2.20.6; no root is required unless you need elevated rights to inspect Docker containers.

#!/usr/bin/env bash
# check-cve-2026-44791.sh
# Detect whether a local n8n installation version falls into the vulnerable ranges for CVE-2026-44791.
# Outputs exactly one of: VULNERABLE, PATCHED, UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

input_version="${1:-}"

auto_detect_version() {
  local v=""

  # 1) Direct binary
  if command -v n8n >/dev/null 2>&1; then
    v="$(n8n --version 2>/dev/null | head -n1 | tr -d '\r' | sed 's/^v//')"
    if [ -n "$v" ]; then
      echo "$v"
      return 0
    fi
  fi

  # 2) Common package.json locations
  for f in \
    /usr/local/lib/node_modules/n8n/package.json \
    /opt/n8n/package.json \
    /app/package.json \
    /usr/src/app/package.json
  do
    if [ -f "$f" ]; then
      v="$(grep -m1 '"version"' "$f" 2>/dev/null | sed -E 's/.*"version"[[:space:]]*:[[:space:]]*"([^"]+)".*/\1/' | sed 's/^v//')"
      if [ -n "$v" ]; then
        echo "$v"
        return 0
      fi
    fi
  done

  # 3) Docker container image tags / exec
  if command -v docker >/dev/null 2>&1; then
    local cid
    cid="$(docker ps --format '{{.ID}} {{.Image}} {{.Names}}' 2>/dev/null | awk '/n8n/ {print $1; exit}')"
    if [ -n "$cid" ]; then
      v="$(docker exec "$cid" n8n --version 2>/dev/null | head -n1 | tr -d '\r' | sed 's/^v//')"
      if [ -n "$v" ]; then
        echo "$v"
        return 0
      fi
      v="$(docker inspect "$cid" --format '{{.Config.Image}}' 2>/dev/null | sed -n 's/.*:\([^:@]*\)$/\1/p' | sed 's/^v//')"
      if [ -n "$v" ]; then
        echo "$v"
        return 0
      fi
    fi
  fi

  return 1
}

normalize_version() {
  echo "$1" | tr -d '[:space:]' | sed 's/^v//'
}

version_ge() {
  # returns 0 if $1 >= $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

version_lt() {
  # returns 0 if $1 < $2
  [ "$1" != "$2" ] && [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]
}

version_in_range() {
  # inclusive lower bound, exclusive upper bound
  local v="$1"
  local low="$2"
  local high="$3"
  version_ge "$v" "$low" && version_lt "$v" "$high"
}

is_vulnerable() {
  local v="$1"

  # Authoritative vulnerable ranges:
  #   < 1.123.43
  #   >= 2.0.0-rc.0, < 2.20.7
  #   >= 2.21.0, < 2.22.1

  if version_lt "$v" "1.123.43"; then
    return 0
  fi

  if version_in_range "$v" "2.0.0-rc.0" "2.20.7"; then
    return 0
  fi

  if version_in_range "$v" "2.21.0" "2.22.1"; then
    return 0
  fi

  return 1
}

main() {
  local v=""

  if [ -n "$input_version" ]; then
    v="$(normalize_version "$input_version")"
  else
    if ! v="$(auto_detect_version)"; then
      echo "UNKNOWN"
      exit 2
    fi
    v="$(normalize_version "$v")"
  fi

  if ! echo "$v" | grep -Eq '^[0-9]+(\.[0-9A-Za-z-]+)+$'; then
    echo "UNKNOWN"
    exit 2
  fi

  if is_vulnerable "$v"; then
    echo "VULNERABLE"
    exit 1
  else
    echo "PATCHED"
    exit 0
  fi
}

main

Sources

1. n8n GitHub Security Advisory GHSA-wrwr-h859-xh2r
2. GitHub Advisory Database GHSA-wrwr-h859-xh2r / CVE-2026-44791
3. OSV entry for GHSA-wrwr-h859-xh2r
4. Previous advisory GHSA-hqr4-h3xv-9m3r
5. Snyk vulnerability record for CVE-2026-44791
6. CISA Known Exploited Vulnerabilities Catalog
7. Black Kite exposure and context writeup
8. Cybersecurity Help vulnerability record