CVE-2026-92949: Sandbox Escape and State Mutation in vm2 via Accessor Property Descriptor Leak

The Node.js library vm2 is an advanced sandbox environment designed to run untrusted code securely within a shared V8 process. It relies heavily on V8 Proxies to intercept interactions between the isolated sandbox environment and the main host process. This architecture creates a logical boundary meant to restrict the untrusted code from modifying host-level data structures or escalating privileges.

The vulnerability identified as CVE-2026-92949 undermines this architecture by exposing a weakness in how the proxy bridge handles descriptor requests. When host objects are marked as frozen or read-only, developers expect their attributes to remain completely immutable from within the sandbox. However, the system fails to apply equivalent validation controls on the indirect retrieval pathways of property descriptors, leading to an integrity compromise.

The underlying flaw allows sandboxed code to request property descriptors of immutable host-bound objects and obtain a live, executable proxy wrapper of the underlying setter function. This behavior violates the logical contract enforced by vm2's ReadOnlyHandler proxy. While the bypass does not immediately grant a full execution-level realm escape on its own, it allows attackers to bypass read-only configurations, which frequently serve as a stepping stone to full compromise.

To understand the root cause, we must analyze the inheritance structure of vm2's proxy handlers. The ReadOnlyHandler class is designed to wrap objects that the application developer wishes to expose inside the sandbox as read-only. This handler intercepts write-traps like set, defineProperty, and deleteProperty to systematically drop or reject write requests. This ensures direct modification of properties on these wrapped objects is blocked.

The vulnerability occurs because ReadOnlyHandler inherits key proxy traps directly from BaseHandler without overriding them. Specifically, the getOwnPropertyDescriptor trap remains unguarded in ReadOnlyHandler. When a sandboxed application requests the descriptor of an accessor property (a property that uses get and set methods) on a frozen host object, BaseHandler processes the query. It returns a descriptor structure where the get and set methods are automatically wrapped in a callable function bridge.

This creates an asymmetric exposure vector. Although direct writes to the proxy are blocked, reading the property descriptor leaks a fully functional, bridge-wrapped wrapper pointing to the original host setter. The sandbox can then invoke this setter directly in the context of the host object, completely bypassing the proxy and its write-restriction traps.

The V8 engine executes the invoked setter on the raw, unwrapped host target. Because the execution path goes straight to the underlying native JavaScript engine, the write-blocking proxy traps are never evaluated. Consequently, the host-realm state is mutated through a view that was explicitly marked as immutable by the developer.

The vulnerability was resolved in commit d6ef73bd46488102dae8f4bc35f3f3c0eba2ea64 by modifying lib/bridge.js. The fix implements defensive overrides within the proxy handlers to drop setter functions before they are bridged back to the sandbox. Below is a conceptual illustration showing the vulnerable code design versus the patched implementation.

// BEFORE PATCH (lib/bridge.js)
// ReadOnlyHandler did not override getOwnPropertyDescriptorDesc,
// meaning any call to read descriptors would default to BaseHandler.
// BaseHandler returned wrapped accessors (including setters) directly to the sandbox.
class ReadOnlyHandler extends BaseHandler {
    // Missing getOwnPropertyDescriptorDesc override
}

The patch introduces an explicit trap in ReadOnlyHandler to sanitize descriptors before they cross the boundary to the sandbox. When the property descriptor of a frozen host-bound object is queried from the sandbox, the bridge checks if a setter is present and strips it from the returned descriptor.

// AFTER PATCH (lib/bridge.js)
// ReadOnlyHandler is updated to explicitly intercept and sanitize descriptors.
class ReadOnlyHandler extends BaseHandler {
    getOwnPropertyDescriptorDesc(target, prop, desc) {
        validateHandlerTarget(this, target);
        desc = super.getOwnPropertyDescriptorDesc(target, prop, desc);
        
        // Strip the setter if the target is sandbox-bound and holds a set accessor
        if (!isHost && desc && desc.set) {
            desc.set = undefined;
        }
        return desc;
    }
}

Additionally, V8 enforces strict rules regarding proxy behavior. If a target object is frozen, the returned proxy descriptors must align with the target's original attributes. To prevent runtime type errors (TypeError) resulting from the mismatch of stripped setters, the maintainers also updated doPreventExtensions to consistently route descriptor duplication through the new sanitization hook. This ensures V8 internal compliance and prevents application crashes.

An attacker can exploit this vulnerability using multiple descriptor extraction channels available in standard ECMAScript. These channels include Object.getOwnPropertyDescriptor, Object.getOwnPropertyDescriptors, Reflect.getOwnPropertyDescriptor, and the legacy Object.prototype.__lookupSetter__ function. Each of these APIs triggers the vulnerable getOwnPropertyDescriptor proxy trap under the hood.

// Triggering the exploit inside the sandbox using multiple extraction channels
 
// Channel 1: Using Object.getOwnPropertyDescriptor
const descriptor = Object.getOwnPropertyDescriptor(cfg, 'level');
if (descriptor && descriptor.set) {
    descriptor.set.call(cfg, 'PWNED-gopd');
}
 
// Channel 2: Using the legacy __lookupSetter__ method
const setter = cfg.__lookupSetter__('level');
if (setter) {
    setter.call(cfg, 'PWNED-lookup');
}

Once the setter function is retrieved, the attacker invokes it using Function.prototype.call or Function.prototype.apply. By passing the frozen object as the this argument, the execution runs in the context of the host object. Because the bridge unwraps the proxy context to execute the target function on the native host instance, the mutation happens directly on the host memory space without triggering the set trap.

This execution path requires no authentication or specific privileges inside the sandbox. The only prerequisite is that the host application must expose an object containing accessor properties (getters and setters) to the sandbox, and mark that object as frozen or read-only. If the host application exposes such configurations, the sandbox environment can alter them completely.

The impact of CVE-2026-92949 is classified under CWE-471: Modification of Assumed-Immutable Data (MAID). This type of vulnerability compromises the fundamental integrity guarantees provided by a sandbox environment. If an application developer exposes critical configurations, security parameters, database connections, or routing tables as frozen objects, the sandboxed code can alter these parameters to manipulate host application flow.

The National Vulnerability Database has assigned this vulnerability a CVSS v3.1 score of 4.0, reflecting medium severity. The attack complexity is rated as high because the vulnerability requires a specific runtime context: the host must expose an object with accessor properties to the sandbox. The integrity impact is classified as low because the exploit only allows modifications of specific exposed objects, rather than absolute system-level writes or arbitrary host-realm shell execution.

The EPSS score for this vulnerability is 0.00319, which indicates a low immediate probability of active exploitation in the wild. Additionally, the vulnerability is not listed in CISA's Known Exploited Vulnerabilities (KEV) catalog. However, in scenarios where the sandbox is the primary defense line protecting a multitenant execution environment, this bypass represents a severe gap in boundary containment.

The primary mitigation is upgrading vm2 to version 3.11.7 or higher, which contains the complete patch for this flaw. Organizations should audit their dependency trees to identify any transitive usage of vm2 in their environments. Because the library is widely utilized, many security scanners and static analysis tools will flag older installations.

It is critical to note that the vm2 library is officially deprecated and is no longer maintained. Due to the inherent difficulty of securing a shared-process JavaScript runtime, the project maintainers have advised users to migrate away from vm2 completely. The architectural design of Node.js makes it fundamentally difficult to prevent all sandbox escapes when the sandbox and host share a single V8 engine instance.

For robust and secure isolation of untrusted JavaScript code, organizations should migrate to isolated-vm. This library isolates sandboxed execution within separate V8 Isolate contexts, which do not share the same memory heap or garbage collector as the host process. Alternatively, running untrusted code inside microVMs, Docker containers, or WASM runtimes offers far superior hardware-level isolation compared to process-shared JavaScript wrappers.