CVE-2026-43898 - SandboxJS Function.caller sandbox escape

SandboxJS versions through 0.9.5 exposed host-side call machinery through Function.caller on sandbox-defined functions. Sandboxed code could recover an internal callback, forge operands, reach host constructors, and execute arbitrary host JavaScript.

For production agent systems, the key lesson is that a JavaScript expression sandbox is not a complete boundary for secrets, tools, workspaces, or internal networks. The upgrade is required, but the prompt also asks the agent to move untrusted code toward stronger isolation.

When to use it

Use this recipe when a repository may evaluate JavaScript expressions with @nyariv/sandboxjs, especially in plugin systems, workflow builders, notebooks, tenant customization, or agent-generated automation. It is most valuable when the runtime also carries secrets, source workspaces, package tokens, internal network access, or model/tool credentials.

Do not use it to run sandbox-escape payloads. Use it to produce a patch, triage note, or operator handoff that proves whether the dependency and runtime authority are safe.

Inputs

  • Package manifests, lockfiles, SBOMs, dependency reports, container manifests, and deployment artifacts that may resolve @nyariv/sandboxjs.
  • SandboxJS call sites, shared expression-evaluation helpers, plugin runners, workflow engines, notebook services, and test fixtures.
  • Classification of expression input sources: trusted internal code, admins, users, tenants, plugins, workflows, queues, or agent outputs.
  • Runtime authority for the sandbox process: environment variables, mounted files, package tokens, CI secrets, cloud credentials, model keys, network reachability, and CPU/memory/time limits.
  • Existing incident-response, credential-rotation, and artifact-rebuild requirements for runtimes that may have evaluated untrusted code.

Affected versions

Package Vulnerable versions Fixed versions
@nyariv/sandboxjs <=0.9.5 0.9.6

Indicator-of-exposure

  • The repository depends on @nyariv/sandboxjs <=0.9.5.
  • SandboxJS evaluates user, tenant, plugin, notebook, workflow, or agent-generated expressions.
  • The sandboxed process can access environment variables, source workspaces, package-manager tokens, cloud credentials, internal services, or build artifacts.

Quick checks:

rg -n "@nyariv/sandboxjs|SandboxJS|new sandb|compile\\(|\\.run\\(|sandboxed|expression" .
npm ls @nyariv/sandboxjs
pnpm why @nyariv/sandboxjs
yarn why @nyariv/sandboxjs

Remediation strategy

  • Upgrade @nyariv/sandboxjs to 0.9.6+.
  • Treat any vulnerable sandbox runtime as potentially escaped if it processed untrusted code.
  • Remove secrets and broad filesystem/network authority from the process that evaluates sandboxed expressions.
  • Add policy tests that reject dangerous sandbox use for untrusted code unless the execution runs in a stronger isolation boundary.
  • Rotate credentials if untrusted sandboxed code could have run before the patch.

The prompt

You are remediating CVE-2026-43898 in `@nyariv/sandboxjs`. Produce exactly one
output:

- A reviewer-ready PR/change request that upgrades SandboxJS, reduces host
  authority around sandbox execution, adds policy tests, refreshes generated
  artifacts, and documents operator cleanup, or
- TRIAGE.md if this repository does not control an affected SandboxJS runtime.

## Rules

- Scope only CVE-2026-43898 and directly related sandbox isolation hardening.
- Do not run sandbox-escape payloads, OS commands, child process probes, or
  host-constructor proof code.
- Do not print, commit, or expose environment variables, source archives, cloud
  credentials, package tokens, CI secrets, tenant files, or sandbox output that
  may contain secrets.
- Do not claim the sandbox is a sufficient boundary for untrusted code without
  process/container isolation.
- Do not auto-merge.

## Steps

1. Inventory package manifests, lockfiles, workspace packages, containers,
   browser/worker bundles, notebooks, plugin runners, tests, SBOMs, and docs
   for `@nyariv/sandboxjs`.
2. Determine every resolved version. A target is vulnerable if it resolves to
   `<=0.9.5`.
3. Search every SandboxJS call site and classify the input source as trusted,
   admin-supplied, tenant/user-supplied, plugin-supplied, workflow-supplied, or
   agent-generated.
4. Upgrade to `@nyariv/sandboxjs@0.9.6+`. Regenerate lockfiles, SBOMs, images,
   deployment artifacts, and dependency reports.
5. For untrusted code paths, reduce host authority:
   - run expression evaluation in a low-privilege process or container;
   - deny unnecessary filesystem and network access;
   - remove model provider keys, cloud keys, package tokens, and CI secrets;
   - bound CPU, memory, and execution time;
   - log sandbox policy decisions without logging secrets.
6. Add tests that assert all SandboxJS dependencies are patched and untrusted
   code paths use the approved isolation wrapper. Do not execute exploit code.
7. Add a PR body section named `CVE-2026-43898 operator actions` covering:
   versions before/after, sandbox call sites, untrusted input paths,
   credentials reachable by the old process, and whether secret rotation or
   rebuilds are required.
8. Run validation: package install, unit tests, sandbox policy tests,
   lint/typecheck, container build, SBOM refresh, and dependency scan.
9. Use PR title:
   `fix(sec): remediate SandboxJS sandbox escape`.

## Stop conditions

- No affected SandboxJS runtime is controlled by this repo.
- All controlled targets already resolve `@nyariv/sandboxjs >=0.9.6` and
  generated artifacts are current.
- The product intentionally evaluates untrusted code in a secret-bearing
  process; document the owner decision and safer isolation plan in TRIAGE.md.
- Verification would require executing sandbox-escape or OS command payloads.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No lockfile, image, SBOM, or deployment artifact resolves @nyariv/sandboxjs <=0.9.5.
  • Sandbox call sites that handle untrusted code are isolated from secrets and internal networks.
  • Tests enforce the approved wrapper or deny unsafe sandbox use.
  • Operator notes cover credential rotation where prior escape was plausible.

Watch for

  • Transitive SandboxJS copies in examples, plugin templates, or notebooks.
  • Build systems that still run vulnerable lockfiles after package.json changes.
  • Security comments that overstate what an expression sandbox can safely do.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades @nyariv/sandboxjs to 0.9.6+, refreshes generated artifacts, routes untrusted expression execution through approved isolation, adds non-exploit policy tests, and documents operator credential-rotation decisions.
  • TRIAGE.md when no controlled affected SandboxJS runtime exists, when all controlled targets are already patched and artifacts are current, or when the repository needs an owner decision before moving untrusted code out of a secret-bearing process.

The output must list checked manifests and call sites, version before/after, runtime authority before/after, validation commands, and any remaining manual operator actions. It must not include exploit payloads, secrets, sandbox output containing sensitive data, or claims that SandboxJS alone is a complete trust boundary.

References