n8n "Ni8mare" (CVE-2026-21858): a CVSS 10.0 flaw hands over 100,000 automation servers with no password

Picture a server that orchestrates all your automations: it reads your emails, writes to your database, deploys code, posts to your social accounts, and holds the API keys to half of your infrastructure. Now picture an attacker taking full control of it without a single credential, just by sending a well-formed HTTP request. That is exactly what Ni8mare allows — the CVE-2026-21858 flaw rated 10.0 out of 10 on CVSS, which left roughly 100,000 n8n servers wide open.

This article dissects the vulnerability, its full exploitation chain all the way to remote code execution, and above all: how to tell whether you are exposed and how to protect yourself. Because a compromised n8n instance isn't just a lost server — it is, in the words of Cyera's researchers, "the keys to everything."

n8n: why this target is so juicy

n8n is an open-source workflow automation platform (a self-hostable competitor to Zapier/Make). It is most often deployed via Docker, on a VPS or a homelab, and connected to everything: SaaS APIs, databases, SSH servers, inbound webhooks. It is precisely this central hub position that makes it a dream target.

An n8n instance stores — in cleartext or in decryptable form — the credentials of every connected service. Compromising it means obtaining a pivot into the entire ecosystem it drives. And because many instances expose their webhooks or forms directly on the Internet (that is their primary function: receiving external data), the attack surface is massive.

Ni8mare (CVE-2026-21858): the anatomy of the flaw

Discovered by Cyera and disclosed in January 2026, Ni8mare is an unauthenticated RCE. The root of the problem is a "Content-Type Confusion" in webhook processing.

Concretely: the function that handles form submissions (formWebhook()) invokes a file-handling function (copyBinaryFile()) that operates on req.body.files without first verifying that the request's Content-Type is actually multipart/form-data. By sending a different Content-Type with a malicious body, the attacker overwrites internal variables (req.body.files) and obtains an arbitrary file read primitive on the system.

An arbitrary file read sounds "limited." Except that on n8n, it is the first link in a chain that leads straight to full control.

The exploitation chain, step by step

Here is how you go from a simple file read to full code execution — a sequence that deserves study precisely because it is so clean:

1. Reading the database. With the arbitrary read primitive, the attacker retrieves /home/node/.n8n/database.sqlite and extracts the administrator's ID, email and password hash.
2. Stealing the encryption key. They then read /home/node/.n8n/config to recover the secret encryption key (the one that protects the credentials of connected services).
3. Forging a session cookie (authentication bypass). With the admin ID and the secret key, they forge a valid session cookie and obtain administrator access — without ever knowing the password.
4. RCE via the "Execute Command" node. Now an admin, they create a new workflow containing an Execute Command node and run arbitrary commands on the server.

File read → secret theft → auth bypass → RCE. Each link is innocuous in isolation; chained together, it is a complete takeover from the Internet, with no authentication. It is the perfect illustration of why a "simple" file read must always be treated as critical.

Ni8mare was only the beginning: the Q1 2026 CVE wave

What makes the n8n episode exemplary is that it is not an isolated flaw but a wave. Rapid7 grouped several of these vulnerabilities under the names "Ni8mare" and "N8scape":

• CVE-2026-21877 (CVSS 10.0) — authenticated RCE: under certain conditions, an authenticated user can make the service execute arbitrary code. Fixed in 1.121.3 (credited to Théo Lelasseux).
• CVE-2025-68613, 68668, 68697 — authenticated flaws chainable with the unauthenticated RCE CVE-2026-21858 for code execution or arbitrary file write.
• CVE-2026-27493 (March 2026) — a "double evaluation" bug in the Form nodes: since form endpoints are public by design (no auth, no account required), simply submitting a payload in the Name field of a public "Contact" form is enough to execute shell commands. Brutally simple.
• CVE-2026-27577 — a sandbox escape in the expression compiler: a missing case in the AST rewrite lets process pass through untransformed, granting RCE to any authenticated expression.

Six critical CVEs in a single quarter on the same product tells a story: self-hosted automation platforms are a still largely underestimated attack surface, and their security has not kept pace with their explosive adoption.

Am I vulnerable? (the only number that matters)

The version that fixes Ni8mare alone is 1.121.0. But to be protected against all the disclosed CVEs (the full wave), you need to be on:

• n8n 2.14.1 or higher, or
• n8n 1.123.27 or higher (LTS branch)

Any earlier version is vulnerable to at least one of these flaws. If you run via Docker (the most common case), check your version immediately:

# Version of the running image
docker exec -it n8n n8n --version

# Or via the API (without a shell in the container)
curl -s https://YOUR-INSTANCE/healthz/readiness

# Update (docker compose example)
docker compose pull && docker compose up -d
docker exec -it n8n n8n --version  # confirm >= 2.14.1

Detection: what to look for in your logs

If your instance was exposed unpatched, assume it may have been hit and look for the following indicators:

• Requests to your /webhook or /form endpoints with an unusual Content-Type (anything other than multipart/form-data on a file submission).
• Unsolicited workflow creation, especially containing an Execute Command or Code node.
• Read access to database.sqlite or the config file in /home/node/.n8n/.
• Admin logins with no prior failed login (the signature of a forged cookie rather than a brute-force).
• Abnormal child processes spawned from the n8n container (an eBPF runtime monitoring tool like Falco is ideal for spotting them).

Remediation and lasting hardening

Patching is necessary but not sufficient — especially if the instance may have been compromised. Action plan:

1. Patch immediately to 2.14.1+ / 1.123.27+. There is no reliable workaround for Ni8mare.
2. If exposure is possible: rotate every secret. A compromised instance gave up the encryption key and therefore all the credentials of connected services. Regenerate the key, and rotate every connected token/API key/password. Our secrets management guide (Vault, External Secrets) walks through the process.
3. Never expose n8n directly on the Internet. Put the interface and the endpoints behind strong authentication, a reverse proxy with access restrictions, or a VPN. Only the strictly necessary webhooks should be reachable, ideally filtered.
4. Network segmentation. The instance should only be able to reach the systems it actually drives — not the whole LAN. That is the very principle of a Zero Trust architecture.
5. Least privilege on connected accounts. Every credential stored in n8n should have the minimal scope. If the instance falls, the impact is bounded.
6. Container isolation. Run n8n via Docker with a non-root user, a read-only filesystem wherever possible, and no mounted Docker socket.

The lesson: automation comes with attack surface

The n8n affair is a textbook case that goes well beyond the product itself. Automation tools — n8n, but also CI/CD servers, orchestrators, AI agents — concentrate by their very nature a disproportionate amount of power and secrets. They are high-value targets that we often deploy with the casualness of an internal tool, exposed on the Internet "just for a test" that becomes permanent.

The rule is simple: anything that automates and holds credentials must be treated as a critical asset — patched as a priority, isolated, monitored, and never exposed without access control. Ni8mare merely reminded us, with a CVSS of 10.0, of what operational rigor should have imposed from the start.