n8n's Unauthenticated RCE Hit an Estimated 100,000 Servers. Patch to 1.121.0
Cyera Research Labs disclosed CVE-2026-21858, nicknamed "Ni8mare," a critical unauthenticated remote code execution vulnerability in n8n that carries a CVSS score of 10.0, the maximum possible. It affects self-hosted n8n instances running versions before 1.121.0, and in some configurations before 1.121.3, with an estimated 100,000 exposed servers globally. I run n8n for a chunk of my own client automation work, so this landed in my feed the way a plumbing leak lands when it's your own basement.
The bug lives in n8n's Form Webhook node, the component that handles file uploads from public-facing forms. It requires no login at all if the vulnerable endpoint is reachable, which is exactly the setup a lot of solo operators run: a VPS somewhere, n8n exposed to accept webhook triggers from Stripe, a client's CRM, or a public intake form, running unattended for months at a time.
How the exploit actually chains together
The root cause is a content-type confusion bug. n8n's file-handling logic in the Form Webhook path assumes incoming requests are multipart uploads and trusts certain internal file references without strictly validating them. An attacker can send crafted JSON instead of a real multipart upload and override those internal file references, which opens the door to reading arbitrary files off disk, including things like /etc/passwd or n8n's local SQLite database.
From there the chain gets worse fast. Reading the local database exposes stored credentials and, critically, the signing material n8n uses for session tokens. With that signing material in hand, an attacker can forge a valid admin session without ever needing a password, then use that forged session to reach n8n's command-execution capabilities and run arbitrary OS commands on the host. Cyera's proof of concept walks through this full chain: file read, credential extraction, session forgery, remote code execution, no authentication required at any step.
Unauthenticated request to Form Webhook -> content-type confusion overrides trusted file reference -> arbitrary file read (SQLite DB, session signing keys) -> forged admin session -> command execution via workflow nodes
Who's actually exposed
This is specifically a self-hosted problem. n8n Cloud isn't affected, because the severe parts of this attack chain depend on access to local files and instance-level secrets that a managed environment doesn't expose the same way. If you're running n8n Cloud, this one isn't yours to worry about. If you're running the open-source version on your own infrastructure, and you have any Form or Webhook node reachable from the public internet, you're in the affected population until you patch.
I'd guess a meaningful share of solo operators and small agencies running n8n fall into exactly that category, because the whole appeal of self-hosting is not paying for the cloud tier, and the whole point of webhooks is that they're reachable from the outside. That combination is precisely what this bug targets.
I've talked to a couple of other solo devs this week who run n8n the same way I do: one instance on a small VPS, a handful of Form nodes wired up to client intake pages, nobody actively watching the logs day to day. None of us had checked our version numbers before this disclosure crossed our feeds, which is a fair description of how most side-project infrastructure gets treated once it's working. That's exactly the blind spot this bug is built to exploit.
What to actually do about it
The fix list is short and doesn't require rethinking your automation setup:
- Upgrade n8n to version 1.121.0 or later, and to 1.121.3 specifically where your configuration calls for it
- Require authentication on every Form node you have exposed, don't rely on obscurity of the URL
- Rotate any API keys, OAuth tokens, or credentials that were stored in a workflow on an instance that was ever internet-exposed while vulnerable
- Review your execution logs for anything that looks like unexpected file access or command execution around the disclosure window
- Disable the Execute Command node entirely unless a specific workflow actually needs it, since it's the highest-value target once someone has a forged session
None of that is a re-architecture. It's an upgrade, a config review, and a credential rotation, and for most single-operator n8n setups it's genuinely a 20-minute task, not a weekend project.
The honest take
My recommendation is blunt: if you have n8n exposed to the internet and haven't checked your version today, stop reading and go check it, then come back. The severity here (unauthenticated, CVSS 10, chains to full RCE) puts it well above the threshold where "I'll get to it this week" is an acceptable response.
Where this argument could be weaker than I'm making it sound: Cyera's 100,000-server exposure estimate is their own research, not an independently audited number, and it almost certainly includes a mix of production instances, abandoned test deployments, and honeypots, so it's a signal of scale rather than a precise count of businesses at risk. That doesn't change the remediation advice, but it's worth being honest that the scariest number in this story is the least verifiable one.
Author
Lukas
@lukcombinator