A critical security flaw has been discovered in the popular workflow automation platform n8n. Tracked as CVE-2026-25049 with a CVSS score of 9.4, the vulnerability allows authenticated users to escape n8n’s JavaScript sandbox and execute arbitrary system commands on the underlying server, effectively taking full control of the n8n instance.
How CVE-2026-25049 Breaks n8n’s JavaScript Sandbox
n8n enables users to embed JavaScript expressions in workflows, which are executed inside a sandbox to prevent malicious code from interacting with the host environment. The platform relies on Abstract Syntax Tree (AST) analysis to detect and block dangerous constructs before the code runs.
Researchers from Pillar Security, Endor Labs, and SecureLayer7 identified that this sandbox implementation was incomplete. By using carefully crafted JavaScript, they were able to bypass AST-based checks and gain access to the global Node.js object and other sensitive runtime features, turning a supposedly isolated expression into a powerful remote code execution (RCE) primitive.
The issue is particularly concerning because it effectively bypasses protections introduced earlier to fix another critical bug, CVE-2025-68613 (CVSS 9.9), patched in December 2025. CVE-2026-25049 restored a viable attack path even for systems that had already applied the prior fix.
Who Is at Risk: Attack Scenarios and Business Impact
To exploit CVE-2026-25049, an attacker needs an account that can create or edit workflows. According to Pillar Security, this level of access is sufficient to compromise the server: “if you can create workflows, you can take over the server.”
Remote Code Execution and Full Server Compromise
Once the sandbox is bypassed, an attacker can execute arbitrary operating system commands. This enables:
1. Full remote code execution (RCE). Installation of additional tools, deployment of backdoors, and use of the n8n host as a launchpad for further attacks inside the network.
Exposure of Secrets and Sensitive Integrations
2. Theft of stored credentials and secrets. n8n often holds API keys, OAuth tokens, and integration passwords for CRMs, data warehouses, cloud platforms, and other critical services. Compromised secrets can quickly escalate into full compromise of connected systems, a pattern repeatedly observed in incident reports such as the Verizon Data Breach Investigations Report.
File System Access, Lateral Movement, and AI Workflow Tampering
3. Access to the file system and internal services. Attackers may read or modify local files and reach internal services or cluster components that are not exposed to the public internet, enabling lateral movement.
4. Compromise of AI workflows. n8n is widely used to orchestrate AI and LLM-driven workflows. An attacker could intercept prompts, alter model responses, invisibly change decision logic, or redirect AI-related traffic to attacker-controlled endpoints, undermining data integrity and business decisions.
The risk is amplified in multi-tenant deployments. If n8n has network access to services shared across tenants, a single compromised account may become a stepping stone to data belonging to other customers.
Timeline and Technical Details of the n8n Vulnerability
According to Pillar Security, the n8n team was notified about CVE-2026-25049 on 21 December 2025. The initial proof of concept demonstrated a reliable escape from the sandbox and access to the Node.js global object, which directly enabled RCE.
An initial patch was shipped within two days. However, subsequent review revealed that the fix left alternative ways to sidestep AST checks using equivalent constructs and operations. As a result, the vulnerability remained exploitable via more sophisticated payloads.
The issue was fully addressed only in n8n 2.4.0, released on 12 January 2026. Experts from Endor Labs provided a simple proof-of-concept exploit, while SecureLayer7 documented how the Function constructor—which should have been blocked—could still be abused server-side. Their research reportedly required over 150 unsuccessful attempts before a reliable bypass was found, underscoring how difficult it is to implement secure JavaScript sandboxes.
Mitigation: Patching, Hardening, and Operational Controls
The n8n maintainers strongly recommend upgrading to the latest stable versions, currently 1.123.17 and 2.5.2, which include the finalized sandbox hardening and related security fixes. In modern supply chain attack patterns, unpatched automation and CI/CD tools have repeatedly been leveraged as high-impact entry points; n8n should now be treated with the same level of urgency.
Immediate Security Measures for n8n Administrators
Security guidance from Pillar Security includes the following priority actions:
1. Rotate the encryption key. Change the value of N8N_ENCRYPTION_KEY, which protects stored secrets, to invalidate any data that might have been exposed.
2. Rotate all credentials stored in n8n. Regenerate and update all passwords, API keys, tokens, and OAuth credentials configured in workflows, even if there is no clear evidence of compromise.
3. Audit workflows for malicious JavaScript. Review existing workflows for suspicious JavaScript expressions, especially those interacting with the file system, system functions, or unusual network endpoints.
If Immediate Patching Is Not Possible
Where an upgrade cannot be performed quickly due to technical or organizational constraints, it is advisable to:
— Restrict workflow creation and editing rights to a minimal set of highly trusted users;
— Run n8n in a maximally isolated environment with reduced operating system privileges, strict network segmentation, and limited access to internal services.
Additional High-Severity Vulnerabilities Fixed in n8n
Alongside CVE-2026-25049, the n8n team fixed four additional vulnerabilities, two of which also carry a CVSS score of 9.4 and require prompt attention:
— CVE-2026-25053: command injection in the Git node, enabling arbitrary command execution when interacting with repositories;
— CVE-2026-25056: arbitrary file write via SQL Query in the Merge node, allowing modification of the file system.
Two further issues, while less critical, still pose meaningful risk in real-world deployments:
— CVE-2026-25054: stored cross-site scripting (XSS) in the Markdown rendering component, exposing users of the web interface to client-side attacks;
— CVE-2026-25055: path traversal in the SSH node when handling uploaded files, potentially enabling access to unintended file system paths.
The disclosure of CVE-2026-25049 and related flaws highlights how challenging it is to securely support user-supplied code in workflow automation platforms. Organizations relying on n8n should not only patch rapidly, but also reassess which users are allowed to define workflows, strengthen network segmentation around automation tooling, and implement continuous monitoring and periodic secret rotation. Treating workflow engines as high-value infrastructure components rather than convenience tools significantly reduces the blast radius of inevitable future vulnerabilities in complex automation ecosystems.
