EUVD-2026-97892
GHSA-xqq7-hjvp-gg2f
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessRun code inside container workspace
-
ExploitInvoke nsenter attaching without --root
-
ExecutionResolve absolute host filesystem paths
-
ImpactRead and modify arbitrary host files
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V13 - Configuration Secure default settings
|
| Exploitation Conditions | Requires the attacker to already be executing code inside a sandboxed.sh container workspace (e.g., untrusted or AI-agent-run code), the exact scenario the product is meant to contain; affected builds are sandboxed.sh through 1.3.0 where the nsenter attachment is performed without the --root flag. Limiting factors that reduce realistic risk: exploitation is local (AV:L) and demands at least low privilege/code execution within the workspace (PR:L) rather than remote or unauthenticated access, and it is only relevant to environments that actually deploy sandboxed.sh to isolate workloads. No user interaction is needed once code runs in the workspace. |
| Impact | This is a genuinely high-impact flaw but with significant real-world gating, so the raw 9.3 should not be read as 'drop everything.' The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:L/UI:N) confirms exploitation is LOCAL and requires the attacker to already have low-level privileges - specifically the ability to execute code inside a sandboxed.sh container workspace - rather than remote unauthenticated access. Technical impact is total: VC:H/VI:H/VA:H plus subsequent-system SC:H/SI:H/SA:H reflect that a successful escape yields full read/write on the host, which is the worst case for a sandbox product whose entire value proposition is isolation. However, the softer signals are weak-to-absent: no EPSS score was provided, the CVE is NOT in CISA KEV, and no public POC is referenced, so exploitation is not demonstrated in the wild. Net: credible, security-critical isolation failure for anyone running sandboxed.sh ≤1.3.0 to contain untrusted/agent-run code (the exact threat model it claims to defend), but priority is bounded by the local/privileged prerequisite and the product's apparently narrow deployment. Note a data caveat: the linked 'fix' commit does not actually contain nsenter or --root changes (see confidence_notes), so the remediation path is not independently corroborated by the provided evidence. |
| Exploit ScenarioDerived | An operator uses sandboxed.sh to run untrusted or AI-agent-generated code inside an isolated container workspace. Because the tool's nsenter attaches without --root, the confined code resolves absolute host paths and reads or modifies arbitrary host files, escaping the sandbox and defeating the documented isolation boundary. No public exploit is referenced, but the primitive is straightforward for any code already executing inside the workspace. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 12, 2026
A container escape in sandboxed.sh through 1.3.0 lets code running inside a container workspace read and modify files on the host filesystem, defeating the isolation the product is designed to provide. The flaw stems from the tool invoking nsenter without the --root flag, so absolute paths resolved by agent-run code land on the host root rather than the container's own filesystem. Exploitation requires the attacker to already execute code inside a sandboxed.sh workspace (low privilege, local), not remote or unauthenticated access, and no public exploit code or confirmed active exploitation has been identified; the effective CVSS 3.1 vector is AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, which materially tempers the headline 9.3 score despite the high confidentiality, integrity, and availability impact.
RemediationAI
Vendor-released patch: apply upstream fix in commit 4ab42e91b16c452f77d93ca69a040a54229b0aa2 (https://github.com/Th0rgal/orb/commit/4ab42e91b16c452f77d93ca69a040a54229b0aa2); a tagged release version containing the fix is not independently confirmed in the provided data, so validate the deployed build against that commit. Upstream fix available (PR/commit); released patched version not independently confirmed. Until a confirmed patched build is deployed, treat the isolation boundary as broken: do not run untrusted or third-party code, and especially agent-generated code, inside sandboxed.sh workspaces on hosts holding sensitive data, since any such workload can already reach the host filesystem. Compensating controls include stripping CAP_SYS_ADMIN and other namespace-related capabilities from the container entrypoint and blocking nsenter via seccomp so the workspace cannot attach to foreign namespaces, which may break legitimate tooling that depends on that path; enforcing user namespaces and read-only bind mounts for any host paths that must be visible reduces blast radius but does not restore true isolation; and hardening the host with mandatory access control (SELinux/AppArmor) profiles that confine the nsenter-attached process limits write access but requires careful profile authoring. Network isolation of the host does not mitigate this issue because the exploitation path is local to the host. Consult the VulnCheck advisory at https://www.vulncheck.com/advisories/sandboxed-sh-through-1.3.0-container-escape-via-nsenter-missing-root-namespace and the project repository https://github.com/Th0rgal/orb for updates.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
sandboxed.sh is a sandboxing/orchestration tool (developed in the Th0rgal/orb repository) that runs agent or user workloads inside container workspaces and is intended to keep that code away from the host. The escape is achieved through nsenter, the util-linux utility that joins the namespaces of another process. When nsenter attaches without the --root option, the tooling enters the target's namespaces but does not change the process root to the target's root directory, so the process continues to resolve absolute paths against the host's filesystem. Any code running in the workspace can therefore read and overwrite host files by referencing absolute paths, bypassing the documented isolation boundary. The root-cause class is CWE-1188 (Insecure Default Initialization of Resource): the secure configuration of the namespace attachment was not enforced by default, and the referenced upstream commit 4ab42e91b16c452f77d93ca69a040a54229b0aa2 addresses this in the repository. Authentication is required in the sense that the attacker must already have code execution inside a container workspace (CVSS PR:L), and the assessed CVSS 3.1 vector rates scope as changed (S:C) because the vulnerable component's flaw allows escaping to a resource beyond its intended security scope.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Attacker needs code execution inside the container (AV:L, PR:L); escaping the sandbox to the host is a scope change (S:C) with full host read/write (C:H/I:H/A:H).
Primary rating from Vendor (vulncheck).
CVSS VectorVendor: vulncheck
DescriptionCVE.org
sandboxed.sh through 1.3.0 contains a container escape vulnerability that allows code in container workspaces to access the host filesystem because nsenter attaches without --root. Agent-run code in a container workspace can resolve absolute paths on the host to read and modify host files, bypassing documented isolation.
Executive ViewAI
sandboxed.sh versions through 1.3.0 contain a critical container escape vulnerability that allows code inside a workspace to read and modify host filesystem files, undermining the product's core isolation guarantee. Organizations using sandboxed.sh to run untrusted or multi-tenant workloads-such as AI agent execution, CI/CD pipelines, or shared development environments-face potential data exposure and integrity compromise of the underlying host; exploitation requires local code execution within a workspace and no public exploit identified at time of analysis, but the boundary-crossing nature warrants immediate management attention.
No vendor-released patch identified at time of analysis. Interim mitigations include restricting workspace access to trusted users, enforcing least privilege, using mandatory access controls (SELinux/AppArmor) to block nsenter and mount namespace operations, dropping CAP_SYS_ADMIN, and monitoring host filesystem integrity.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
Exploit-DB