CVE-2025-68613

What it actually does

This vulnerability is a critical authenticated remote code execution flaw in n8n's workflow expression evaluation system. In affected versions from 0.211.0 before 1.120.4, 1.121.1, and 1.122.0, workflow expressions supplied by an authenticated user can be evaluated in a context that is insufficiently isolated from the underlying Node.js runtime. An attacker with workflow creation or editing privileges may escape the intended expression sandbox and execute arbitrary operating system commands with the privileges of the n8n process. Because n8n commonly stores workflow logic, credentials, API tokens, integrations, and automation secrets, successful exploitation can lead to instance takeover, credential theft, workflow tampering, lateral movement through connected services, and destructive system operations.

Why it matters to the business

A compromised n8n instance can expose business-critical automation credentials, modify or disable operational workflows, exfiltrate data from connected SaaS and internal systems, and provide an attacker with a foothold for broader intrusion. The issue is listed in CISA KEV with a remediation due date of 2026-03-25, has very high exploitation likelihood, and is reported as actively exploited in the wild, including association with the Interlock ransomware campaign. Organizations using n8n for automation should treat vulnerable instances as high-priority assets because compromise can cascade into many connected business processes and third-party services.

How an attack unfolds

An attacker first obtains authenticated access to an affected n8n instance, typically through stolen credentials, weak access controls, exposed administrative interfaces, or compromise of a lower-privileged account with workflow authoring rights. The attacker then creates or edits a workflow and supplies a malicious expression designed to break out of the intended evaluation restrictions. When n8n evaluates that expression during workflow configuration, testing, or execution, the expression can access the underlying runtime and cause the n8n process to execute attacker-controlled code. From there, the attacker may enumerate environment variables, read n8n configuration and credential stores, modify workflows for persistence, invoke outbound network connections, stage additional tooling, or use integrated credentials to access downstream systems. In ransomware-linked activity, this kind of access may be used to harvest credentials, expand access, disrupt automation, and prepare for extortion or encryption activity.

How to fix it

Upgrade n8n immediately to a fixed release: 1.120.4, 1.121.1, 1.122.0, or later. For source-based deployments of n8n-io/n8n, ensure the code includes fixed commit 6c484fd4e85bd12025ff13eb88c37e701b468bbe or a later trusted commit. Versions starting with 0.211.0 and earlier than the fixed releases should be considered vulnerable. If immediate upgrade is not possible, restrict workflow creation and editing to fully trusted administrators only, disable or limit public exposure of the n8n interface, enforce strong authentication and MFA, place n8n behind a VPN or access proxy, run the n8n process with minimal operating system privileges, restrict outbound network access, isolate the host or container from sensitive networks, and rotate credentials that n8n can access. These mitigations reduce impact but do not fully remove the vulnerability; patching is required.

How to confirm the fix worked

Confirm the installed n8n version is 1.120.4, 1.121.1, 1.122.0, or later, depending on the release track in use. For Git-based deployments, verify the deployed code contains commit 6c484fd4e85bd12025ff13eb88c37e701b468bbe or a later commit from the official n8n repository. Review package manifests, container image tags, application startup banners, administrative version displays, and deployment artifacts to ensure no vulnerable version remains. Validate that untrusted users cannot create or edit workflows, that administrative access requires MFA or equivalent controls, and that the n8n runtime runs as a non-root user with restricted filesystem and network permissions. After upgrading, restart all n8n workers and web processes, replace old containers or pods rather than reusing cached vulnerable images, and verify that workflow expression evaluation no longer has access to dangerous Node.js runtime primitives such as process, require, or child_process outside intended functionality.

Typical attack path

1. Identify an internet-accessible or reachable n8n instance running an affected version.
2. Obtain valid authentication through credential theft, password spraying, exposed accounts, session theft, or other access paths.
3. Use workflow creation or editing functionality to add an expression that is evaluated by the vulnerable expression engine.
4. Trigger expression evaluation through workflow testing, saving, execution, webhook invocation, or scheduled automation.
5. Execute arbitrary commands as the n8n operating system process user.
6. Collect secrets from environment variables, configuration files, n8n credential storage, workflow definitions, and connected integrations.
7. Modify workflows, create persistence mechanisms, or add malicious automation steps.
8. Use harvested credentials or network access to pivot into connected services or internal systems.
9. Optionally deploy additional payloads, exfiltrate data, disrupt workflows, or support ransomware operations.

How to detect it

Investigate both application-layer activity and host/container behavior. Review n8n audit logs, workflow history, workflow export JSON, database-backed workflow definitions, reverse proxy logs, identity provider logs, container runtime logs, process execution telemetry, EDR events, and outbound network telemetry. Look for recently created or modified workflows containing expressions that reference Node.js runtime escape patterns, process access, module loading, child process execution, encoded command strings, or network download utilities. Correlate suspicious workflow edits with execution events, webhook invocations, and child processes spawned by the n8n service account or container. On Linux containers and hosts, inspect shell history if available, container exec events, unexpected files in temporary directories, new cron entries, modified startup scripts, and outbound connections to unknown infrastructure. On Windows deployments, inspect PowerShell, cmd.exe, wscript/cscript, certutil, bitsadmin, and scheduled task activity launched by the n8n process. If Interlock ransomware activity is a concern, expand the hunt to credential theft, remote access tooling, unusual archive creation, data staging, lateral movement, and ransomware pre-encryption behaviors. Absence of a single known indicator should not be considered proof of no compromise because exploitation payloads may vary widely.

• require('child_process')
• require("child_process")
• child_process.exec
• child_process.execSync
• child_process.spawn
• child_process.spawnSync
• process.mainModule.require
• global.process
• constructor.constructor
• Function('return process')
• Function("return process")
• {{require(
• {{ require(
• {{process.
• {{ process.
• {{global.process
• {{ global.process
• /bin/sh -c
• /bin/bash -c
• cmd.exe /c
• powershell.exe -NoP
• powershell.exe -EncodedCommand
• curl http://
• curl https://
• wget http://
• wget https://
• nc -e
• ncat -e
• bash -i >& /dev/tcp/
• /tmp/
• /var/tmp/
• /home/node/.n8n
• /root/.n8n
• N8N_ENCRYPTION_KEY
• credentials_entity
• workflow_entity
• /rest/workflows
• /rest/workflows/
• /webhook/
• /webhook-test/

What your security team should do

• Treat all exposed vulnerable n8n instances as urgent due to active exploitation, KEV listing, high EPSS probability, and ransomware campaign association.
• Upgrade to n8n 1.120.4, 1.121.1, 1.122.0, or later as the primary remediation; do not rely on access restrictions as a long-term fix.
• Inventory all n8n deployments, including self-hosted containers, Kubernetes workloads, developer instances, and source-based installations.
• Temporarily restrict n8n administrative and workflow-editing access to trusted users only, preferably through VPN, SSO, MFA, and IP allowlisting.
• Review workflow change history for suspicious expressions, newly created workflows, unauthorized edits, unexpected webhook nodes, command execution patterns, or outbound data transfer logic.
• Hunt for evidence of command execution by the n8n process, especially shell, curl, wget, PowerShell, Python, Node.js child process, or reverse shell activity.
• Rotate n8n credentials, API tokens, OAuth secrets, environment secrets, and credentials for connected services if exploitation is suspected or cannot be ruled out.
• Restrict egress from n8n hosts or containers to only required destinations and monitor for unusual outbound connections.
• Back up and integrity-check workflow definitions before and after remediation to identify malicious persistence or unauthorized automation changes.
• Because the issue is in CISA KEV, align remediation with the 2026-03-25 deadline at minimum, but prioritize immediate remediation for internet-facing or multi-user instances.