Ni8mare: The CVSS 10.0 n8n Flaw That Turns a Webhook Into a Full Server Takeover

A vulnerability with the worst possible severity score is sitting in older n8n installs, and it needs no login to exploit. Ni8mare (CVE-2026-21858) lets a remote, unauthenticated attacker send one specially crafted request to an n8n webhook and walk away with any file on the server — API keys, database contents, credentials, everything. Cyera’s public write-up of the flaw has been circulating again this week, and the exposure numbers are ugly: the Shadowserver Foundation found nearly 60,000 internet-connected n8n instances still running vulnerable versions.

By the end of this article you’ll know exactly how Ni8mare works (in plain language), whether your instance is exposed, and how to patch it in about 15 minutes — plus what to check in case someone got there first.

What Ni8mare actually is

A webhook is an HTTP endpoint n8n exposes so outside services can trigger your workflows — a form submission, a file upload, a payment event. A CVE is the industry-wide catalog ID for a specific bug; CVSS 10.0 is the maximum severity rating, meaning the bug is remotely exploitable, needs no authentication, and can fully compromise the host.

Ni8mare lives in how n8n parses incoming webhook data. n8n picks its parser based on the Content-Type header of the request:

• multipart/form-data → a special file-upload parser (the Formidable library), which stores uploaded files in temporary locations and populates req.body.files. The temp-file indirection exists specifically to block path-traversal tricks.
• Anything else (e.g. application/json) → the regular body parser, which populates req.body.

The bug: n8n’s file-handling code reads from req.body.files without verifying the request actually went through the upload parser. So an attacker sends a request to a form/file-upload webhook with Content-Type: application/json and a hand-built files object — and n8n treats it as a legitimate parsed upload, including the attacker-supplied filepath field.

How one webhook request becomes full server control

1. Attacker finds a webhook that expects file uploads. Any workflow with a Form node or file-upload webhook on an internet-reachable n8n instance qualifies. The webhook URL doesn’t need to be secret — n8n webhook paths are often guessable or leaked in client-side code.
2. They send a request with the wrong Content-Type. Instead of multipart/form-data, the request declares application/json and includes a fake files payload — with the filepath field pointed at any file on the server, like /proc/self/environ, .env, or the SQLite database.
3. n8n copies the “uploaded” file. Since the upload parser never ran, the attacker-controlled filepath is used verbatim. Per Cyera’s write-up, “instead of copying an uploaded file, we can copy any local file from the system” — and any node downstream of the form receives the local file’s content.
4. File read becomes full compromise. Reading database.sqlite or environment files yields the N8N_ENCRYPTION_KEY and every stored credential. Cyera notes the same primitive allows forging session cookies (authentication bypass), injecting files into workflows, and ultimately arbitrary code execution — full server takeover.

No account. No workflow access. One HTTP request to a public webhook.

Why the blast radius is massive

n8n isn’t a blog engine — it’s the automation control plane. The workflows on a compromised instance typically hold OAuth tokens for Google Workspace and Salesforce, OpenAI API keys, database connection strings, and payment processor credentials. One server takeover hands an attacker every integration the business wired up.

The numbers, all as reported this month:

• 100M+ Docker pulls of n8n; Cyera estimates ~100,000 servers potentially exposed.
• Nearly 60,000 internet-connected instances still vulnerable, per the Shadowserver Foundation’s scan data (reported by TechRadar in September 2026).
• 76% of exposed n8n instances run versions with known critical CVEs, per Censys’s October 2026 State of the Internet report — we covered that count in our exposed-n8n hardening checklist.

Ni8mare was reported to n8n’s security team on November 9 and patched nine days later in n8n 1.121.0. So the fix has existed for almost a year — the exposed instances are simply instances nobody updated. There are no official workarounds; patching is the only remediation.

Are you exposed?

Note: the 2.x release line postdates this fix, so if you already run 2.x you’re on the patched code path. But versions and advisories rot fast — if you’re unsure, the check in Step 1 takes ten seconds.

Prerequisites: SSH or console access to the machine running n8n, your N8N_ENCRYPTION_KEY value saved somewhere safe, and about 15 minutes.

Step 1 - Check your n8n version

In the n8n editor, open Settings → About — it shows the exact build. Or from the host:

docker exec <n8n-container-name> n8n --version

Replace <n8n-container-name> with your container’s name (often n8n). You should see something like 1.121.0, 1.123.83, or 2.x.x. Anything below 1.121.0 is in the vulnerable range — and honestly, if you’re still on the 1.12x line at all, you should move to the current stable anyway (the October 2026 advisory batch alone patched 14 more advisories, covered in our October security update post).

Step 2 - Back up before you touch anything

Upgrading is low-risk, but a backup makes it zero-risk. Export your workflows from the editor (⋮ menu → Export), and copy your database — the default SQLite file, or a pg_dump if you run Postgres.

The critical one: confirm your N8N_ENCRYPTION_KEY value is saved somewhere off the server. Without the exact same key, a restored instance cannot decrypt any stored credential, and every credential becomes unusable. I treat this as step zero of every upgrade.

Warning: if your instance was internet-exposed on a vulnerable version, back up first, but also plan to rotate secrets after patching (Step 4) — a backup preserves your data, it doesn’t undo a compromise that already happened.

Step 3 - Upgrade to the patched version

For the common Docker Compose install:

# 1. Pull the patched image
docker compose pull n8n

# 2. Recreate the container with the new image
docker compose up -d

# 3. Watch the logs for a clean startup
docker compose logs -f n8n

Why these commands: pull fetches the fixed image, up -d recreates the container on it, and the logs confirm the database migrations ran without errors. You should see n8n ready on 0.0.0.0, port 5678 with no migration failures.

Pin to a fixed version tag rather than latest in your docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:1.123.83

Anything at or above 1.121.0 closes Ni8mare; pinning the current stable (1.123.83 on the 1.x line, or the 2.x line) also picks up every advisory since. If you installed via npm:

# Stop the running process first (systemd/pm2/however you run it)
npm install -g [email protected]
# then start it again

Verify in Settings → About that the running version is at or above 1.121.0.

Step 4 - Check whether someone got there first

If your instance was both vulnerable and internet-reachable, patching closes the hole but doesn’t erase a break-in. Work through these:

1. Scan your own exposure. Check whether your instance’s IP appears in Shadowserver or Censys scan data for vulnerable n8n versions. If it was fingerprinted, assume it was probed.
2. Review webhook access logs. Look for requests to your webhook endpoints with unusual Content-Type headers (application/json hitting form/file-upload paths) or requests that don’t match any legitimate integration. One anomalous hit to a file-upload webhook is the signature.
3. Rotate your secrets. If there is any chance of compromise, rotate the N8N_ENCRYPTION_KEY, every API key and OAuth credential stored in n8n, and any database passwords the instance could reach. A file-read bug means the attacker may hold a copy of everything — changing the locks after patching is the only way to be sure.
4. Audit user sessions. Check for unfamiliar owner/admin accounts or unexpected workflow changes — the file-read primitive can escalate to session forgery.

If you want this as a repeatable routine, our free n8n security advisory triage template walks through the same pattern — inventory your version, check it against the advisory list, and run the post-patch verification — as an actual workflow you can import.

What this article doesn’t cover (honest limits)

I did not test the exploit against a live instance — reproducing a CVSS 10.0 unauthenticated RCE would be reckless, and Cyera’s write-up contains the technical detail if you need it for a compliance report. I also can’t confirm whether Ni8mare was exploited in the wild before or after the patch; neither n8n nor Cyera has published exploitation data. The exposure counts come from third-party internet scans (Shadowserver via TechRadar, Censys), which measure vulnerable instances, not compromised ones. Patch first, investigate logs second.

FAQ

Am I affected if I only use n8n Cloud?

No. n8n Cloud instances were patched automatically. This is a self-hosted problem.

I run 2.x — do I need to do anything?

The Ni8mare fix predates the 2.x line, so 2.x installs already contain it. But use this as the prompt to check you’re on a current 2.x — the October 2026 advisory batch patched 14 more advisories on top.

Is there a workaround if I can’t upgrade right now?

No official workaround exists for Ni8mare. The closest mitigation is removing internet exposure: put n8n behind a VPN or firewall so webhook endpoints aren’t publicly reachable. That shrinks who can knock, but patching is the actual fix.

Where are the full advisory details?

On the n8n GitHub Security Advisories page and Cyera’s research write-up (linked from the Infosecurity Magazine coverage). The original report to n8n’s security team was November 9; the fix shipped nine days later in 1.121.0.

Key Takeaways

1. Ni8mare (CVE-2026-21858) is a CVSS 10.0 unauthenticated RCE in n8n — one crafted webhook request can read any file on the server, forging sessions and escalating to full takeover.
2. The fix is n8n 1.121.0 or later — nearly 60,000 internet-connected instances are still unpatched, which is why this still matters a year later.
3. There is no workaround — patch, or at minimum pull the instance off the public internet.
4. If you were exposed, rotate everything — a file-read bug means stored secrets may already be copied; changing keys after patching is the real remediation.

Next: run the 4-step check above, then grab the n8n security advisory triage template to make version checks a repeatable routine instead of a panic.

Images: Pexels