If you run n8n on anything older than version 1.121.0, an unauthenticated attacker can read your database, forge an admin session, and execute arbitrary commands on your server. No credentials needed. No user interaction required. CVSS 10.0. Between December 19, 2025 and February 7, 2026, n8n disclosed at least eight critical and high-severity vulnerabilities, including unauthenticated remote code execution, sandbox escapes, and expression injection bugs that bypass previous patches. GreyNoise logged 33,000 exploit attempts against exposed n8n instances in a single week.
This is not a theoretical risk. It is an active attack surface.
The CVE Timeline: Eight Vulnerabilities, Six Weeks
The vulnerabilities arrived in three waves. Each wave was worse than the last.
Wave 1: Expression Injection and Sandbox Escapes (December 2025)
CVE-2025-68613 (CVSS 8.8) dropped on December 19, 2025. An authenticated user could inject arbitrary system commands through n8n’s expression language. The expression evaluator, which processes template variables like {{ $json.email }} in workflow nodes, failed to sanitize inputs that contained JavaScript code. An attacker with workflow edit access could craft expressions that broke out of the evaluator sandbox and executed shell commands on the host. Fixed in n8n 1.20.4.
CVE-2025-68668 (CVSS 9.9), disclosed on December 26, earned the codename “N8scape.” n8n 1.0 introduced Python code execution using Pyodide, a WebAssembly-based Python runtime that runs in a sandboxed environment. N8scape demonstrated that the sandbox boundary was porous: a carefully crafted Python payload could escape Pyodide’s isolation and access the host filesystem, environment variables, and network. The attack required authentication but only basic workflow creation permissions.
CVE-2025-68697 (CVSS 5.4) arrived the same day. n8n’s legacy JavaScript execution mode, used in older workflows, permitted arbitrary file read and write operations. Lower severity, but another path to data exfiltration for authenticated attackers.
Wave 2: Ni8mare, the CVSS 10.0 (January 2026)
CVE-2026-21858 (CVSS 10.0) is the one that should keep self-hosted n8n operators up at night. Discovered by Dor Attias at Cyera Research Labs and codenamed “Ni8mare”, this vulnerability requires zero authentication. Any n8n instance with a Form or Webhook trigger exposed to the network is vulnerable.
The attack exploits a content-type confusion flaw. When a webhook endpoint expects a multipart file upload, n8n’s middleware parses the request body using Formidable and populates req.body.files with sanitized temporary file paths. But if the attacker sends the request with Content-Type: application/json instead, the JSON body parser runs. The prepareFormReturnItem() function never checks which parser actually ran. It trusts whatever is in req.body.files, including attacker-controlled filepath values pointing to /home/node/.n8n/database.sqlite.
The full kill chain works in three stages:
- Arbitrary file read: Send a JSON payload with a crafted
filesobject wherefilepathpoints to the SQLite database. n8n dutifully returns the file contents. - Auth bypass: Extract the admin password hash and the
ENCRYPTION_KEYfrom the database and config. Forge a valid JWT session cookie. - RCE: Create a workflow with an Execute Command node. Run anything.
Reported November 9, 2025. Patched November 18, 2025 (before public disclosure). CVE assigned January 6, 2026. Public disclosure January 7, 2026. Fixed in version 1.121.0. Estimated 100,000 instances were potentially affected.
CVE-2026-21877 (CVSS 9.9) arrived the same day: a remote code execution through arbitrary file write, affecting versions 0.123.0 to 1.121.3. Fixed in 1.121.3.
Wave 3: The Patch Bypass (February 2026)
The fix for CVE-2025-68613 relied on TypeScript type checking to ensure expression inputs were strings before sanitizing them. It was not enough.
CVE-2026-25049 (CVSS 9.4), disclosed February 7, demonstrated that the sanitization check could be bypassed by passing non-string values (objects, arrays, or symbols) as expression inputs. As Endor Labs researcher Cris Staicu explained: “TypeScript cannot enforce these type checks on runtime attacker-produced values.” An authenticated attacker with workflow edit permissions could once again execute arbitrary system commands.
When combined with a public webhook, the attack becomes exploitable without authentication. Fixed in versions 1.123.17 and 2.5.2.
Eleven additional vulnerabilities were disclosed alongside CVE-2026-25049, including:
- CVE-2026-21893 (CVSS 9.4): Command injection via admin permissions
- CVE-2026-25052 (CVSS 9.4): File access TOCTOU vulnerability
- CVE-2026-25053 (CVSS 9.4): OS command injection in the Git node
- CVE-2026-25051 (CVSS 8.5): XSS in webhook responses
- CVE-2026-25054 (CVSS 8.5): Stored XSS in the markdown component
Why n8n’s Architecture Makes This Worse
These are not isolated bugs in edge-case features. They hit the core of what n8n does: execute user-defined logic on a shared server. Three architectural patterns amplify the risk.
Expression Evaluation Is a Shell in Disguise
n8n’s expression language is essentially JavaScript eval() with guardrails. Users write {{ }} templates that get evaluated at runtime to transform data between workflow nodes. The guardrails (sandbox boundaries, type checks, sanitization) have been bypassed three times now (CVE-2025-68613, CVE-2026-25049, and CVE-2025-68668). Each fix addressed the specific bypass technique without addressing the fundamental problem: running user-supplied code in a shared execution environment is hard to secure. The Pyodide sandbox escape proved that even WebAssembly isolation is not a silver bullet.
Webhooks Create Unauthenticated Attack Surface
n8n workflows commonly start with webhook triggers that listen on public URLs. These endpoints are, by design, unauthenticated: they accept inbound HTTP requests from external systems. Ni8mare (CVE-2026-21858) exploited exactly this pattern. Any workflow with a Form or Webhook trigger became an entry point for full server compromise. The n8n documentation recommends putting webhooks behind a reverse proxy with authentication, but the default configuration exposes them directly.
Self-Hosted Means Self-Patched
n8n Cloud instances were patched by the n8n team. Self-hosted instances, which make up the majority of n8n deployments, depend on operators manually upgrading. The gap between “patch available” and “patch applied” is where the 33,000 exploit attempts logged by GreyNoise happened. Many self-hosted n8n instances run on Docker with fixed version tags, meaning they never receive automatic updates.
What You Need to Do Right Now
If you self-host n8n, here is the minimum action list.
Patch Immediately
The minimum safe version as of February 2026 is n8n 2.5.2 (or 1.123.17 for the 1.x branch). This covers all disclosed CVEs including CVE-2026-25049. Check your version:
n8n --version
# or for Docker:
docker exec n8n-container n8n --version
If you are on anything older, upgrade now. Not tomorrow. Now.
Restrict Webhook Access
Put your n8n instance behind a reverse proxy (Nginx, Caddy, Traefik) that requires authentication for all endpoints except the specific webhook paths your integrations need. Block all direct access to the n8n UI and API from the public internet.
# Example: restrict n8n access to VPN/internal network
server {
listen 443 ssl;
server_name n8n.yourcompany.com;
# Allow webhook paths from anywhere
location /webhook/ {
proxy_pass http://localhost:5678;
}
# Require VPN/internal IP for everything else
location / {
allow 10.0.0.0/8;
deny all;
proxy_pass http://localhost:5678;
}
}
Audit Workflow Permissions
n8n supports role-based access control in its paid tiers. If you are on the community edition, every user with access can create workflows with Execute Command nodes. Restrict who has access to your n8n instance to only the people who genuinely need it.
Monitor for Exploitation
Check your n8n logs for suspicious webhook requests, particularly:
- Requests to webhook endpoints with
Content-Type: application/jsonthat containfilepathorfileskeys in the body - Workflows created with Execute Command nodes that you did not author
- Unusual outbound network connections from the n8n container
Consider Your Deployment Model
If you run n8n for AI workflow automation with access to sensitive credentials (API keys, database connections, OAuth tokens), consider whether self-hosting is still the right choice. n8n Cloud handles patching automatically. The trade-off is control vs. security maintenance burden.
The Bigger Picture: Workflow Platforms as Attack Targets
n8n is not uniquely insecure. It is uniquely popular, open-source, and frequently self-hosted, which makes it a higher-value target and means vulnerabilities get found and disclosed publicly. Closed-source platforms like Zapier and Make have their own security risks, but their attack surface is managed by the vendor rather than by every individual operator.
The pattern here matters more than the specific CVEs. Workflow automation platforms are becoming the connective tissue of enterprise AI systems. They hold API keys for dozens of services, process sensitive customer data, and increasingly orchestrate AI agent actions. When a workflow platform is compromised, the blast radius extends to every system it connects to.
The OWASP Top 10 for LLM Applications already warns about insecure plugin design and excessive agency. n8n’s CVE cluster is what those warnings look like in practice: a platform that grants broad system access, running user-supplied code, exposed to the internet.
Patch your instances. Lock down your webhooks. And treat your workflow automation platform with the same security rigor you apply to your production database, because it probably has the credentials to access it.
Frequently Asked Questions
What is CVE-2026-21858 (Ni8mare) and why is it so critical?
CVE-2026-21858 is an unauthenticated remote code execution vulnerability in n8n with a CVSS score of 10.0, the maximum possible. It exploits a content-type confusion flaw in webhook handlers to read arbitrary files from the server, extract admin credentials, forge session tokens, and execute system commands. No login is required. Any n8n instance with a Form or Webhook trigger exposed to the network is vulnerable. It affects versions 1.65.0 through 1.120.4 and is fixed in version 1.121.0.
What is the minimum safe n8n version as of February 2026?
The minimum safe version is n8n 2.5.2 (or 1.123.17 for the 1.x branch). This version includes patches for all known critical CVEs, including CVE-2026-21858 (Ni8mare, CVSS 10.0), CVE-2026-25049 (expression escape, CVSS 9.4), and CVE-2026-21877 (arbitrary file write, CVSS 9.9).
How many CVEs were disclosed against n8n in late 2025 and early 2026?
At least eight critical and high-severity CVEs were disclosed between December 19, 2025 and February 7, 2026. These include three expression injection and sandbox escape vulnerabilities, two unauthenticated RCE bugs (including the CVSS 10.0 Ni8mare), and multiple command injection and XSS flaws. Eleven additional vulnerabilities were disclosed in the February 2026 batch.
Is n8n Cloud affected by these vulnerabilities?
n8n Cloud instances were patched by the n8n team as soon as fixes were available, so they are no longer vulnerable. However, self-hosted n8n instances depend on operators manually upgrading to the patched versions. The majority of exploit attempts observed in the wild targeted self-hosted instances that had not yet been updated.
Can these n8n vulnerabilities be exploited without authentication?
Yes. CVE-2026-21858 (Ni8mare) is fully unauthenticated and requires only network access to an n8n webhook endpoint. CVE-2026-25049, while requiring authentication in its base form, can also be exploited without credentials when combined with public webhook triggers. Any n8n instance directly exposed to the internet without a reverse proxy is at risk.