Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Sandbox-defined functions expose Function.caller, allowing sandboxed code to recover the internal LispType.Call runtime callback. That callback can then be invoked with attacker-controlled fake context and obj values to extract blocked host statics, recover the real host Function constructor, and execute arbitrary host JavaScript. Details The vulnerability is in the property access logic registered via addOps in prop.ts. Sandboxed code could access the caller, callee, and arguments properties on functions. In the CommonJS build, this allowed sandboxed code to read Function.caller and leak a privileged internal LispType.Call callback. In executorUtils.ts createFunction() constructs normal host JS functions, and because these are ordinary host functions, sandbox code can observe: That leaks the host-side callback that invoked the sandbox function. This leaked callback is the internal LispType.Call op, which is registered in call.ts. The escape was possible because the…
Recommended action: Upgrade to 0.9.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A scope modification vulnerability exists in @nyariv/sandboxjs version 0.8.35 and below. The vulnerability allows untrusted sandboxed code to leak internal interpreter objects through the new operator, exposing sandbox scope objects in the scope hierarchy to untrusted code; an unexpected and undesired exploit. While this could allow modifying scopes inside the sandbox, code evaluation remains sandboxed and prototypes remain protected throughout the execution. Vulnerable Code Location Primary: The New Operator Handler File: src/executor.ts, lines 1275–1280 This handler has two missing sanitization steps: 1. Arguments (b) are not passed through valueOrProp() — Constructor arguments contain raw Prop objects (internal interpreter wrappers) instead of extracted values. 2. Return value is not passed through getGlobalProp() or sanitizeArray() — The constructed object is returned directly to the execution tree without any sanitization. Comparison: The Call Handler (Correctly…
Recommended action: Upgrade to 0.8.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The @nyariv/sandboxjs parser contains unbounded recursion in the restOfExp function and the lispify/lispifyExpr call chain. An attacker can crash any Node.js process that parses untrusted input by supplying deeply nested expressions (e.g., ~2000 nested parentheses), causing a RangeError: Maximum call stack size exceeded that terminates the process. Details The root cause is in src/parser.ts. The restOfExp function (line 443) iterates through expression characters, and when it encounters a closing bracket that doesn't match the expected firstOpening, it recursively calls itself at line 503: Each nested bracket ((, , {) adds a stack frame. There is no depth counter or limit check. The function signature has no depth parameter: A second unbounded recursive path exists through lispify → lispTypes.get(type) → group handler → lispifyExpr (line 672) → lispify, which processes parenthesized groups recursively with no depth limit. All public API methods (Sandbox.parse(),…
Recommended action: Upgrade to 0.8.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SandboxJS blocks direct assignment to global objects (for example Math.random = ...), but this protection can be bypassed through an exposed callable constructor path: this.constructor.call(target, attackerObject). Because this.constructor resolves to the internal SandboxGlobal function and Function.prototype.call is allowed, attacker code can write arbitrary properties into host global objects and persist those mutations across sandbox instances in the same process. Details The intended safety model relies on write-time checks in assignment operations. In assignCheck, writes are denied when the destination is marked global (obj.isGlobal), which correctly blocks straightforward payloads like Math.random = () = 1. Reference: src/executor.ts#L215-L218 The bypass works because the dangerous write is not performed by an assignment opcode. Instead, attacker code reaches a host callable that performs writes internally. The constructor used for sandbox global objects is…
Recommended action: Upgrade to 0.8.36 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Assumed repo path is /Users/zwique/Downloads/SandboxJS-0.8.34 (no /Users/zwique/Downloads/SandboxJS found). A global tick state (currentTicks.current) is shared between sandboxes. Timer string handlers are compiled at execution time using that global tick state rather than the scheduling sandbox's tick object. In multi-tenant / concurrent sandbox scenarios, another sandbox can overwrite currentTicks.current between scheduling and execution, causing the timer callback to run under a different sandbox's tick budget and bypass the original sandbox's execution quota/watchdog. Impact: execution quota bypass → CPU/resource abuse --- Details - Affected project: SandboxJS (owner: nyariv) - Assumed checked-out version: SandboxJS-0.8.34 at /Users/zwique/Downloads/SandboxJS-0.8.34 Vulnerable code paths - /src/eval.ts — sandboxFunction binds ticks using ticks || currentTicks.current: Relevant lines: 44, 53, 164, 167. - /src/evaluator.ts / /src/executor.ts — global ticks: and Relevant…
Recommended action: Upgrade to 0.8.35 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
It is possible to obtain arrays containing Function, which allows escaping the sandbox. Details There are various ways to get an array containing Function, e.g. Given an array containing Function, and Object.fromEntries, it is possible to construct {[p]: Function} where p is any constructible property. This can be used to escape the sandbox. PoC Impact Sandbox Escape - RCE
Recommended action: Upgrade to 0.8.34 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape vulnerability allows sandboxed code to mutate host built-in prototypes by laundering the isGlobal protection flag through array literal intermediaries. When a global prototype reference (e.g., Map.prototype, Set.prototype) is placed into an array and retrieved, the isGlobal taint is stripped, permitting direct prototype mutation from within the sandbox. This results in persistent host-side prototype pollution and may enable RCE in applications that use polluted properties in sensitive sinks (example gadget: execSync(obj.cmd)). Details Root Cause: The sandbox implements a protection mechanism using the isGlobal flag in the Prop class to prevent modification of global objects and their prototypes. However, this taint tracking is lost when values pass through array/object literal creation. Vulnerable Code Path src/executor.ts(L559-L571): Exploitation Flow: Protection Bypass Location src/utils.ts(L380-L385): When the prototype is accessed via array retrieval, the…
Recommended action: Upgrade to 0.8.31 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape vulnerabilities due to a mismatch between the key on which the validation is performed and the key used for accessing properties. Details Even though the key used in property accesses ( in the code below) is annotated as , this is never enforced: https://github.com/nyariv/SandboxJS/blob/6103d7147c4666fe48cfda58a4d5f37005b43754/src/executor.ts#L304-L304 So, attackers can pass malicious objects that coerce to different string values when used, e.g., one for the time the key is sanitized using and a different one for when the key is used for the actual property access. PoC Impact Remote code execution, if attacker can execute code inside the sandbox.
Recommended action: Upgrade to 0.8.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
As Map is in SAFEPROTOYPES, it's prototype can be obtained via Map.prototype. By overwriting Map.prototype.has the sandbox can be escaped. Details This is effectively equivalent to CVE-2026-25142, but without lookupGetter (let was used during testing), it turns out the let implementation is bugged: PoC Impact Able to set Map.prototype.has - RCE
Recommended action: Upgrade to 0.8.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape is possible by shadowing hasOwnProperty on a sandbox object, which disables prototype whitelist enforcement in the property-access path. This permits direct access to proto and other blocked prototype properties, enabling host Object.prototype pollution and persistent cross-sandbox impact. The issue was reproducible on Node v23.9.0 using the project’s current build output. The bypass works with default Sandbox configuration and does not require custom globals or whitelists. Root Cause prototypeAccess uses a.hasOwnProperty(b) directly, which can be attacker‑controlled if the sandboxed object shadows hasOwnProperty. When this returns true, the whitelist checks are skipped. - src/executor.ts:348 const prototypeAccess = isFunction || !(a.hasOwnProperty(b) || typeof b === 'number'); <img width="1030" height="593" alt="image" src="https://github.com/user-attachments/assets/0fa0807e-81cc-45b5-be13-bd839c974a4f" / - src/executor.ts:367-399 prototype whitelist…
Recommended action: Upgrade to 0.8.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The return values of functions aren't wrapped. Object.values/Object.entries can be used to get an Array containing the host's Function constructor, by using Array.prototype.at you can obtain the hosts Function constructor, which can be used to execute arbitrary code outside of the sandbox. Details The return values of functions aren't wrapped, chaining function calls allows bypassing most validation/sanitization. PoC Impact Sanbox Escape - RCE
Recommended action: Upgrade to 0.8.29 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
SandboxJS does not properly restrict lookupGetter which can be used to obtain prototypes, which can be used for escaping the sandbox / remote code execution. Details https://github.com/nyariv/SandboxJS/blob/f212a38fb5a6d4bc2bc2e2466c0c011ce8d41072/src/executor.ts#L368-L398 The Object prototype which contains lookupGetter is properly protected, but the special case for accessing function properties bypasses the prototype chain checks including the root Object prototype. PoC Impact Prototype Pollution - RCE
Recommended action: Upgrade to 0.8.27 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox escape vulnerability due to AsyncFunction not being isolated in SandboxFunction Details The library attempts to sandbox code execution by replacing the global Function constructor with a safe, sandboxed version (SandboxFunction). This is handled in utils.ts by mapping Function to sandboxFunction within a map used for lookups. However, the library did not include mappings for AsyncFunction, GeneratorFunction, and AsyncGeneratorFunction. These constructors are not global properties but can be accessed via the .constructor property of an instance (e.g., (async () = {}).constructor). In executor.ts, property access is handled. When code running inside the sandbox accesses .constructor on an async function (which the sandbox allows creating), the executor retrieves the property value. Since AsyncFunction was not in the safe-replacement map, the executor returns the actual native host AsyncFunction constructor. Constructors for functions in JavaScript (like Function,…
Recommended action: Upgrade to 0.8.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A prototype pollution vulnerability exists in @nyariv/sandboxjs versions <= 0.8.23, allowing attackers to inject arbitrary properties into Object.prototype via crafted JavaScript code. This can result in a denial-of-service (DoS) condition or, under certain conditions, escape the sandboxed environment intended to restrict code execution. The vulnerability stems from insufficient prototype access checks in the sandbox’s executor logic, particularly in the handling of JavaScript function objects returned.
Recommended action: Upgrade to 0.8.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.