In February 2026, a critical sandbox escape vulnerability was publicly disclosed in n8n, the widely adopted open-source workflow automation platform. Tracked as CVE-2026-25049, this flaw enables authenticated users to bypass the expression evaluation sandbox and execute arbitrary system commands on the host server, achieving full remote code execution with a CVSS v3.1 score of 9.9.
As part of the OPSWAT Cybersecurity Fellowship Program, our fellows conducted a comprehensive technical analysis of CVE-2026-25049, examining its root cause, exploitation mechanism, and organizational impact.
This blog delivers a detailed walkthrough of the vulnerability - from n8n’s expression processing architecture and its layered security controls to the precise technique that defeats all five defensive layers simultaneously.
CVE-2026-25049 is a critical expression sandbox escape vulnerability in n8n, classified under CWE-913: Improper Control of Dynamically-Managed Code Resources. The flaw affects all n8n versions prior to 1.123.17, as well as versions 2.0.0 through 2.5.1, and has been patched in versions 1.123.17 and 2.5.2. It enables authenticated users with workflow creation permissions to craft malicious JavaScript expressions that bypass the platform’s expression sandbox, ultimately achieving arbitrary command execution on the host server.
The vulnerability is particularly severe because n8n commonly occupies a privileged position within an organization’s infrastructure. As a workflow automation hub, n8n typically maintains direct access to internal APIs, databases, credential stores, and third-party services. A compromised n8n instance does not merely expose the automation server - it provides a pivot point into every connected system, dramatically amplifying the blast radius of exploitation.
CVE-2026-25049 is not a standalone discovery but a bypass of the patch for CVE-2025-68613, an earlier sandbox escape in n8n’s expression evaluator. Despite implementing multiple layered defenses after the initial vulnerability, a fundamental gap in how the sanitizer processes JavaScript Abstract Syntax Tree (AST) node types allowed the original class of attack to resurface through a different syntactic vector. This pattern - where a patch addresses the specific exploit technique rather than the underlying design weakness - highlights the persistent challenge of securing dynamic code evaluation environments.
The vulnerability was disclosed on February 4, 2026, alongside ten other security advisories for n8n, and has been independently analyzed by multiple security research teams.
About n8n
n8n is an open-source workflow automation platform that enables organizations to connect systems, automate processes, and build integrations across hundreds of services. With widespread adoption and over 1,300 available integrations, n8n has become one of the most popular tools in its category, used by development teams and enterprises to automate everything from internal tooling to business-critical data pipelines.
The platform supports both self-hosted and cloud deployments and provides a visual workflow builder alongside direct JavaScript support for custom logic. n8n’s architecture is node-based: workflows are composed of interconnected nodes that pass data in JSON format between triggers, actions, and function steps. Execution can run in manual mode for testing or in production mode for live deployment. This architecture, combined with native support for JavaScript expressions and access to internal APIs and credential stores, makes n8n a powerful automation tool - but also a high-value target when vulnerabilities arise.
Technical Background
Abstract Syntax Trees
An Abstract Syntax Tree (AST) is a hierarchical representation of source code produced by a parser. Rather than treating code as a flat string, an AST decomposes it into structured nodes representing its syntactic elements - variable declarations, function expressions, member expressions, identifiers, and literals.
Understanding AST node types is essential to this analysis because n8n’s security controls operate at the AST level. The sanitizers inspect specific node types to detect and block dangerous patterns. The vulnerability exploits the fact that the same semantic operation - accessing an object’s property - can produce entirely different AST node types depending on the JavaScript syntax used.
For example, the expression obj.constructor produces a MemberExpression node, while const { constructor } = obj produces a VariableDeclaration containing an ObjectPattern with a Property node. Both extract the same property, but the AST structures are fundamentally different - and n8n’s sanitizers only inspect the first pattern.
n8n Expression Evaluation and Security Architecture
n8n’s architecture is organized into five layers: Frontend, CLI, Core, Workflow, and Nodes. The Workflow layer handles expression evaluation, which is the component relevant to this vulnerability.
n8n allows users to embed JavaScript expressions within workflow node parameters to dynamically manipulate data. These expressions are evaluated server-side using a library called Tournament, which parses expressions into an AST before execution. Sanitization hooks are injected directly into the Tournament creation process, running checks during AST construction to intercept dangerous patterns before any code executes.
Because these expressions run within the same Node.js process as the n8n server, the platform implements five distinct security layers designed to prevent untrusted code from escaping the sandbox.
Layer 1 - Global Context Overwrite
Before any expression is evaluated, n8n creates a restricted execution context by overwriting dangerous global objects and functions. Properties such as document, window, globalThis, eval, setTimeout, setInterval, and Function are replaced with empty objects, preventing direct access to these capabilities.
This approach has an inherent limitation: if an attacker can escape the restricted context and reach the real global process object, the overwritten properties become irrelevant.
Layer 2 - Regex Validation
Before the expression reaches the evaluator, n8n applies a regular expression check on the raw expression string to block access to the constructor property - a common vector for obtaining the Function constructor and achieving code execution.
The regex /\.\s*constructor/gm detects dot-notation access to .constructor. However, this check is fundamentally limited because JavaScript offers multiple syntactic paths to access the same property, not all of which involve dot notation.
Layer 3 - AST Runtime Sanitizer – PrototypeSanitizer
The most sophisticated defense operates during AST construction. The PrototypeSanitizer hook traverses the AST and inspects MemberExpression nodes to determine whether the accessed property appears on a blocklist of unsafe object properties - including constructor, __proto__, prototype, mainModule, and binding.
The sanitizer handles three cases: dot notation (obj.prop) where it checks the identifier name, static bracket notation (obj['prop']) where it checks the string literal value, and dynamic expressions which are wrapped in a runtime sanitizer function. As shown in Figure 10, only MemberExpression nodes are inspected - destructuring patterns are not traversed.
Layer 4 - AST Runtime Sanitizer FunctionThisSanitizer
Added as a direct patch for CVE-2025-68613, the FunctionThisSanitizer intercepts Immediately Invoked Function Expressions (IIFEs) and rewrites them to bind this to an empty object. This prevents the technique used in the original exploit, where (function(){ return this })() leaked the global process object through the unbound this reference.
Critically, this sanitizer only handles FunctionExpression nodes. It explicitly returns early for any callee that is not a FunctionExpression, including arrow functions.
Dangerous properties such as eval, Function, and process.mainModule are removed from or overwritten in the execution context, preventing direct access to code execution primitives even if earlier layers are bypassed.
Vulnerability Analysis
Root Cause
The root cause of CVE-2026-25049 lies in a shared assumption across all five security layers: every layer assumed that property access would occur through either dot notation (obj.constructor) or bracket notation (obj['constructor']). None accounted for JavaScript destructuring syntax.
JavaScript destructuring allows properties to be extracted from objects using a fundamentally different AST structure:
// Traditional access - produces MemberExpression node
obj.constructor; // Blocked by regex, AST sanitizer, and runtime checks
// Destructuring - produces ObjectPattern → Property node
const { constructor } = obj; // Not checked by any layer
Although both patterns achieve the same result, they produce entirely different AST representations. The PrototypeSanitizer only inspects MemberExpression nodes, and the regex only matches .constructor patterns. Destructuring assignments create VariableDeclaration → ObjectPattern → Property nodes, which none of the sanitizers traverse.
This is compounded by n8n’s handling of arrow functions. The FunctionThisSanitizer intercepts only FunctionExpression nodes and rewrites them to bind this to a safe context. Arrow functions produce ArrowFunctionExpression AST nodes, which the sanitizer does not process. Since arrow functions inherit this from their enclosing scope (lexical this), they provide access to the unsanitized global context.
Together, these two oversights produce a complete bypass: destructuring extracts the Function constructor without triggering any property access checks, and arrow functions provide an execution context that the FunctionThisSanitizer does not intercept.
Exploitation
The exploit combines both gaps to break every security layer simultaneously. Our fellows traced the following exploitation path:
Step 1 - Arrow Function Entry. The payload begins with an arrow function wrapped in an Immediately Invoked Function Expression (IIFE):
={{(() => {
// Arrow function - bypasses FunctionThisSanitizer
...
})()}}
The FunctionThisSanitizer checks whether the callee is a FunctionExpression; since this is an ArrowFunctionExpression, the sanitizer returns early without rewriting the call. The arrow function executes with full access to the real global context.
Step 2 - Destructuring Bypass. Inside the arrow function, destructuring extracts the Function constructor from an arrow function instance:
const { constructor } = () => {};
Because this is a destructuring assignment, the AST contains an ObjectPattern node rather than a MemberExpression. The regex check sees no .constructor pattern, and the PrototypeSanitizer never inspects the property name. The attacker now holds a reference to the Function constructor.
Step 3 - Dynamic Code Execution. With the Function constructor obtained, the attacker constructs and executes arbitrary code:
return constructor(
'return process.mainModule.require("child_process").execSync("whoami").toString()',
)();
The dynamically constructed function runs outside the sandbox context with full access to the Node.js process object, enabling arbitrary system command execution on the host.
Proof of Concept
To demonstrate the real-world impact of this vulnerability, our fellows reproduced the exploit in a controlled lab environment. The attack scenario involves hosting a vulnerable n8n instance and importing a workflow containing the malicious payload within a node parameter - specifically targeting the Edit Fields Node, which permits expression evaluation.
Once the workflow is triggered, the payload bypasses all five sanitization layers and executes a reverse shell on the host server, returning full command execution capability to the attacker.
Webhook Escalation to Unauthenticated RCE
The severity of this vulnerability increases significantly when combined with n8n’s webhook functionality. n8n allows workflows to expose HTTP endpoints as webhooks with configurable authentication options, including bearer tokens, basic authentication, and - critically - no authentication at all. An attacker with workflow creation access can configure a public webhook with authentication: "none", embed the RCE payload in a connected node, and activate the workflow. At that point, any HTTP request to the webhook URL - from anywhere on the internet - triggers arbitrary command execution on the host server.
This escalation path transforms CVE-2026-25049 from an authenticated, internal vulnerability into an effectively unauthenticated attack vector with internet-wide exposure.
Mitigation
The n8n team addressed CVE-2026-25049 in versions 1.123.17 and 2.5.2 by implementing proper runtime type checking in the sanitization functions and expanding AST coverage to handle destructuring patterns. Organizations running affected versions should upgrade immediately.
If immediate upgrade is not feasible, administrators should restrict workflow creation and editing permissions to fully trusted users only and deploy n8n in a hardened environment with restricted operating system privileges and network access.
Given the critical severity and ease of exploitation - particularly when combined with public webhooks - organizations should also audit existing workflows for suspicious expressions, monitor for anomalous system command execution originating from the n8n process, and review webhook configurations for any endpoints exposed without authentication.
Mitigating with OPSWAT
By leveraging OPSWAT SBOM, organizations can swiftly identify vulnerable n8n components within their infrastructure and take action before exploitation occurs. OPSWAT SBOM, a foundational technology within the MetaDefender® platform, provides a comprehensive inventory of all software components, libraries, and dependencies in use across an organization’s environment.
As shown in Figure 15, MetaDefender Core™ scanned the package.json file containing the n8n dependency and automatically flagged CVE-2026-25049 as Critical, displaying the affected version range and the recommended fixed versions for remediation. This enables security teams to quickly identify and prioritize the vulnerability across their deployment landscape.
OPSWAT SBOM is available in MetaDefender Core™ and MetaDefender Software Supply Chain™, enabling security teams to:
- Quickly locate vulnerable components - Immediately identify open-source dependencies affected by sandbox escape and code execution vulnerabilities, enabling swift remediation or removal.
- Ensure proactive patching and updates - Continuously monitor open-source components to detect outdated or insecure packages, enabling timely updates and reduced exposure.
- Maintain compliance and reporting - Meet regulatory requirements as frameworks increasingly mandate transparency in software supply chains.
