Ni8mare: n8n's CVSS 10.0 That Hands Over Your Entire Automation Stack

If you run n8n — the workflow automation platform that half the industry wired into their AI pipelines last year — you need to stop and check your version right now.

CVE-2026-21858, dubbed Ni8mare by its discoverers at Cyera Research Labs, is a CVSS 10.0 unauthenticated remote code execution flaw. No credentials needed. No user interaction. Just network access to the webhook endpoint.

A proof of concept is public. Roughly 100,000 instances are exposed to the internet.

What n8n Is (and Why This Matters)

n8n is a workflow automation platform used to connect services, trigger actions, and increasingly, orchestrate AI agents. Think of it as the glue between your internal tools — CRM, ticketing, CI/CD, cloud APIs, databases.

That means a typical n8n instance has:

API tokens for every connected service
Database credentials
Cloud provider keys
CI/CD pipeline access
Customer data flowing through workflows

Compromising n8n doesn’t just give you n8n. It gives you everything n8n touches.

The Vulnerability

The root cause is a Content-Type confusion flaw in n8n’s webhook and file-handling logic.

The parseRequestBody() function processes incoming webhook requests but fails to verify that the Content-Type header is actually multipart/form-data before invoking file-handling code. This lets an attacker override the internal req.body.files object through a regular HTTP request.

From the Cyera disclosure:

“Since this function is called without verifying the content type is ‘multipart/form-data,’ we control the entire req.body.files object.”

That gives you arbitrary local file reads through the Form node’s copyBinaryFile() function.

The Attack Chain

Once you can read arbitrary files, the game is over:

Step	Action	Result
1	Read `/home/node/.n8n/database.sqlite`	Extract admin credentials
2	Read `/home/node/.n8n/config`	Get encryption secrets
3	Forge session cookie	Authentication bypass
4	Access Execute Command node	Full RCE on the host

Four steps. Unauthenticated to root. The attacker reads the database, grabs credentials, forges a valid session, and executes arbitrary commands.

This isn’t theoretical. The PoC is public.

There’s a Second One

n8n also disclosed CVE-2026-21877 — a separate vulnerability, also CVSS 10.0. This one is an unrestricted file upload flaw that lets an authenticated attacker execute arbitrary code through the n8n service.

The key difference: CVE-2026-21877 requires authentication. But if an attacker chains CVE-2026-21858 first (which gives them auth), both flaws are effectively unauthenticated.

	CVE-2026-21858	CVE-2026-21877
Auth Required	No	Yes
CVSS	10.0	10.0
Type	Content-Type confusion → file read → RCE	Unrestricted file upload → RCE
Fixed In	1.121.0	1.121.3

Exposure

Censys identified 26,512 exposed n8n instances directly accessible from the internet:

United States: 7,079
Germany: 4,280
France: 2,655

The actual number of vulnerable instances is likely higher — many sit behind reverse proxies that still pass webhook traffic through.

Cyera’s estimate of ~100,000 affected servers includes instances not directly indexed.

Timeline

Date	Event
November 9, 2025	Cyera reports vulnerability to n8n
November 18, 2025	n8n releases patch (v1.121.0)
January 7, 2026	CVE assigned, public disclosure

Notice the gap: the patch shipped in November, but the CVE and public disclosure didn’t happen until January. If you weren’t watching n8n’s changelogs, you had no idea you were running a CVSS 10.0 for two months.

What To Do

1. Check Your Version

# If running via Docker
docker exec -it n8n n8n --version

# If running via npm
n8n --version

If you’re on anything below 1.121.3, you’re vulnerable to at least one of these.

2. Update Immediately

# Docker
docker pull n8nio/n8n:latest
docker restart n8n

# npm
npm update -g n8n

Target versions: 1.121.3+, or latest stable (1.123.10, 2.1.5, 2.2.4, 2.3.0).

3. Check for Compromise

Look for:

Unexpected admin accounts in n8n’s user management
New or modified workflows (especially Execute Command nodes)
Unfamiliar webhook endpoints
File access logs showing reads of database.sqlite or config

4. Assume Secrets Are Burned

If your instance was exposed and running a vulnerable version, assume every credential stored in n8n is compromised:

Rotate all API tokens configured in n8n credentials
Rotate database passwords
Rotate cloud provider keys
Review CI/CD pipeline access
Check connected services for unauthorized activity

5. Stop Exposing n8n to the Internet

n8n’s webhook endpoints need to be reachable, but the entire application doesn’t need to be internet-facing. Use:

Reverse proxy with path-based routing (only expose /webhook/ paths)
IP allowlisting for webhook sources
VPN or Tailscale for admin access

There’s no workaround for this vulnerability. Patching is the only fix.

The Automation Platform Problem

This is the same pattern we see with edge appliances, except it’s moved up the stack.

n8n sits at the center of enterprise automation. It holds the keys to everything it connects to. When it gets compromised, the blast radius isn’t one application — it’s every application in the workflow.

And like edge appliances, these platforms are:

Internet-facing (webhooks need to be reachable)
Credential-rich (that’s their entire purpose)
Often self-hosted with minimal security review
Patched reactively, not proactively

The shift toward AI-powered automation makes this worse. n8n instances increasingly orchestrate AI agents that have broad permissions across infrastructure. A compromised n8n instance with AI agent access is an attacker with an autonomous assistant.

References

Your automation platform knows every password to every service it touches. That’s the point. It’s also the problem.