CVE-2026-34217

SandboxJS is a JavaScript sandboxing library. Prior to 0.8.36, a scope modification vulnerability exists in @nyariv/sandboxjs. 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. This vulnerability is fixed in 0.8.36.

SandboxJS is a JavaScript sandboxing library. Prior to 0.8.36, a scope modification vulnerability exists in @nyariv/sandboxjs. 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. This vulnerability is fixed in 0.8.36.

Description

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

addOps<new (...args: unknown[]) => unknown, unknown[]>(
  LispType.New,
  ({ done, a, b, context }) => {
    if (!context.ctx.globalsWhitelist.has(a) && !context.ctx.sandboxedFunctions.has(a)) {
      throw new SandboxAccessError(`Object construction not allowed: ${a.constructor.name}`);
    }
    done(undefined, new a(...b));  // ← b is NOT sanitized, return is NOT sanitized
  },
);

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 Implemented)

File: src/executor.ts, lines 493–605

addOps<unknown, Lisp[], any>(LispType.Call, ({ done, a, b, obj, context }) => {
  // ...
  const vals = b
    .map((item) => {
      if (item instanceof SpreadArray) {
        return [...item.item];
      } else {
        return [item];
      }
    })
    .flat()
    .map((item) => valueOrProp(item, context));  // ← Arguments ARE sanitized
  // ...
  let ret = evl ? evl(obj.context[obj.prop], ...vals) : (obj.context[obj.prop](...vals));
  ret = getGlobalProp(ret, context) || ret;  // ← Return IS sanitized
  sanitizeArray(ret, context);               // ← Return IS sanitized
  done(undefined, ret);
});

The Call handler correctly sanitizes both arguments (via valueOrProp) and return values (via getGlobalProp and sanitizeArray). The New handler does neither.

Why This Is Vulnerable

Step 1: What is a Prop Object?

The sandbox interpreter wraps every value access in a Prop object (defined at src/utils.ts, lines 565–582). A Prop has:

class Prop {
  context: any;       // The object the property belongs to
  prop: PropertyKey;  // The property name
  isConst: boolean;
  isGlobal: boolean;
  isVariable: boolean;
}

When sandboxed code accesses a variable like isNaN, the interpreter creates Prop(scope.allVars, 'isNaN'). The context field is a direct reference to the scope's variable storage object.

Step 2: What is in scope.allVars?

At the global scope level, scope.allVars is the same object as options.globals — the SAFE_GLOBALS object containing:

{
  globalThis: <real globalThis>,
  Function: <real Function constructor>,
  eval: <real eval function>,
  console: { log: console.log, ... },
  Array, Object, Map, Set, Promise, Date, Error, RegExp,
  isNaN, parseInt, parseFloat, ...
}

These are the real host JavaScript objects. The sandbox normally protects them by intercepting reads through the Prop handler and replacing dangerous ones via the evals Map.

Step 3: How the Prop Leaks Through new

When sandboxed code executes new Constructor(someVariable):

1. The interpreter evaluates someVariable — this produces a Prop object: Prop(scope.allVars, 'someVariable')
2. The New handler receives this Prop as-is in the b array (no valueOrProp() call)
3. new Constructor(...[Prop]) passes the raw Prop object to the constructor function
4. Inside the constructor, the Prop is received as a named parameter 5.…

SandboxJS is a JavaScript sandboxing library. Prior to 0.8.36, a scope modification vulnerability exists in @nyariv/sandboxjs. 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. This vulnerability is fixed in 0.8.36.

Description

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

addOps<new (...args: unknown[]) => unknown, unknown[]>(
  LispType.New,
  ({ done, a, b, context }) => {
    if (!context.ctx.globalsWhitelist.has(a) && !context.ctx.sandboxedFunctions.has(a)) {
      throw new SandboxAccessError(`Object construction not allowed: ${a.constructor.name}`);
    }
    done(undefined, new a(...b));  // ← b is NOT sanitized, return is NOT sanitized
  },
);

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 Implemented)

File: src/executor.ts, lines 493–605

addOps<unknown, Lisp[], any>(LispType.Call, ({ done, a, b, obj, context }) => {
  // ...
  const vals = b
    .map((item) => {
      if (item instanceof SpreadArray) {
        return [...item.item];
      } else {
        return [item];
      }
    })
    .flat()
    .map((item) => valueOrProp(item, context));  // ← Arguments ARE sanitized
  // ...
  let ret = evl ? evl(obj.context[obj.prop], ...vals) : (obj.context[obj.prop](...vals));
  ret = getGlobalProp(ret, context) || ret;  // ← Return IS sanitized
  sanitizeArray(ret, context);               // ← Return IS sanitized
  done(undefined, ret);
});

The Call handler correctly sanitizes both arguments (via valueOrProp) and return values (via getGlobalProp and sanitizeArray). The New handler does neither.

Why This Is Vulnerable

Step 1: What is a Prop Object?

The sandbox interpreter wraps every value access in a Prop object (defined at src/utils.ts, lines 565–582). A Prop has:

class Prop {
  context: any;       // The object the property belongs to
  prop: PropertyKey;  // The property name
  isConst: boolean;
  isGlobal: boolean;
  isVariable: boolean;
}

When sandboxed code accesses a variable like isNaN, the interpreter creates Prop(scope.allVars, 'isNaN'). The context field is a direct reference to the scope's variable storage object.

Step 2: What is in scope.allVars?

At the global scope level, scope.allVars is the same object as options.globals — the SAFE_GLOBALS object containing:

{
  globalThis: <real globalThis>,
  Function: <real Function constructor>,
  eval: <real eval function>,
  console: { log: console.log, ... },
  Array, Object, Map, Set, Promise, Date, Error, RegExp,
  isNaN, parseInt, parseFloat, ...
}

These are the real host JavaScript objects. The sandbox normally protects them by intercepting reads through the Prop handler and replacing dangerous ones via the evals Map.

Step 3: How the Prop Leaks Through new

When sandboxed code executes new Constructor(someVariable):

1. The interpreter evaluates someVariable — this produces a Prop object: Prop(scope.allVars, 'someVariable')
2. The New handler receives this Prop as-is in the b array (no valueOrProp() call)
3. new Constructor(...[Prop]) passes the raw Prop object to the constructor function
4. Inside the constructor, the Prop is received as a named parameter 5.…