n8n is an open source workflow automation platform

CVE-2026-21858 is an improper input validation bug in self-hosted n8n that affects >=1.65.0, <1.121.0; 2.x already contains the fix. The bug sits in form/webhook request handling and only becomes reachable when an instance has an active workflow that includes a Form Submission trigger and a Form Ending node configured to return a binary file. In that setup, an unauthenticated remote caller who can hit the form endpoint can abuse content-type confusion to read server-side files, steal secrets, and in some deployments chain to full host compromise.

The vendor's 10.0 / CRITICAL score is technically defensible for the worst case, but it overstates population-wide urgency. This is not a universal pre-auth RCE against every exposed login page; it is a narrower internet-reachable workflow flaw that requires a specific workflow pattern to already exist. Still, when that pattern is present on an internet-exposed self-hosted node, the blast radius is ugly because n8n commonly centralizes tokens, SaaS creds, CI/CD access, and cloud secrets.

Why this verdict

• Start at vendor 10.0: if you already have the exact vulnerable workflow exposed, the unauthenticated file-read-to-compromise chain is absolutely dangerous.
• Minus 0.8 for exposure narrowing: this is limited to self-hosted >=1.65.0, <1.121.0; cloud and 2.x are already outside the blast zone.
• Minus 0.7 for attacker reachability friction: the attacker needs a reachable form/webhook endpoint, not merely access to the main n8n web UI or an internal host.
• Minus 0.9 for workflow-design dependency: exploitation requires an active workflow with Form Submission and a binary-returning Form Ending; that is a meaningful population reducer in real estates.
• Plus 0.4 for attacker enablement: public write-ups, PoCs, and scanner coverage make validation and weaponization easier than the raw EPSS alone would suggest.
• Plus 0.4 for blast radius: compromise of n8n often means compromise of everything n8n touches—OAuth tokens, databases, CI/CD, SaaS APIs, and AI pipelines.

Why not higher?

Because the vuln is not broadly exploitable against every installed copy. It needs a reachable, vulnerable workflow shape already deployed, which means this is not the same operational class as a product-wide pre-auth RCE on the base login surface. The required attacker path narrows both exposed population and exploit reliability.

Why not lower?

Because when the prerequisite workflow exists, the path is still unauthenticated, internet-viable, and high-impact. Public tooling exists, tens of thousands of exposed instances were observed, and n8n's role as an automation hub turns a single foothold into a multi-system credential and control event.

1. Block public form and webhook routes — At reverse proxies, ingress controllers, and edge firewalls, restrict anonymous access to n8n form/webhook endpoints that do not need to be public. This is the cleanest population reduction control and should be deployed within 30 days for a HIGH verdict, sooner for internet-exposed estates.
2. Inventory vulnerable workflow shapes — Query self-hosted n8n instances for active workflows containing Form Submission plus Form Ending configured with respondWith=returnBinary. This lets you separate theoretical version exposure from actually exploitable business flows and should be completed within 30 days.
3. Isolate n8n from crown-jewel networks — Move n8n hosts/containers into tightly segmented zones with egress filtering to SaaS/API destinations they truly require. This limits post-read secret abuse and lateral movement and should be enforced within 30 days.
4. Harden host and container privileges — Run n8n as a non-root user, minimize mounted secrets, prefer secret managers over .env sprawl, and disable dangerous nodes where operationally possible. This reduces the value of file read and weakens the file-read-to-RCE chain; deploy within 30 days.
5. Alert on child process creation from n8n — Tune EDR/container telemetry for node or the n8n process spawning shells, package managers, curl, wget, or other living-off-the-land tools. This is the best compensating detective control for the later stages of the chain and should be live within 30 days.

Run this on the target self-hosted n8n host or inside the n8n container. Invoke it as bash check_cve_2026_21858.sh /home/node/.n8n/database.sqlite or simply bash check_cve_2026_21858.sh if the default SQLite path is used; it needs read access to the n8n database file and permission to run n8n --version or docker exec if n8n is containerized.

#!/usr/bin/env bash
set -euo pipefail

# check_cve_2026_21858.sh
# Detect likely exposure to CVE-2026-21858 on self-hosted n8n.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN
#   3 = ERROR

DB_PATH="${1:-}"
VERSION=""
CONTAINER=""

print_result() {
  local status="$1"
  echo "$status"
}

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

version_lt() {
  ! version_ge "$1" "$2"
}

find_version() {
  if command -v n8n >/dev/null 2>&1; then
    VERSION="$(n8n --version 2>/dev/null | head -n1 | tr -d '[:space:]' || true)"
    if [ -n "$VERSION" ]; then
      return 0
    fi
  fi

  if command -v docker >/dev/null 2>&1; then
    CONTAINER="$(docker ps --format '{{.ID}} {{.Image}} {{.Names}}' | awk '/n8n/ {print $1; exit}' || true)"
    if [ -n "$CONTAINER" ]; then
      VERSION="$(docker exec "$CONTAINER" n8n --version 2>/dev/null | head -n1 | tr -d '[:space:]' || true)"
      if [ -n "$VERSION" ]; then
        return 0
      fi
    fi
  fi

  if [ -f /usr/local/lib/node_modules/n8n/package.json ] && command -v python3 >/dev/null 2>&1; then
    VERSION="$(python3 - <<'PY'
import json
p='/usr/local/lib/node_modules/n8n/package.json'
try:
    with open(p,'r',encoding='utf-8') as f:
        print(json.load(f).get('version',''))
except Exception:
    print('')
PY
)"
    if [ -n "$VERSION" ]; then
      return 0
    fi
  fi

  return 1
}

find_db() {
  if [ -n "$DB_PATH" ] && [ -f "$DB_PATH" ]; then
    return 0
  fi

  for p in \
    "${N8N_USER_FOLDER:-}/database.sqlite" \
    "/home/node/.n8n/database.sqlite" \
    "$HOME/.n8n/database.sqlite"; do
    if [ -n "$p" ] && [ -f "$p" ]; then
      DB_PATH="$p"
      return 0
    fi
  done

  return 1
}

check_workflows_sqlite() {
  local rows
  rows="$(sqlite3 "$DB_PATH" "SELECT COALESCE(nodes,'') FROM workflow_entity WHERE active=1;" 2>/dev/null || true)"
  if [ -z "$rows" ]; then
    return 2
  fi

  # Heuristic for the known vulnerable pattern:
  # - active workflow contains Form Submission trigger
  # - contains Form ending/completion node
  # - configured to return binary content
  if printf '%s' "$rows" | grep -q 'n8n-nodes-base.formTrigger' && \
     printf '%s' "$rows" | grep -q '"operation":"completion"' && \
     printf '%s' "$rows" | grep -Eq '"respondWith":"(returnBinary|binaryFile)"'; then
    return 0
  fi

  return 1
}

main() {
  if ! find_version; then
    print_result "UNKNOWN"
    exit 2
  fi

  # Normalize common leading 'v'
  VERSION="${VERSION#v}"

  # Fixed in all 2.x, unaffected below 1.65.0, fixed in >=1.121.0
  if version_ge "$VERSION" "2.0.0"; then
    print_result "PATCHED"
    exit 0
  fi

  if version_lt "$VERSION" "1.65.0"; then
    print_result "PATCHED"
    exit 0
  fi

  if version_ge "$VERSION" "1.121.0"; then
    print_result "PATCHED"
    exit 0
  fi

  # Version is in affected range. Now check whether the vulnerable workflow pattern exists.
  if ! command -v sqlite3 >/dev/null 2>&1; then
    print_result "UNKNOWN"
    exit 2
  fi

  if ! find_db; then
    print_result "UNKNOWN"
    exit 2
  fi

  if check_workflows_sqlite; then
    print_result "VULNERABLE"
    exit 1
  else
    case $? in
      1)
        # Affected version, but vulnerable workflow pattern not found in local active SQLite workflows.
        # Could still be false-negative if using Postgres/MySQL or remote DB.
        print_result "UNKNOWN"
        exit 2
        ;;
      2)
        print_result "UNKNOWN"
        exit 2
        ;;
      *)
        print_result "UNKNOWN"
        exit 2
        ;;
    esac
  fi
}

main "$@"

Sources

1. GitHub Security Advisory GHSA-v4pr-fm98-w9pg
2. n8n community security advisory
3. NVD entry for CVE-2026-21858
4. Cyera Research Labs: Ni8mare technical write-up
5. Censys advisory for CVE-2026-21858
6. ProjectDiscovery nuclei templates releases
7. CISA Known Exploited Vulnerabilities Catalog
8. SystemVll public PoC repository