CVE-2026-77083 in n8n
Summary
by MITRE • 08/20/2026
n8n is a workflow automation platform. In versions prior to 1.123.69, 2.33.4, and 2.34.1, the JavaScript Code node's VM sandbox did not freeze the sandbox's Function.prototype, allowing an authenticated user with the ability to create and execute workflows to pollute it from within a Code node execution and recover a reference to the host's globalThis, resulting in a sandbox escape. The full exploit chain additionally depends on specific modules being available as allowlisted imports in the deployment's configuration. The issue is fixed in versions 1.123.69, 2.33.4, and 2.34.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified in n8n workflow automation platforms prior to versions 1.123.69, 2.33.4, and 2.34.1 represents a critical sandbox escape within the JavaScript Code node execution environment. This flaw stems from an insufficient isolation mechanism where the virtual machine sandbox failed to freeze or seal the Function.prototype object. In standard secure coding practices for Node.js environments, freezing core prototypes is a primary defense against prototype pollution attacks that can lead to arbitrary code execution outside the intended scope. By leaving Function.prototype mutable, the platform allowed authenticated users with workflow creation privileges to manipulate this global constructor during script execution. This manipulation enabled attackers to pollute the prototype chain and subsequently recover a reference to the host's globalThis object, effectively breaking out of the restricted sandbox environment and gaining access to the underlying Node.js process context.
From an operational perspective, this vulnerability allows for significant impact beyond simple data leakage or workflow disruption. Once an attacker escapes the sandbox by obtaining a reference to globalThis, they can potentially execute arbitrary JavaScript code with the same privileges as the n8n server process. This could lead to full system compromise depending on how the application is deployed and what permissions are granted to the running user. The exploit chain specifically relies on certain modules being available as allowlisted imports within the deployment configuration, which means that while the vulnerability exists in all affected versions, successful exploitation may vary based on specific instance configurations. This dependency highlights the importance of not only patching software but also reviewing allowed module lists and restricting unnecessary dependencies to minimize the attack surface for such sandbox escapes.
The technical nature of this flaw aligns with CWE-94 Improper Control of Generation of Code or Command, specifically regarding injection into a script interpreter via prototype pollution techniques. Furthermore, it maps to MITRE ATT&CK technique T1059.007 JavaScript, which describes the use of client-side scripting languages for execution within an application environment. The failure to properly isolate untrusted code from trusted system resources is a classic example of inadequate security controls in serverless or workflow automation contexts where user-supplied scripts are executed dynamically. Organizations utilizing n8n must recognize that even authenticated users with limited administrative rights can leverage this flaw if they have the ability to create and execute workflows, turning what appears to be a low-privilege account into a high-impact threat vector.
To mitigate this risk, immediate upgrade to version 1.123.69 for the v1 branch or versions 2.33.4 and 2.34.1 for the v2 branches is required as these releases contain fixes that properly freeze necessary prototypes within the sandbox environment. In addition to patching, administrators should audit their workflow configurations to ensure that only essential modules are included in allowlists, thereby reducing the potential tools available for exploitation even if a similar vulnerability were discovered in future versions. Implementing strict input validation and limiting the scope of code execution nodes can further harden the deployment against prototype pollution attacks. Regular security assessments focused on sandbox isolation integrity should be conducted to ensure that dynamic code execution features remain securely contained within their intended boundaries, preventing unauthorized access to host system resources.