Commissioned, Curated and Published by Russ. Researched and written with AI.
What’s New
CISA added CVE-2025-68613 to the Known Exploited Vulnerabilities catalogue on March 11, 2026, with a federal patch deadline of March 25. The Shadowserver Foundation is tracking 24,700+ unpatched n8n instances still exposed on the public internet – three months after the patch was released.
Changelog
| Date | Summary |
|---|---|
| 12 Mar 2026 | Initial publication. |
CISA added CVE-2025-68613 to the Known Exploited Vulnerabilities catalogue on March 11, 2026. The vulnerability is a 9.9 CVSS remote code execution flaw in n8n, the open-source workflow automation platform. The patch has been available since December 2025. According to the Shadowserver Foundation, 24,700+ instances remain unpatched and publicly accessible today.
That number is not an estimate of potential targets. Those are confirmed, internet-facing, unpatched n8n deployments, actively reachable right now.
What n8n is and why it’s the target
n8n is a self-hosted, node-based workflow automation tool – the closest self-hosted equivalent to Zapier. Engineers building AI agent pipelines reach for it specifically because it runs on your own infrastructure. You control the data, the integrations, the credentials. No vendor lock-in, no SaaS pricing surprises.
That positioning makes n8n the hub of a lot of sensitive connectivity. A typical AI automation stack connects n8n to: LLM APIs (OpenAI, Anthropic), internal databases, Slack and email, cloud storage, internal services. Every integration means a stored credential. Every credential means an attack surface.
This is the structural problem. An n8n instance is not just a server – it is a credential aggregator. Compromise the n8n process and you don’t get one set of secrets. You get all of them.
This is also why n8n is the target, not an incidental victim. The same architectural decisions that make it useful for AI pipelines – broad integrations, stored API keys, service account privileges – make it a high-value target for attackers who understand what’s inside.
CVE-2025-68613: expression injection into RCE
n8n workflows transform data between nodes using expressions. The syntax is familiar to anyone who’s used templating engines: {{ $json.field }}, {{ $node["HTTP Request"].json.body }}. These expressions are evaluated server-side to pass data between workflow steps.
CVE-2025-68613 exploits that evaluation engine. Under certain conditions, an authenticated attacker can inject arbitrary code into workflow expressions. When the workflow executes, the injected code runs with the privileges of the n8n service process.
The CISA advisory describes it as “improper control of dynamically managed code resources.” The n8n advisory is more specific: authenticated users with permission to create or modify workflows can craft expressions that trigger unintended system command execution on the host.
The critical phrase there is “with the privileges of the n8n process.” If n8n is running as root, or with broad filesystem and network access (common in developer setups), an attacker who lands expression injection gets everything. Database connections, API keys, filesystem access, cloud credentials – whatever the n8n process can reach.
The authentication requirement does limit the attack surface relative to a fully unauthenticated bug. But it doesn’t require admin credentials. n8n’s advisory confirms that low-privilege accounts with workflow edit access are sufficient. In organisations that treat the n8n interface as a developer tool rather than an admin surface, that bar is often easy to clear – via credential stuffing, phishing, a stolen API key, or a disgruntled insider.
The CVSS score of 9.9 reflects this. One expression injection on an instance with typical permissions means full compromise of the n8n host and every service it connects to.
For more on the underlying principle – why agent pipeline components need tight privilege separation – the agent pipeline hardening post covers this in depth.
CVE-2026-21858: the unauthenticated problem
The expression injection flaw is serious. The second vulnerability is worse.
CVE-2026-21858, disclosed at the start of 2026 and nicknamed “ni8mare” by the researchers who found it, carries a CVSS score of 10.0 – maximum severity. The attack vector: improper handling of webhooks, requiring zero authentication.
n8n webhooks are publicly accessible HTTP endpoints that trigger workflows on external events. They are intentionally internet-facing by design. If you’ve ever integrated an n8n workflow with a GitHub webhook, a Stripe payment event, or a form submission, you’ve used them. They’re a core feature.
CVE-2026-21858 turns those endpoints into an unauthenticated RCE surface. Any internet-accessible n8n instance with webhooks enabled – which describes most production deployments – is a target. No credentials needed. No social engineering. Send a crafted request, execute code on the host.
The Register described it plainly: attackers get “free rein of an n8n instance without the need for authentication.” That’s the correct framing. It is not a targeted attack – it is a scan-and-exploit operation. Shodan or Censys, identify n8n instances, fire malicious webhook payloads at scale. The 24,700 exposed instances are not just vulnerable to CVE-2025-68613. They are, if also unpatched for CVE-2026-21858, exploitable by anyone on the internet who can run a script.
The 24,700 problem
The patch for CVE-2025-68613 shipped in December 2025, in versions 1.120.4, 1.121.1, and 1.122.0. CISA added it to the KEV catalogue three months later, in March 2026. In between: no mass patching. 24,700+ instances remained exposed, 12,300+ in North America, 7,800+ in Europe.
This is the self-hosted maintenance problem in concrete form.
SaaS tools patch automatically. The vendor deploys; users get the update. There’s no action required, and no window where 24,000 instances sit unpatched in production.
Self-hosted tools work differently. The operator is responsible for updates. That means someone has to notice the advisory, evaluate it, schedule downtime, test the update, and deploy it. For teams with mature ops practices, that process happens in days. For developers who stood up n8n to automate their AI pipeline and moved on to the next problem, it often doesn’t happen at all.
This is not a criticism of n8n as a project. It’s a structural characteristic of self-hosted software. The same autonomy and control that make self-hosting appealing – the whole case is made in detail at russellclare.com/ai-self-hosting/ – require the operator to take on the maintenance responsibility that a SaaS vendor would otherwise handle.
When the software is a workflow automation tool used in AI agent pipelines, with credentials for every integrated service stored in the database, the cost of ignoring that maintenance responsibility is substantial. The 24,700 exposed instances represent organisations who have taken on the self-hosting trade-off without the security operations to back it up.
The n8n vulnerability situation has also continued to develop. Researchers found a third set of flaws (CVE-2026-25049, CVSS 9.4) in early February 2026, exploiting additional paths through the expression evaluation engine. Three critical RCE chains in the same system in three months. This isn’t a one-off – it’s a sign that the expression evaluation attack surface is being systematically researched, and that unpatched instances are staying in the crosshairs.
For a broader look at AI tooling as an attack surface, the AI cloud threat post covers this pattern across the stack.
What to do right now
If you run n8n, in any environment, work through this list in order.
1. Patch immediately. Update to n8n 1.120.4, 1.121.1, or 1.122.0 minimum to address CVE-2025-68613. Check the n8n security advisories for the current patch state on CVE-2026-21858 and CVE-2026-25049 – both require separate patches. Run the newest stable release available.
2. Take the instance off the public internet. n8n has no business being directly internet-accessible. Put it behind a VPN or restrict to internal network access. If you need external webhook endpoints, run a proxy or relay that accepts the incoming requests and forwards them to n8n internally – do not expose the n8n process itself.
3. Treat workflow edit access as admin access. The expression injection requires a user with workflow edit permissions. Review who has that access. Revoke it from anyone who doesn’t need it. If your team treats the n8n UI as a general developer tool, change that policy now.
4. Rotate every stored credential. If your instance was exposed to the internet while unpatched, assume the credentials stored in it are compromised. Rotate every API key, database password, and service account token that n8n has access to. All of them. Don’t triage – rotate everything.
5. Run n8n as a least-privilege service account. The expression injection runs with the privileges of the n8n process. If that process is root, or has broad filesystem access, the blast radius is maximum. n8n does not need root. Create a dedicated service account with the minimum permissions required and run the process under it.
6. Enable audit logging and review it. n8n logs workflow execution. If you haven’t reviewed those logs since December, do it now. Look for unexpected workflow creation, new expressions in existing workflows, or execution patterns that don’t match your normal usage.
7. Subscribe to n8n security advisories. The GitHub advisory feed at github.com/n8n-io/n8n is the canonical source. If you’re running self-hosted software in production, you need a process for tracking its security advisories. This is the minimum baseline for operating self-hosted tooling responsibly.
The trade-off, made concrete
Self-hosted AI infrastructure gives you control over your data, your integrations, and your costs. That case is real and the trade-off is often worth making. But control is not passive – it requires active maintenance.
n8n is the most prominent example right now, but it is not unique. Any self-hosted workflow automation tool has a similar attack surface: an expression or scripting engine that executes code in the context of a process with broad credentials. The same analysis applies to Airflow, Prefect, Temporal, and most tools in this category. The question is not whether they have vulnerabilities – they do – but whether you have the processes to patch them when those vulnerabilities are disclosed.
Three months elapsed between a 9.9 CVSS patch and CISA adding it to the KEV catalogue. In that window, 24,700+ organisations made themselves available to attackers who had already reverse-engineered the flaw. Some of those instances are almost certainly compromised already.
Check your instances. Know what version you’re running. If you don’t know, find out before you read the next thing.