A critical Remote Code Execution vulnerability was identified in n8n, the widely-deployed open-source workflow automation platform, affecting versions 0.211.0 through 1.120.3. The vulnerability, tracked as CVE-2025-68613 and scored at CVSS 9.9, stems from an expression injection flaw within n8n’s JavaScript evaluation engine. Through it, an authenticated attacker can craft a malicious expression payload, inject it into a standard workflow node, and achieve full shell access on the underlying host server—executing code under the same privileges as the n8n service process.
Upon public disclosure, security teams observed rapid scanning and exploitation attempts in the wild, with Proof-of-Concepts and toolkits surfacing within hours. Defense teams across vendors responded in parallel, publishing WAF signatures, detection scanners, and patch advisories. The vulnerability is particularly high-impact given that automation platforms routinely store API tokens, database credentials, cloud environment variables, and SaaS authentication secrets—meaning a server compromise extends well beyond the host itself.
The following packages and versions are directly affected:
- n8n: 0.211.0 – 1.120.3 (self-hosted deployments)
At its core, CVE-2025-68613 is a sandbox escape via expression injection. n8n allows users to write custom JavaScript expressions inside workflow nodes to transform and route data between services. To prevent abuse, these expressions are evaluated within a restricted sandbox designed to block access to the Node.js runtime and the underlying operating system.
The flaw lies in the insufficient isolation of the expression evaluation context. Vulnerable versions of n8n fail to sanitize the global this object from the sandbox execution scope. In a Node.js environment, access to this provides a traversal path directly to the running process object. Once the attacker reaches process, they can invoke require() to load native Node.js modules—specifically child_process—and execute arbitrary OS-level commands on the host server.
Critically, this is not a client-side or output injection vulnerability. The attack targets server-side expression evaluation, resulting in code execution within the n8n server process itself—not within any browser or frontend context.
The vulnerability was scored Critical (CVSS 9.9) and has broad impact given n8n’s adoption across DevOps, IT automation, and data pipeline infrastructure in both enterprise and startup environments.
How CVE-2025-68613 Was Discovered
CVE-2025-68613 was identified through security research into n8n’s expression evaluation internals and the known challenges of sandboxing JavaScript execution within Node.js environments. The vulnerability was subsequently disclosed to the n8n security team through responsible disclosure channels.
Following internal validation, the n8n team released patched versions—1.120.4, 1.121.1, and 1.122.0—addressing the context isolation failure that enabled the sandbox escape. The public advisory was referenced by security vendors and cloud providers to perform root cause analysis and develop detection tooling. Shortly after the advisory became public, widespread scanning and exploitation attempts were observed targeting internet-exposed n8n instances, particularly those with public registration enabled or with the editor UI exposed on the default port 5678.
Technical Overview Of The Attack
CVE-2025-68613 exploits the failure of n8n’s sandbox to strip the global this object from the expression evaluation context. In standard Node.js module scope, this at the top level refers to module.exports—but within n8n’s vulnerable evaluation environment, it resolves to the global process context, providing a pivot to the full Node.js runtime.
The attack chain unfolds as follows:
It is worth noting that no special workflow permissions or administrative roles are required beyond the ability to create and execute a workflow. The vulnerable code path is reachable by any authenticated user on an affected instance.
Code-Based Example
Based on publicly documented exploitation attempts and Proof-of-Concepts published by researchers, the following represents the structure of the exploit payload as injected into an n8n expression field:
{{ (function(){
return this.process.mainModule.require('child_process').execSync('cat /etc/passwd').toString();
})() }}Breakdown Of Key Payload Fields
| Component | Role |
|---|---|
| this.process | Exploits the unstripped global context to access the Node.js process object—the root of the sandbox escape. Without this exposure, the chain cannot begin. |
| mainModule.require | Uses the process object to invoke require() dynamically, bypassing the sandbox’s restriction on module loading. |
| child_process | Loads Node.js’s native operating system interface module, which provides the ability to spawn arbitrary shell processes. |
| execSync(‘cat /etc/passwd’) | Executes a shell command synchronously on the host server. The cat /etc/passwd example confirms code execution; in real-world campaigns this would be replaced with a reverse shell download, credential extraction, or persistence mechanism. |
Note: In observed exploitation campaigns, the shell command payload is replaced with commands designed to exfiltrate environment variables (including cloud credentials and API keys stored in process.env), download and execute remote shell scripts, or establish persistent backdoors via cron jobs or system services.
What Was Observed After The Vulnerability Came To Light
Following public disclosure of the advisory, threat actors initiated scanning and exploitation attempts within hours. The speed of weaponization reflects a pattern now common to critical RCE vulnerabilities in widely-deployed infrastructure tooling.
Post-exploitation activity observed in the wild included:
The disclosure period also saw the emergence of fake and non-functioning Proof-of-Concepts on public repositories, which introduced initial confusion around detection coverage. Organizations were advised to validate exploit samples only against trusted security vendor sources before configuring WAF rules or detection signatures—a precaution critical to avoiding both false positives and gaps in defensive coverage.
Remediations
Short Term
- Patch Immediately: Upgrade all self-hosted n8n instances to 1.120.4, 1.121.1, 1.122.0, or any later release. These versions enforce proper context isolation during expression evaluation, closing the sandbox escape vector entirely.
- Restrict the Editor UI: If patching cannot be applied immediately, restrict access to the n8n editor (default port 5678) to loopback only, or gate it behind a VPN or allowlisted IP range. Disable public self-registration if it is enabled.
- Deploy WAF Rules: Configure WAF rules to block or flag requests containing expression injection indicators—specifically, payloads referencing this.process, mainModule.require, child_process, or execSync in any field submitted to the n8n workflow editor API.
- Audit Workflow Access: Review which accounts have permission to create and execute workflows. Restrict this capability to fully trusted personnel. Apply the Principle of Least Privilege across all n8n user roles.
- Conduct Forensic Log Review: Examine host-level process execution logs for unexpected child processes spawning from the n8n container or service—particularly sh, bash, curl, wget, or python. Anomalous outbound network connections and file writes to temporary directories are also indicators of successful exploitation.
- Rotate Exposed Credentials: Assume that any credentials stored as environment variables within a potentially compromised n8n instance have been exfiltrated. Rotate all relevant API keys, database connection strings, IAM credentials, and SaaS tokens immediately.
Long Term
- Enforce Least Privilege on the n8n Service: n8n processes should run as non-root users with minimal OS and cloud permissions. Containerized deployments should enforce restrictive security contexts, read-only filesystems where possible, and network egress controls to limit the blast radius of any future compromise.
- Deploy Runtime Security Tooling: Implement runtime detection tools capable of identifying anomalous process behavior—specifically, shell processes spawning from web server parents, unexpected outbound network connections, or file system writes to sensitive or temporary paths originating from the n8n process.
- Maintain a Software Bill of Materials (SBOM): Adopt SBOM tooling to maintain visibility into all third-party dependencies across your stack, enabling rapid identification of affected components when vulnerabilities like this one are disclosed.
- Establish a Rapid Patch Protocol: CVE-2025-68613 demonstrated that the window between public advisory and mass exploitation can be measured in hours. Organizations should have a tested, rehearsed process for deploying emergency patches to critical infrastructure components with minimal lead time.
- Validate Detection Tooling Against Trusted Sources: Before configuring WAF rules or detection signatures based on publicly available Proof-of-Concepts, validate those samples against trusted security vendor sources to eliminate false positives and ensure comprehensive coverage of the actual attack surface.
Conclusion
CVE-2025-68613 is a stark reminder that automation platforms—despite their operational centrality and broad network permissions—are often underscrutinized from a security posture perspective. The near-perfect CVSS score reflects not just the ease of exploitation, but the downstream impact: owning an automation server means inheriting access to every service it is configured to reach.
The speed at which this vulnerability moved from advisory to active exploitation in the wild highlights how narrow the remediation window has become for high-severity vulnerabilities in widely-deployed tooling. For organizations running self-hosted n8n, this event should serve as both an urgent remediation task and an opportunity to evaluate their dependency management practices, patching velocity, and runtime detection capabilities.
The patch is available. The path forward is clear.
Connect with QuasarCyberTech Experts
Need strategic guidance on preparing your business for emerging cyber threats?
At QuasarCyberTech, our specialized cybersecurity solutions help organizations stay ahead of evolving risks. From Vulnerability Assessment and Penetration Testing (VAPT) to Security Operations Center (SOC) implementation, Red Team exercises, and Governance, Risk, and Compliance (GRC) frameworks, we provide the expertise and tools needed to secure your digital assets and infrastructure.
Contact us today to develop a customized security strategy for your organization.
References:
n8n Official Security Advisory
NVD / NIST
n8n GitHub Repository (Changelog)
GitHub Advisory
