CVE-2026-43898: SandboxJS Sandbox Escape
Critical CVSS (10.0) reachable over local.
TL;DR - CVE-2026-43898 is a critical SandboxJS sandbox escape rated CVSS 10.0. - Versions before 0.9.6 are affected; upgrade to 0.9.6 or later. - No CISA KEV listing, CVE-specific public PoC, or confirmed in-the-wild exploitation was found in the checked sources. - Applications evaluating untrusted JavaScript should treat this as a potential host compromise.
Summary
CVE-2026-43898 affects SandboxJS, a JavaScript sandboxing library. The SandboxJS vulnerability allows sandboxed code to recover an internal runtime callback, obtain blocked host capabilities, recover the genuine JavaScript Function constructor, and execute arbitrary JavaScript in the host context.
NVD assigns the issue a CVSS v3 base score of 10.0 Critical. The available NVD response supplied the score but not the CVSS vector string. Because the vector has not been independently verified from the vendor advisory or a refreshed NVD record, this article does not infer individual CVSS metrics beyond the confirmed severity and observed impact.
| Field | Value |
|---|---|
| CVE | CVE-2026-43898 |
| Product | SandboxJS |
| Affected versions | Versions before 0.9.6 |
| Fixed version | 0.9.6 |
| CVSS v3 base score | 10.0 Critical |
| Attack vector | Not independently confirmed; vulnerability is triggered by code evaluated in the SandboxJS runtime |
| Authentication required | Not confirmed in the supplied record |
| Patch available | Yes |
| Primary impact | Sandbox escape and arbitrary host-side JavaScript execution |
| NVD publication date | 2026-05-28 |
| NVD last modified | 2026-10-14 |
The practical risk depends on what the embedding application exposes to the SandboxJS process. A compromised evaluator may be able to access application secrets, manipulate data, read files, make network requests, or invoke operating-system functionality available to the host process. Treat a sandbox escape as a potential host compromise, not merely as a failure of JavaScript-language restrictions.
Analyst’s Take: Upgrade priority should be driven by where SandboxJS evaluates untrusted or semi-trusted code, not by the absence of a CISA KEV listing or confirmed public PoC. The documented escape reaches the embedding process’s host-side JavaScript, so vulnerable evaluators with access to credentials, files, or internal services warrant immediate attention.
Organizations reviewing JavaScript sandbox security should also compare this issue with broader application isolation and data-loss risks, including what data loss prevention means.
Root Cause
The root cause is an unintended capability leak through the Function.caller property. In vulnerable releases, functions defined inside the sandbox expose information about their caller. That exposure allows sandboxed code to recover the internal LispType.Call runtime callback used by SandboxJS.
The recovered callback can be invoked with attacker-controlled fake context and obj values. This bypasses the intended separation between sandbox objects and host objects, allowing the attacker to extract blocked host statics. From there, the attacker can recover the real host-side Function constructor and use it to execute JavaScript outside the sandbox’s restrictions.
The exploit path is a chain of boundary failures:
- A sandbox-defined function exposes
Function.caller. - The caller reference reveals an internal SandboxJS runtime callback.
- The callback accepts attacker-controlled object and context values.
- Host statics that should remain inaccessible become reachable.
- The genuine host
Functionconstructor is recovered. - Host-side JavaScript executes with the privileges of the embedding process.
This distinction matters during response. Removing an individual malicious payload does not repair the boundary. The vulnerable library must be upgraded, and systems that evaluated attacker-controlled code should be assessed for post-escape activity.
Who’s Exposed
The affected product is SandboxJS from the nyariv/SandboxJS project. The affected range is:
SandboxJS < 0.9.6
The fixed release is:
SandboxJS >= 0.9.6
The available vulnerability record does not identify additional product names, separately maintained branches, or alternative distributions. Organizations should still check both direct and transitive dependencies. Applications may include SandboxJS through a lockfile, vendored source tree, container image, internal package mirror, or bundled browser/server artifact.
A deployment is especially exposed when it evaluates untrusted or semi-trusted JavaScript, including user-submitted expressions, tenant-provided automation, plugin code, workflow logic, server-side templates, or rules downloaded from external systems. The risk is also material where the evaluator runs in a long-lived service with access to credentials, internal APIs, sensitive files, or powerful cloud metadata endpoints.
Do not rely only on the version declared in package.json. Verify the resolved dependency and the code actually deployed:
npm ls sandboxjs --all
npm explain sandboxjs
grep -R '"sandboxjs"' package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml 2>/dev/null
Confirm the package name and installation layout against the project’s build system. If the library was vendored or bundled, inspect the deployed artifact and compare it with the 0.9.6 fix rather than assuming the package manager’s inventory is complete.
Severity Breakdown
NVD reports a CVSS v3 base score of 10.0, placing CVE-2026-43898 in the Critical category. The impact is severe because successful exploitation crosses the intended sandbox boundary and enables arbitrary host-side JavaScript execution. In a server application, that may provide access to process memory exposed through JavaScript objects, environment variables, application credentials, files, network services, and other capabilities available to the process.
The supplied NVD response did not include the vector string. Accordingly, the individual CVSS components below must not be presented as confirmed values:
| CVSS component | Confirmed value |
|---|---|
| Attack vector | Not supplied in the checked record |
| Attack complexity | Not supplied |
| Privileges required | Not supplied |
| User interaction | Not supplied |
| Scope | Not supplied |
| Confidentiality impact | Not supplied |
| Integrity impact | Not supplied |
| Availability impact | Not supplied |
| Base score | 10.0 |
Operationally, defenders should assume that any endpoint or workflow accepting attacker-influenced JavaScript may be an entry point until the deployment is upgraded and reviewed. The missing CVSS vector does not change the documented outcome: arbitrary execution outside the sandbox in a product designed to contain code execution.
For comparison, teams maintaining vulnerability-management programs may benefit from reviewing Nessus vs. Qualys in 2026 when deciding how to track and prioritize this type of dependency risk.
Exploitation Status
CVE-2026-43898 is not listed in the CISA Known Exploited Vulnerabilities catalog based on the checked result:
on_kev: false
CVE: CVE-2026-43898
There is no CISA-assigned KEV date, remediation deadline, required action, or ransomware-campaign flag for this CVE at the time assessed. This indicates that CISA has not cataloged confirmed exploitation for the vulnerability; it does not show that exploitation is impossible or that an attack has never occurred.
The checked sources did not confirm CVE-specific exploitation in the wild. They also did not confirm a public proof of concept specifically attributable to CVE-2026-43898. Public proof-of-concept material exists for other SandboxJS sandbox-escape advisories, but related research must not be treated as proof that this CVE has been exploited or that another advisory’s payload works unchanged against this issue.
| Question | Assessment |
|---|---|
| CISA KEV listing | No |
| Confirmed CVE-specific in-the-wild exploitation | Not found in checked sources |
| CVE-specific public PoC | Not confirmed in checked sources |
| Related SandboxJS escape research | Public material exists for other advisories |
| Recommended assumption | Treat vulnerable internet-facing or multi-tenant evaluators as high risk |
Affiliate Security Tools
If incident response or remediation requires checking endpoints for additional malicious activity, use only tools approved by your organization and verify their privacy, licensing, and deployment terms before purchase. Security software may be useful as a supplementary control, but it does not replace patching SandboxJS or investigating the affected host.
Sources
The primary technical sources are the NVD record, the SandboxJS security advisory, and the vendor’s fixing commit. The advisory and commit identify the fixed release as 0.9.6 and describe the sandbox escape mechanism involving Function.caller, LispType.Call, host statics, and the host Function constructor.
- NVD: CVE-2026-43898
- GitHub Security Advisory: GHSA-g8f2-4f4f-5jqw
- SandboxJS fixing commit
- CISA Known Exploited Vulnerabilities Catalog
Revisit the CISA result during incident triage because KEV status can change after publication. Refresh the NVD record or vendor advisory before recording a definitive CVSS vector in asset-management or compliance systems. At the time assessed, the verified facts are that versions before 0.9.6 are affected, 0.9.6 fixes the issue, the NVD score is 10.0, and no CISA-confirmed exploitation or CVE-specific public PoC was established in the checked sources.
Given the host-code execution impact, upgrade first wherever SandboxJS evaluates attacker-influenced JavaScript. Then verify the resolved and deployed version, isolate any evaluator that cannot be patched immediately, and review vulnerable deployments for post-escape activity before rotating exposed credentials.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Detection should combine dependency inventory, application telemetry, and host monitoring. Start by identifying every process that imports or bundles SandboxJS below 0.9.6, then determine whether those processes evaluate untrusted code. A vulnerable library in an unused administrative tool has a different exposure profile from the same library in a public API accepting tenant-supplied JavaScript.
Review application logs for requests that submit JavaScript containing references associated with the escape path, including Function.caller, unusual constructor access, or attempts to traverse runtime objects. These strings are not a complete signature and can be obfuscated, so treat matches as triage indicators rather than definitive exploitation proof.
A basic search for relevant application telemetry might look like:
grep -RniE 'Function[[:space:]]*\.[[:space:]]*caller|constructor|LispType|SandboxJS' \
/var/log/my-application /var/log/nginx 2>/dev/null
For centralized logging, an example Splunk query is:
index=app
("Function.caller" OR "LispType.Call" OR "SandboxJS")
| stats count values(uri) values(src_ip) values(user) by host
Adapt the fields and syntax to the deployed logging platform. Legitimate application code may contain the words constructor or caller, so investigate surrounding request bodies, user identity, source address, and execution outcomes.
The highest-value signal is often post-escape behavior. Correlate sandbox evaluation events with unexpected child processes, file reads, outbound connections, credential access, or environment-variable exposure. For Linux systems, audit rules can provide supporting evidence when auditd is deployed:
ausearch -m EXECVE -ts recent
ausearch -m CONNECT -ts recent
Look for activity by the application account immediately after suspicious sandbox submissions. Examples include shells, interpreters, package managers, curl, wget, access to cloud metadata addresses, unexpected DNS lookups, and writes outside the application’s normal working directories. Preserve relevant request bodies and process telemetry before rotating or rebuilding affected instances.
Remediation Steps
Upgrade SandboxJS to 0.9.6 or later, then rebuild and redeploy every affected application. The exact command depends on the package manager, but a typical npm workflow is:
npm install sandboxjs@^0.9.6
npm update sandboxjs
npm ls sandboxjs
Review the resulting lockfile, run the application’s test suite, rebuild production artifacts, and restart all processes that may have loaded the vulnerable version. If the application uses a monorepo, workspace, vendored dependency, or container image, repeat the check for every service rather than patching only the repository root.
For CI or deployment verification, fail builds that resolve a vulnerable version. One simple check is:
version="$(npm ls sandboxjs --parseable 2>/dev/null | tail -n 1 | xargs -r basename)"
npm ls sandboxjs
The command above is only an inventory aid; use the organization’s approved semantic-version validation in CI to enforce >=0.9.6. Confirm the final container or server artifact, not just the build workspace.
If an immediate upgrade is impossible, stop evaluating untrusted JavaScript in the vulnerable process. Do not treat input filtering, blocking the string Function.caller, or deleting selected globals as a reliable workaround because the issue is a capability-boundary failure and payloads may be transformed or obfuscated. Temporarily isolate the evaluator in a separate low-privilege process or container with no sensitive mounts, restricted outbound networking, minimal filesystem access, and no cloud-instance metadata access. These controls reduce blast radius but do not replace the upgrade.
After patching, investigate vulnerable deployments that processed untrusted code. Review application requests, authentication events, child-process creation, filesystem access, network connections, environment variables, secrets-manager access, and cloud audit logs for the period beginning when the vulnerable version was deployed. Rotate credentials that may have been readable by the application process, including API keys, database passwords, signing keys, and cloud credentials. If compromise indicators are present, rebuild from trusted artifacts rather than assuming a package update removes persistence.