CISA adds critical n8n RCE (CVE-2025-68613) to KEV list. Learn how this 9.9 CVSS flaw allows full instance takeover and how to patch your workflows today.
What CVE-2025-68613 Enables
CVE-2025-68613 is a remote code execution flaw in n8n with a 9.9 CVSS score. In practice, that means an attacker who can reach a vulnerable instance may run arbitrary code in the process that powers the automation engine. Once that code runs, the attacker is no longer limited to a single workflow step: they can control the host process, read secrets the instance holds, and alter or create workflows that act with the same privileges as the n8n service.
Full instance takeover follows from that access path. Credentials stored for databases, APIs, and cloud services become available to the attacker. Scheduled and webhook-triggered workflows can be rewritten to exfiltrate data or pivot into connected systems. Because n8n sits at the center of many integration graphs, a single compromised instance often has more reach than a standalone app server.
Why CISA KEV Listing Changes the Priority
CISA’s Known Exploited Vulnerabilities (KEV) catalog is reserved for issues that are actively exploited in the wild, not merely theoretically severe. When a flaw lands on that list, the operational message is clear: treat remediation as urgent, not as a backlog item for the next maintenance window. For teams that run n8n on self-hosted or private infrastructure, KEV status should override “we are not a high-profile target” assumptions.
KEV also matters for process and compliance. Many security programs map KEV items to fixed response SLAs. Even if your org has no formal KEV policy, the listing is a strong signal that public exploit activity exists and that delay increases exposure. Prioritize inventory of every n8n deployment—production, staging, and forgotten sandboxes—before you assume you are clear.
How to Patch and Reduce Exposure Today
Start with upgrade. Apply the vendor-fixed n8n release as soon as you can validate it in a non-production environment, then promote to production. Do not rely on “we only allow trusted users” as a substitute for the patch if the instance is reachable from a network path an attacker can use. After upgrading, restart services cleanly and confirm the running version matches the fixed build.
- Inventory all n8n hosts, containers, and managed deployments, including developer machines that expose ports.
- Restrict network access: put admin and webhook endpoints behind auth, VPN, or allowlists where possible.
- Rotate secrets the instance could access—API keys, OAuth tokens, database passwords—after any period of uncertainty about compromise.
- Review recent workflow changes, credentials usage, and unusual outbound traffic from the n8n host.
- Disable unused community nodes and limit who can create or edit workflows until the environment is confirmed clean.
If you cannot patch immediately, reduce the attack surface: isolate the instance on a private network, block public inbound access except for required webhooks, and monitor process and network activity for unexpected child processes or large outbound transfers. Isolation buys time; it does not replace the fix.
What to Check After You Patch
Treat remediation as incomplete until you verify behavior, not only version strings. Confirm workflows still run as expected after the upgrade, then audit for signs of prior abuse: new or modified workflows you did not authorize, credentials that were recently added or used, and webhook URLs that should not exist. Check logs for anomalous executions around the time the issue became public knowledge on the KEV list.
Finally, encode the lesson into operations. Keep n8n on a short update cadence, track CVEs against your automation stack the same way you track them for production apps, and document who owns n8n security. A 9.9 RCE that enables full instance takeover is rare in severity; the practical response is routine: patch fast, assume lateral risk, and prove the instance is still under your control.