sandboxed.sh: agent code reached host files through nsenter
Container workspaces in sandboxed.sh did not keep agent-run code away from the host filesystem, which the project documented as isolated.
· VulnCheck · Research by hieuPenguin
CVE-2026-109569 lets code an agent runs inside a sandboxed.sh container workspace read and write files on the host, because nsenter attaches without the root namespace option. Versions through 1.3.0 are affected.
01What happened
VulnCheck published CVE-2026-109569 on October 12, 2026, a container escape in sandboxed.sh through version 1.3.0, rated critical at CVSS 9.3 and credited to hieuPenguin. sandboxed.sh runs coding agents in container workspaces and is now the backend for the Orb clients.
02How it works
The tool attaches a shell to a container workspace using nsenter but leaves out the option that switches to the container root filesystem (CWE-1188), so the shell keeps the host root. Code that an agent runs in the workspace can then resolve absolute paths such as /etc on the host and read or modify files there. A hardening commit in the project repository describes a run that left its container and rewrote host files.
03Who is affected
Self-hosted installs of sandboxed.sh through version 1.3.0 are affected, which means teams relying on its container workspaces to contain coding agents. VulnCheck lists no fixed version.
04What to do
Turn on the scoped namespace by setting SANDBOXED_SH_NSENTER_USE_TARGET_ROOT=1, after checking that the agent binaries are present inside the container, because the maintainer's hardening commit leaves it off by default. Until that is in place, treat the workspace as able to reach host files and keep credentials and sensitive paths off that host.
Questions people ask
- Is there a patched version of sandboxed.sh for CVE-2026-109569?
- No fixed version appears in the VulnCheck advisory for CVE-2026-109569. The project repository holds a commit that adds a scoped namespace option, but the maintainer describes it as a defensive knob that stays off until each host is confirmed to carry the agent binaries inside the container, so installs stay exposed by default.
- What does an attacker need to exploit the sandboxed.sh escape?
- An attacker needs code running inside a container workspace, which is the position a coding agent gives to any repository, package or prompt it processes. From there the missing root namespace makes host paths resolvable, so the escape needs no second flaw. The CVSS vector records a local attack vector with low privileges.
- Why is this rated lower here than its critical CVSS score?
- Severity on The Injection measures the impact for defenders, and sandboxed.sh is a self-hosted tool with a narrow user base rather than a widely deployed product. CVE-2026-109569 is real and reproducible, which places it at medium in this rubric, while VulnCheck's critical rating reflects the technical impact on an affected install.
Sources 3 links, all fetched
- 1vulncheck.comVulnCheck Advisory
- 2github.comGitHub Advisory
- 3github.comHardening Commit