CISA has added CVE-2025-68613 — a critical remote code execution (RCE) vulnerability in the n8n workflow automation platform — to its Known Exploited Vulnerabilities (KEV) Catalog, citing evidence of active exploitation and triggering mandatory remediation requirements for affected federal agencies under Binding Operational Directive 22-01. This designation elevates the issue from a vendor advisory to an operational imperative for the Federal Civilian Executive Branch (FCEB), and it should serve as a wake-up call for every organization using self-hosted or improperly hardened n8n instances.
n8n is a popular open-source workflow automation tool used to connect services, orchestrate integrations, and run lightweight automation jobs without heavy engineering. Because n8n often stores API keys, OAuth tokens, database credentials, and other sensitive secrets inside workflows or the instance configuration, a vulnerability that allows expression injection or code execution can produce catastrophic downstream effects.
CISA’s KEV Catalog is the U.S. government’s list of CVEs for which there is evidence of exploitation in the wild. Under BOD 22-01, FCEB agencies must remediate KEV-listed vulnerabilities by specified deadlines; while that order applies to federal civilian agencies, CISA explicitly recommends that all organizations prioritize remediation for KEV items. The agency’s recent addition makes CVE-2025-68613 an operational priority.
An attacker who can create or edit workflows (authenticated but not necessarily privileged beyond workflow editing) can craft specially formatted expressions that bypass the expression evaluator’s safeguards. Those expressions can reach into the Node.js environment, require native modules like child_process, and execute system-level commands with the privileges of the n8n process. That sequence yields remote code execution, arbitrary file reads, theft of stored secrets, and potential full instance takeover.
CISA’s placement of CVE-2025-68613 into the KEV Catalog on March 11, 2026 reflects the agency’s assessment that credible evidence of exploitation exists. The KEV designation typically follows reports of active in-the-wild use or reliable intelligence indicating abuse of a vulnerability against operational targets.
However, the public picture of exploitation is mixed. Some security firms and incident responders reported PoCs and attempted scans; others noted no widespread exploitation campaigns at the time of their writing. The KEV designation should be interpreted as a conservative operational signal: treat the vulnerability as actively exploitable and urgent even if you have not yet observed malicious activity in your environment.
Because proof-of-concept code and exploit repositories have proliferated, the difficulty of weaponizing the issue is decreasing. That increases the chance of opportunistic scans and automated compromise attempts, especially against internet-exposed n8n instances or poorly segmented internal deployments.
Organizations running n8n — whether self-hosted or managed — need to act now. Patch, restrict authoring rights, rotate secrets, and hunt for indicators of compromise. More broadly, this incident demonstrates that automation tooling requires enterprise-grade security controls, continuous monitoring, and a posture that assumes compromise until proven otherwise.
If your organization runs n8n or relies on third-party services that integrate with it, treat this as a priority incident: inventory, patch, and verify. The combination of a readily weaponizable vulnerability, proliferating proof-of-concept material, and evidence of in-the-wild exploitation means the risk window is open and shrinking by the day.
Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA
n8n is a popular open-source workflow automation tool used to connect services, orchestrate integrations, and run lightweight automation jobs without heavy engineering. Because n8n often stores API keys, OAuth tokens, database credentials, and other sensitive secrets inside workflows or the instance configuration, a vulnerability that allows expression injection or code execution can produce catastrophic downstream effects.CISA’s KEV Catalog is the U.S. government’s list of CVEs for which there is evidence of exploitation in the wild. Under BOD 22-01, FCEB agencies must remediate KEV-listed vulnerabilities by specified deadlines; while that order applies to federal civilian agencies, CISA explicitly recommends that all organizations prioritize remediation for KEV items. The agency’s recent addition makes CVE-2025-68613 an operational priority.
What is CVE-2025-68613?
The technical gist
CVE-2025-68613 is categorized under CWE-913: Improper Control of Dynamically-Managed Code Resources — in plain language, the n8n expression evaluation engine previously allowed user-supplied expressions to escape intended sandboxing and invoke underlying JavaScript/Node.js runtime capabilities that should have been off-limits.An attacker who can create or edit workflows (authenticated but not necessarily privileged beyond workflow editing) can craft specially formatted expressions that bypass the expression evaluator’s safeguards. Those expressions can reach into the Node.js environment, require native modules like child_process, and execute system-level commands with the privileges of the n8n process. That sequence yields remote code execution, arbitrary file reads, theft of stored secrets, and potential full instance takeover.
Affected versions and fixes
- The vulnerability affects n8n versions starting from an older baseline (0.211.0 and later branches) up through several 1.x release lines that were not yet patched.
- Vendor and public vulnerability data indicate that the issue has been fixed in specific releases. Users running earlier versions should upgrade to one of the patched releases listed by n8n to remediate the flaw.
- Because n8n is distributed both as a self-hosted server and as a managed/cloud offering by third parties, administrators must verify the version and update path for their specific deployment model.
Timeline and vendor response
n8n maintainers published security advisories and backported fixes to multiple release branches after disclosure. The initial fix closed the primary sandbox escape vector, and follow-on patches addressed additional bypasses identified by researchers and threat actors. Despite the patches, security researchers and follow-up advisories later documented chained exploitation techniques and additional expression-evaluation bypasses that required further fixes.CISA’s placement of CVE-2025-68613 into the KEV Catalog on March 11, 2026 reflects the agency’s assessment that credible evidence of exploitation exists. The KEV designation typically follows reports of active in-the-wild use or reliable intelligence indicating abuse of a vulnerability against operational targets.
Why this matters: risk to organizations
- n8n instances are high-value targets. They will often hold API credentials, OAuth refresh tokens, database credentials, cloud service keys, and other persistent secrets used to automate workflows. Compromise of an n8n instance often yields lateral access to the very systems that automation integrates.
- The exploitation path is easy to reach for attackers who already control a user account with workflow creation or editing permission. Many organizations grant those permissions too broadly.
- The vulnerability’s nature — dynamic code execution via an expression language — makes detection and prevention by standard input sanitization or naive filters difficult.
- For cloud or containerized n8n deployments, a compromised container can be used to gain access to private networks, cloud metadata endpoints, or escalate to the host if improperly configured.
Evidence and exploitation landscape
CISA’s KEV entry signals that there is at least some confirmed exploitation. Public reporting shows multiple security teams and vendors publishing proof-of-concept code and technical write-ups demonstrating how expression injection could be weaponized to read sensitive files and spawn OS commands.However, the public picture of exploitation is mixed. Some security firms and incident responders reported PoCs and attempted scans; others noted no widespread exploitation campaigns at the time of their writing. The KEV designation should be interpreted as a conservative operational signal: treat the vulnerability as actively exploitable and urgent even if you have not yet observed malicious activity in your environment.
Because proof-of-concept code and exploit repositories have proliferated, the difficulty of weaponizing the issue is decreasing. That increases the chance of opportunistic scans and automated compromise attempts, especially against internet-exposed n8n instances or poorly segmented internal deployments.
Immediate actions for administrators (practical remediation checklist)
- Inventory: Identify all n8n instances across cloud, on-premises, development, and ephemeral environments. Don’t forget test and sandbox environments connected to production services.
- Emergency upgrade: Patch affected instances to the vendor-specified patched releases immediately. If you cannot upgrade immediately, apply mitigations listed below.
- Restrict authoring permissions: Limit workflow creation and editing privileges to a small set of fully trusted users. Assume any account with authoring rights is a privilege target.
- Rotate secrets: After patching, rotate all API keys, OAuth tokens, service accounts, and other secrets stored in n8n or referenced by workflows. Assume secrets may have been exfiltrated.
- Harden the runtime: Run n8n with the least possible container/OS privileges, disable mounting of host directories into containers unless required, and restrict outbound network access.
- Network segmentation: Ensure n8n instances are isolated from sensitive network zones. Block access to cloud metadata endpoints and internal admin interfaces from the automation runtime.
- Audit and incident hunt: Search logs and workflow histories for signs of unauthorized workflow creation, sudden exports of secrets, process spawn logs, or unexpected outbound connections.
- Rebuild if compromised: If you find evidence of exploitation, rebuild the instance from known-good images, restore workflows from clean backups, and re-provision secrets from scratch.
Recommended mitigations if you cannot patch immediately
- Limit workflow editing rights to trusted groups and enforce strong authentication (MFA) for those accounts.
- Apply host-level restrictions so the n8n process runs under a dedicated low-privilege user with no sudo access.
- Use network controls (firewalls, security groups) to prevent the n8n instance from reaching unnecessary internal resources or cloud provider metadata endpoints.
- Deploy Web Application Firewalls (WAFs) or runtime application security controls to detect anomalous expressions or pattern-based attacks on the administration or API surfaces.
- Monitor and block known exploit patterns at the perimeter (for example, suspicious payloads attempting to load child_process or process access in expressions).
- Temporarily disable anonymous or self-service account registration if your deployment exposes such functionality.
Detection: what to look for
- Unexpected child processes spawned by the n8n runtime (for Node.js, look for unexpected invocations of child_process or spawned shell binaries).
- Workflow creation or edits from accounts that shouldn’t be authoring workflows, especially around times of suspicious outbound connections.
- Unusual outbound traffic from the n8n host to unknown IPs or domains, especially around command-and-control patterns or data exfil targets.
- Access or reads of configuration files or the instance’s storage export that include secret keys or tokens.
- Sudden changes to connectors, new HTTP requests to internal services, or new cloud API calls originating from the n8n service account.
For cloud-managed n8n users and platform operators
- If you use a vendor-managed n8n service, check vendor advisories and status pages for where their instances run and whether they’ve applied the patches. Managed providers may have updated instances, but you still need to rotate tokens and verify integrations for suspicious activity.
- For Kubernetes deployments, rotate secrets stored in ConfigMaps or Secrets, and redeploy pods from updated images built from patched application code.
- For multi-tenant or SaaS providers hosting n8n for clients, prioritize communication to customers, offer detection and triage assistance, and provide a clear remediation timeline.
Why vulnerability chaining matters here
Expression-evaluation flaws like CVE-2025-68613 are especially dangerous because they can be chained with other weaknesses. For example:- A sandbox escape in an expression engine, combined with a misconfigured storage mount, can let an attacker write persistent backdoors.
- An RCE in a workflow engine plus stored API keys can give attackers access to dozens of third-party systems.
- Several follow-up advisories documented additional expression parsing bypasses that could be chained to achieve full host compromise even after initial fixes.
Operational critique: what went right and what went wrong
Strengths and positives
- The vendor responded with patches and public advisories across multiple release branches, demonstrating a coordinated disclosure and remediation effort.
- The n8n community and many security vendors rapidly analyzed the issue, produced detection guidance, and published mitigation steps.
- CISA’s KEV designation provides the hard operational lever necessary to force federal patching and encourages private-sector prioritization.
Weaknesses and persistent risks
- The underlying design trade-offs of expression languages and dynamic evaluation in workflow engines present a perennial attack surface that is difficult to fully sandbox.
- Patch rollouts were followed by additional bypass discoveries, showing that initial mitigations can be incomplete and that follow-through and regression testing across all expression vectors are vital.
- Too many organizations grant workflow authoring permissions too widely or run n8n with overly permissive host privileges — operational practices that magnify the blast radius of any flaw.
- Public PoCs and exploit code proliferated quickly, lowering the bar for opportunistic attackers.
Long-term lessons and strategic recommendations
- Treat workflow automation platforms as critical infrastructure. They are not mere convenience tools; they are high-value integration points that must receive the same security rigor as application servers and service accounts.
- Adopt least-privilege models for workflow creation and execution. Separate roles for operators, authors, and administrators; require MFA and strong auditing for authoring roles.
- Move sensitive secrets out of application-managed storage when feasible. Use dedicated secret-management solutions with auditable rotation and access policies rather than embedding long-lived keys in workflows.
- Build secure CI/CD and patch management pipelines that allow rapid rollout of security fixes and quick rollback if regressions occur.
- Run regular threat-hunting exercises focused on automation tooling, looking for lateral movement paths that begin with credential theft from orchestrators.
Incident response playbook (concise)
- Identify: Inventory all n8n instances and their versions; identify exposed or internet-facing endpoints.
- Contain: Isolate compromised or at-risk instances from internal networks and revoke any service account tokens associated with them.
- Patch: Apply vendor-provided patches to all affected instances or rebuild on patched images.
- Rotate: Replace all secrets and credentials stored in the instance and in connected integrations.
- Hunt: Look for indicators of compromise (suspicious process creation, unknown outbound connections, unauthorized workflow changes).
- Remediate: Rebuild or re-provision compromised hosts from clean images; restore workflows from backups verified to be pre-compromise.
- Report: Follow any required reporting channels for your sector; FCEB agencies must follow BOD 22-01 remediation procedures and deadlines.
Final assessment
CVE-2025-68613 is a high-impact vulnerability with real-world implications: the ability to execute arbitrary code on automation platforms that coordinate across many services is one of the most dangerous classes of flaws in modern stacks. CISA’s decision to add the CVE to the KEV Catalog elevates the threat from “urgent” to “mission-critical” for federal agencies and should prompt immediate action across the private sector.Organizations running n8n — whether self-hosted or managed — need to act now. Patch, restrict authoring rights, rotate secrets, and hunt for indicators of compromise. More broadly, this incident demonstrates that automation tooling requires enterprise-grade security controls, continuous monitoring, and a posture that assumes compromise until proven otherwise.
If your organization runs n8n or relies on third-party services that integrate with it, treat this as a priority incident: inventory, patch, and verify. The combination of a readily weaponizable vulnerability, proliferating proof-of-concept material, and evidence of in-the-wild exploitation means the risk window is open and shrinking by the day.
Source: CISA CISA Adds One Known Exploited Vulnerability to Catalog | CISA