Six CVEs in Three Months: n8n’s Worst Security Quarter Ever

If you self-host n8n for workflow automation, stop what you’re doing and check your version number. Between January and March 2026, security researchers disclosed six critical vulnerabilities in n8n — including multiple unauthenticated remote code execution (RCE) chains that give attackers full control of your server.

The most severe, CVE-2026-21858 (“Ni8mare”), scored a perfect CVSS 10.0 and affects an estimated 100,000 self-hosted instances. Two more critical RCE chains dropped on March 25, and the window for exploitation is wide open on any unpatched server.

This guide covers every disclosed CVE, how to check if you’re vulnerable, and how to lock down your n8n instance so the next disclosure doesn’t ruin your week.

The CVE Breakdown: What’s Been Disclosed

CVE-2026-21858 — “Ni8mare” (CVSS 10.0)

Disclosed in early Q1, this is the worst of the bunch. An unauthenticated attacker can achieve full remote code execution on any n8n instance exposed to the internet. No credentials, no API keys, no prior access required. Cyera Research, who discovered the flaw, estimates 100K+ self-hosted servers are affected.

Impact: Complete server compromise. Attackers can read your workflow credentials, access connected databases, pivot to other services on your network, and install persistent backdoors.

CVE-2026-33660 — Merge Node AlaSQL Injection

Disclosed March 25. The Merge node’s AlaSQL SQL mode allows authenticated users to read arbitrary files from the server and achieve RCE. The attack uses JavaScript’s constructor chain to escape the sandbox:

// The attacker crafts a SQL query in the Merge node that breaks out:
// AlaSQL ? JavaScript constructor chain ? arbitrary code execution
// This bypasses n8n's expression sandbox entirely

Impact: Any user with workflow edit access (including shared team members) can read /etc/passwd, Docker configs, environment variables containing API keys, and execute arbitrary commands.

CVE-2026-27493 — Form Node Double-Evaluation RCE

Also disclosed March 25. Public-facing Form nodes evaluate expressions twice, and when chained with expression sandbox escape CVE-2026-27577, this allows unauthenticated RCE through any publicly accessible n8n form.

Impact: If you use n8n’s Form trigger to collect data from external users, anyone who submits a crafted form payload can execute commands on your server.

CVE-2026-27577 — Expression Sandbox Escape

The expression sandbox that’s supposed to prevent workflow code from accessing the underlying system can be bypassed. This CVE is the enabler for CVE-2026-27493’s unauthenticated RCE chain.

Additional Disclosed Flaws

Two more CVEs round out the quarter: a deserialization flaw dubbed “LangGrinch” (CVE-2025-68664) that can extract conversation histories and secrets, and a path traversal in prompt loading (CVE-2026-34070, CVSS 7.5) affecting LangChain integrations within n8n workflows.

Am I Vulnerable? How to Check

Check Your n8n Version

If you’re running n8n via Docker (the most common self-hosted setup), check your current version:

# Check running n8n version
docker exec n8n n8n --version

# Or check your docker-compose.yml image tag
grep -i "n8nio/n8n" docker-compose.yml

You must be on n8n 2.14.1+ or 1.123.27+ to be patched against all disclosed CVEs. Anything older is vulnerable to at least one of these flaws.

Check for Public Exposure

The unauthenticated RCE chains (Ni8mare and the Form Node chain) only work if your n8n instance is reachable from the internet. Check whether yours is exposed:

# Check if n8n port is publicly accessible
# Run this from a machine OUTSIDE your network
curl -s -o /dev/null -w "%{http_code}" https://your-n8n-domain.com/healthz

# Check if Form trigger endpoints are public
curl -s -o /dev/null -w "%{http_code}" https://your-n8n-domain.com/form/

If either returns a 200, your instance is publicly reachable and at risk from the unauthenticated chains.

Upgrade Now: Step-by-Step

Docker Compose (Most Common)

# 1. Back up your n8n data
docker exec n8n n8n export:workflow --all --output=/tmp/workflows.json
docker exec n8n n8n export:credentials --all --output=/tmp/credentials.json
cp -r ~/.n8n ~/.n8n.backup.$(date +%Y%m%d)

# 2. Update the image tag in docker-compose.yml
# Change: image: n8nio/n8n:latest
# Or pin: image: n8nio/n8n:2.14.1

# 3. Pull and restart
docker compose pull n8n
docker compose up -d n8n

# 4. Verify the new version
docker exec n8n n8n --version

npm Installation

# 1. Back up first
n8n export:workflow --all --output=workflows-backup.json
n8n export:credentials --all --output=credentials-backup.json

# 2. Update
npm install -g n8n@latest

# 3. Restart n8n (systemd example)
sudo systemctl restart n8n

# 4. Verify
n8n --version

Kubernetes / Helm

# Update values.yaml with the new image tag
# image:
#   tag: "2.14.1"

helm upgrade n8n n8n/n8n -f values.yaml -n n8n

Hardening Your n8n Instance

Patching fixes today’s CVEs. Hardening reduces blast radius when the next ones drop — and with six disclosures in one quarter, the pattern is clear.

1. Kill Public Access with a VPN or Reverse Proxy

n8n should never be directly exposed to the internet. Place it behind a reverse proxy with authentication, or restrict access to a WireGuard VPN tunnel:

# Nginx reverse proxy with basic auth
server {
    listen 443 ssl;
    server_name n8n.yourdomain.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }

    # Block public form access unless specifically needed
    location /form/ {
        deny all;
        # Or restrict to specific IPs:
        # allow 203.0.113.0/24;
        # deny all;
    }
}

2. Run n8n as a Non-Root User

If an attacker achieves RCE, running as root gives them the entire server. Docker’s default is root inside the container:

# docker-compose.yml
services:
  n8n:
    image: n8nio/n8n:2.14.1
    user: "1000:1000"
    environment:
      - N8N_USER_FOLDER=/home/node/.n8n
    volumes:
      - ./n8n-data:/home/node/.n8n

3. Network Isolation

Limit what n8n can reach if compromised. Docker networks are your friend:

# docker-compose.yml
services:
  n8n:
    networks:
      - n8n-internal
      - n8n-external
    # n8n can reach its database but not your other services

  postgres:
    networks:
      - n8n-internal
    # Database is only reachable from n8n

networks:
  n8n-internal:
    internal: true   # No internet access
  n8n-external:

4. Restrict Workflow Capabilities

n8n ships with powerful nodes enabled by default. Lock down what workflows can do:

# Environment variables to restrict n8n
N8N_BLOCK_ENV_ACCESS_IN_NODE=true     # Block access to server env vars
EXECUTIONS_DATA_SAVE_ON_ERROR=all     # Log failed executions for audit
N8N_DIAGNOSTICS_ENABLED=false         # Disable telemetry
N8N_TEMPLATES_ENABLED=false           # Disable community templates (attack surface)

5. Monitor for Exploitation Attempts

Set up basic monitoring to catch attacks. An intrusion prevention system like CrowdSec can block suspicious traffic patterns automatically:

# Check n8n logs for suspicious activity
docker logs n8n --since 24h 2>&1 | grep -i "error\|unauthorized\|injection\|eval"

# Monitor for unusual outbound connections
ss -tnp | grep $(docker inspect -f '{{.State.Pid}}' n8n)

The Bigger Picture: Self-Hosted Software Security

n8n’s Q1 2026 is a case study in the tradeoff every self-hoster accepts: you get full control, but you’re also the security team. With 52 million+ weekly PyPI downloads across the affected LangChain packages and 100K+ self-hosted n8n servers, the attack surface is enormous.

Three patterns from this quarter’s disclosures apply to every self-hosted tool:

  • Expression sandboxes fail. n8n’s sandbox was bypassed twice. Never assume a “sandbox” protects you — defense in depth (network isolation, least privilege, non-root containers) is what actually limits damage.
  • Public forms are attack surface. Any feature that accepts unauthenticated input is a target. Restrict public endpoints to the absolute minimum, and consider putting them behind a WAF.
  • Update cycles matter. The gap between CVE disclosure and active exploitation is shrinking. If you can’t commit to patching within 48 hours of a disclosure, you need managed support to handle it for you.

If you’re running n8n alongside other self-hosted tools on the same server, this is a good time to audit everything. Our n8n production setup guide covers the baseline Docker Compose configuration, and the hardening steps above layer on top of it.

What to Do Right Now

  1. Check your version — run docker exec n8n n8n --version. If it’s below 2.14.1, you’re vulnerable.
  2. Upgrade immediately — back up, pull the new image, restart. This takes 5 minutes.
  3. Block public access — if n8n is exposed to the internet, put it behind a reverse proxy with auth or a VPN. This is the single highest-impact change.
  4. Audit your workflows — check for Form triggers that accept public input and Merge nodes using SQL mode.
  5. Set up update notifications — subscribe to n8n’s GitHub security advisories so the next disclosure doesn’t catch you off guard.

Self-hosting n8n on a Cloud VPS gives you the control to lock down your instance properly — dedicated resources, full root access, and network isolation that shared environments can’t provide. Pair it with CWH’s managed support for patch management if keeping up with security disclosures isn’t in your workflow.