If you run n8n yourself, 2026 was the year you couldn’t ignore its security advisories anymore. Several critical, unauthenticated remote-code-execution vulnerabilities were disclosed in quick succession — the kind that let an attacker take over an exposed instance without a password. Here’s what actually happened, in plain language, and what it means if you’re self-hosting.
The headline vulnerability: “Ni8mare” (CVE-2026-21858)
The most severe of the batch, nicknamed Ni8mare, is an unauthenticated remote code execution flaw that security researchers rated at the maximum CVSS score of 10.0. In practice, it let an attacker read arbitrary files off the server, steal the instance’s encryption key, forge an admin session, and run OS commands — all without logging in first. n8n fixed it in version 1.121.0; anything older exposed to the internet was at risk.
The rest of the batch
Ni8mare wasn’t alone. Three other CVEs landed around the same period:
- CVE-2026-27493 — a second-order expression injection in n8n’s Form nodes. Submitting crafted form data let an attacker inject and evaluate arbitrary n8n expressions, which, chained with a separate sandbox-escape bug, could escalate to full remote code execution.
- CVE-2026-25049 — a critical (CVSS 9.4) unauthenticated RCE reachable through public webhooks with no authentication at all. A single line of JavaScript using destructuring syntax in a workflow node was enough to run system commands. Fixed in 1.123.17 and 2.5.2.
- CVE-2026-33660 — an authenticated RCE (CVSS 9.4) that let a logged-in attacker execute arbitrary commands on the host.
Put together, these disclosures are why “just run n8n on a cheap VPS and forget about it” stopped being reasonable advice this year.
What this actually means for you
A few things are true regardless of who hosts your instance:
- Patching n8n itself is your job. Whether you’re on a $5 VPS or a managed instance, nobody else decides when your n8n version gets updated — you do (unless you’ve explicitly handed that over). What changes with managed hosting isn’t who clicks “update”; it’s whether the infrastructure around that update is safe to touch.
- Isolation limits the blast radius. On a shared box or a “pod” style host, one compromised instance can be a foothold into a shared environment. A properly isolated, single-tenant instance with its own database and its own encryption key means a compromise stays contained to that one instance.
- An untested backup is not a backup. If an update goes wrong — or an instance gets compromised before you patch — the only way back is a backup you’ve actually verified restores, not one you assume works.
- Public-facing surface matters. CVE-2026-25049 was exploitable through ordinary public webhooks. Anything sitting behind basic edge protection (a WAF, DDoS mitigation) has a materially smaller attack surface than an instance with nothing in front of it.
The practical checklist
If you’re running n8n yourself — on any host — this year’s CVEs are a good reason to check:
- Are you actually watching n8n’s release notes and security advisories, or finding out about critical patches secondhand?
- Is your instance’s encryption key backed up separately from your database? (If you lose it, every stored credential becomes permanently unrecoverable — patched or not.)
- Is your instance isolated, or sharing resources with other tenants?
- Have you tested a restore in the last month, or just assumed the backup job succeeded?
None of this requires switching hosts. It does require someone treating it as an actual job rather than a background task. That’s the gap managed n8n hosting is built to close — see our security and backups approach for the specifics, or what’s included on every plan.