CISA adds n8n expression-injection RCE (CVE-2025-68613) to its exploited list

On 11 March 2026 CISA added CVE-2025-68613, a critical remote code execution bug in the n8n workflow automation platform, to its Known Exploited Vulnerabilities (KEV) catalog. It is the first n8n flaw on that list. If your team self-hosts n8n to glue together APIs, databases and AI pipelines, assume the instance holds some of your most valuable credentials. A logged-in attacker who can edit a workflow could run code as the n8n process.

What happened

n8n's maintainers fixed CVE-2025-68613 in December 2025. It carries a CVSS score of 9.9. The bug sits in n8n's workflow expression evaluation system, the feature that lets you write {{ ... }} expressions inside node parameters. Under some conditions, expressions supplied by an authenticated user were evaluated without enough isolation from the underlying Node.js runtime. That let the user break out and run arbitrary code with the privileges of the n8n process.

When CISA added the CVE to KEV on 11 March 2026, it set a 25 March deadline for US Federal Civilian Executive Branch agencies under Binding Operational Directive 22-01 and urged every other organisation to patch as well. Neither CISA nor n8n published details of the observed attacks.

Exposure figures depend on the source and the date. The Hacker News, citing Shadowserver, reported more than 24,700 unpatched instances online as of early February 2026. BleepingComputer's report on the KEV listing cited a Shadowserver count of over 40,000. Either way, a large number of internet-facing n8n servers were still unpatched months after the fix shipped.

The KEV listing came on top of other serious n8n bugs. In January 2026 n8n fixed CVE-2026-21858, nicknamed "Ni8mare," which let unauthenticated attackers abuse public webhook and form endpoints on versions 1.65.0 through 1.120.x. In March, researchers disclosed further critical issues in the same expression engine, including CVE-2026-27577.

Who is affected

• Self-hosted n8n (npm package, Docker image or source install) on versions 0.211.0 through 1.120.3 and 1.121.0. The fixed releases are 1.120.4, 1.121.1 and 1.122.0. The advisory recommends 1.122.0 or later.
• Any account that can create or edit workflows. The attacker needs to be logged in, so the real exposure depends on who holds editor rights. Shared instances, agency setups where clients have access, and leaked user passwords all widen it.
• Everything n8n has credentials for. The n8n process can decrypt the credentials it stores, so code running inside it can reach your databases, SaaS API tokens, OAuth refresh tokens, cloud keys and CI/CD secrets.

What it means for developers and engineering teams

Workflow tools like n8n are effectively a secrets broker with a scripting engine attached. Expression languages are convenient because they evaluate JavaScript-like code at runtime. Putting a reliable boundary between that code and the host process is hard, and in an automation platform the process is the most privileged thing you run. The fact that n8n keeps fixing bugs in the same expression subsystem suggests that sandboxing is still not airtight.

Several lessons apply beyond n8n:

• "Authenticated" does not mean "low risk." A 9.9 score with an authentication requirement still means one phished editor account or one disgruntled contractor can compromise the server. Treat workflow-editor access as equivalent to shell access.
• Blast radius is a design choice. If n8n runs as root in a container with the Docker socket mounted, or on a VM with broad cloud IAM permissions, a code-execution bug becomes a host or account compromise. Least privilege at the OS and cloud layer is what limits the damage.
• Internet exposure is optional. Most teams only need the webhook endpoints to be public. The editor UI and REST API can sit behind a VPN, SSO proxy or IP allowlist.
• Stored credentials need rotation plans. If you can't quickly list and rotate every secret your n8n instance holds, you can't respond to a compromise.

What to do now

1. Check your version: look at Settings → About in the UI, or run docker exec <container> n8n --version. Upgrade to the latest 1.x or later release, which includes the fixes for CVE-2025-68613, CVE-2026-21858 and the March expression-engine bugs. For Docker: docker pull n8nio/n8n:latest and recreate the container.
2. Audit who can edit workflows. Remove stale users, require SSO or MFA, and drop editor rights for anyone who only needs to view or run workflows.
3. Take the editor off the public internet. Put the UI and /rest API behind a VPN, zero-trust proxy or allowlist, and expose only the webhook paths that need to be public.
4. Run n8n with least privilege: a non-root user, no Docker socket mount, a read-only root filesystem where possible, egress restricted to the services workflows actually call, and a scoped cloud IAM role.
5. Look for signs of compromise. Review recent workflow edits and executions you don't recognise, new users or API keys, unexpected child processes of the n8n process, and unexpected outbound connections.
6. If an instance was exposed and unpatched, rotate every credential stored in it, including the N8N_ENCRYPTION_KEY, and treat the host as untrusted until you've rebuilt it.

Related on TechLogHub

• n8n vs Zapier vs Make, including the self-hosted vs SaaS trade-off
• What is a webhook?
• Depna, a dependency vulnerability scanner

Sources

• CISA: CISA Adds One Known Exploited Vulnerability to Catalog (11 March 2026)
• GHSA-v98v-ff95-f3cp / CVE-2025-68613 advisory data (OSV)
• The Hacker News: CISA flags actively exploited n8n RCE
• BleepingComputer: CISA orders feds to patch n8n RCE flaw exploited in attacks
• Arctic Wolf: CVE-2026-21858 ("Ni8mare")