CVE-2025-68613: Remote Code Execution in n8n Workflow Expression Evaluator

CVE ID: CVE-2025-68613 Vendor: n8n Product: n8n (workflow automation platform) Vulnerability Type: Improper Control of Dynamically-Managed Code Resources (CWE-913) Attack Vector: Network CISA KEV Patch Deadline: 2026-03-25 (federal agencies)

Technical Description

CVE-2025-68613 is a remote code execution vulnerability rooted in n8n's workflow expression evaluation system. The flaw stems from improper control of dynamically managed code resources — specifically, the platform fails to adequately sandbox or validate code executed dynamically during workflow expression evaluation.

When n8n processes workflow expressions, it evaluates user-supplied input as executable code without enforcing sufficient isolation boundaries. An attacker who can create or modify a workflow — either through authenticated access or through an unauthenticated attack surface if the n8n instance is publicly exposed — can inject malicious expressions that execute arbitrary operating system commands on the host server. Code execution occurs under the privileges of the n8n process itself, which in many deployments runs with broad system access.

The vulnerability resides in the expression evaluation engine that n8n uses to allow dynamic data transformations within automation workflows. Because this functionality is core to how n8n operates, disabling it entirely is not a practical mitigation without degrading platform functionality.

Attack Surface and Exploitation Conditions

Exploitation requires the ability to create or modify a workflow within the target n8n instance. This condition is met under several realistic deployment scenarios:

  • Publicly exposed instances with no authentication or weak authentication controls allow unauthenticated attackers to reach the workflow editor directly.
  • Multi-tenant or shared instances where untrusted users hold workflow creation permissions can be exploited by any of those users.
  • Compromised accounts with workflow access provide a direct path to server-level code execution, escalating what would otherwise be a credential compromise into full host takeover.

Once an attacker crafts a malicious expression and triggers workflow execution, arbitrary commands run server-side. Depending on the deployment environment, this enables credential theft, lateral movement to connected systems and APIs that n8n has configured integrations with, data exfiltration, and persistence mechanisms on the underlying host.

n8n is widely used in enterprise automation pipelines and frequently holds credentials for dozens of third-party services — databases, cloud platforms, SaaS applications, and internal APIs. A successful RCE attack against a production n8n instance therefore carries a blast radius that extends well beyond the n8n host itself.

Real-World Impact

Organizations running n8n as part of their internal automation infrastructure face direct risk if any of the following conditions apply:

  • The n8n web interface is reachable from the internet or untrusted network segments.
  • Non-administrative users hold workflow creation or editing rights.
  • n8n runs with host-level or elevated container privileges.
  • The n8n instance stores credentials for critical internal or cloud systems.

Federal civilian executive branch (FCEB) agencies are bound by CISA's Known Exploited Vulnerabilities (KEV) catalog directive and must remediate this vulnerability by March 25, 2026. Non-federal organizations should treat the KEV listing as an indicator of active exploitation risk and prioritize remediation accordingly.

Patching and Mitigation Guidance

1. Apply vendor patches immediately. Monitor the n8n GitHub repository and official release notes for a patched version addressing CVE-2025-68613. Apply the patch as soon as it is available. Do not wait for a scheduled maintenance window given the severity of this vulnerability.

2. Audit existing workflows for malicious expressions. Review all workflows in active instances for unexpected or obfuscated expressions, particularly those using JavaScript execution nodes, $eval, or similar dynamic code constructs. Treat any unrecognized workflow as potentially malicious.

3. Restrict workflow creation permissions. Limit the ability to create or modify workflows to explicitly authorized and trusted users. Remove workflow editing rights from all accounts that do not require them. Enforce multi-factor authentication on all accounts with workflow access.

4. Block external access to n8n interfaces. If the n8n web interface is currently reachable from the internet, restrict access immediately via firewall rules, VPN requirements, or network segmentation. n8n should not be directly internet-facing unless absolutely necessary, and even then only behind strong authentication controls.

5. Isolate n8n from sensitive network segments. Segment n8n away from production databases, internal APIs, and other critical systems. Apply least-privilege networking controls so that even a compromised n8n process cannot reach high-value targets directly.

6. Run n8n in a hardened container. As a compensating control while awaiting the patch, deploy or redeploy n8n in a container with a restricted security profile — drop unnecessary Linux capabilities, apply a restrictive seccomp profile, and avoid running as root. This limits the impact of any successful code execution to the container environment rather than the underlying host.

7. Enable and monitor workflow execution logs. Configure logging for workflow execution events and monitor for anomalous expression patterns, unexpected system calls, or outbound network connections initiated from the n8n process. Integrate these logs into your SIEM for alerting.

Summary of Required Actions

| Action | Priority | |---|---| | Apply n8n patch when released | Critical / Immediate | | Audit workflows for malicious content | Critical / Immediate | | Restrict workflow creation permissions | Critical / Immediate | | Block public internet access to n8n | Critical / Immediate | | Network-segment n8n from critical systems | High | | Harden container runtime configuration | High | | Enable SIEM logging for workflow events | High |

SOC teams should add detection rules for unusual process spawning from the n8n service account and monitor for outbound connections to unexpected destinations originating from n8n hosts. CISOs should inventory all n8n deployments — including shadow IT instances — and confirm remediation status before the CISA KEV deadline.