Sandbox Bypass

Vulnerability

The realms-shim package, in all versions, is vulnerable to a sandbox bypass via prototype pollution [1][3]. The shim implements an outdated Realm API proposal that does not provide isolation between realms; objects passed between mutually-suspicious realms can leak, allowing one realm to pollute the globals or intrinsics of another [1]. Prototype pollution occurs when an attacker injects properties into Object.prototype through unsafe recursive merges or property definition by path, as described in the Snyk advisory [3]. The shim lacks mechanisms to freeze intrinsics or hide them behind a membrane, making the sandbox ineffective [1].

Exploitation

An attacker can exploit this vulnerability by crafting objects with a __proto__ property or other prototype-polluting attributes and passing them between realms [1][3]. If the target realm processes these objects without proper sanitization, the attacker can pollute Object.prototype and thereby modify the behavior of all objects in that realm. The attacker needs the ability to execute code within one realm and have that code interact with another realm, typically through object exchange. No special authentication is required beyond the ability to run JavaScript in the context of the shim [1].

Impact

Successful exploitation allows an attacker to bypass the sandbox and pollute the global intrinsics of another realm, leading to arbitrary code execution in the context of the host application [1]. This can result in full compromise of the application's security, including data theft, privilege escalation, or denial of service. The impact is critical because the shim is intended to provide isolation, but the vulnerability completely undermines that goal [1].

Mitigation

The realms-shim package is obsolete and insecure; it is not recommended for use [1]. No patch is available for this vulnerability. Users should migrate to alternative isolation tools such as Endo, SES, or HardenedJS, which provide proper sandboxing via lockdown() and Compartment constructors [1]. The ShadowRealm proposal (Stage 3) also offers a safer alternative with a callable boundary that prevents object leakage [1].