CVE-2026-109569 in sandboxed.sh
Summary
by MITRE • 10/13/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The sandboxed.sh utility, specifically through version 1.3.0, contains a critical security flaw that undermines the fundamental principle of container isolation by allowing processes within a containerized workspace to escape into the host operating system's file hierarchy. This vulnerability stems from an improper implementation of namespace separation during the execution of commands via nsenter. The tool is designed to provide isolated environments for agents or users running code, ensuring that their activities are confined to specific workspaces without affecting the underlying infrastructure. However, the failure to include the --root flag when invoking nsenter results in a misconfiguration where the process retains access to the host's root filesystem namespace rather than being restricted to an isolated view. This oversight effectively neutralizes the intended security boundary, allowing any code executed within these container workspaces to interact directly with the host system as if it were running natively on the server.
From a technical perspective, the absence of the --root argument in nsenter means that the process does not switch its root directory to the specified mount namespace or chroot environment before executing commands. Instead, it operates within the context of the parent process's namespaces while potentially leveraging other privileges granted by the container runtime configuration. This allows an attacker who has gained access to a container workspace to resolve absolute paths on the host filesystem. By constructing file paths that point outside the designated sandbox directory, such as /etc/passwd or sensitive application configurations located in system directories, the agent-run code can read and modify these files. This capability bypasses all documented isolation mechanisms provided by the tool, turning what should be a secure execution environment into an open gateway to the host operating system.
The operational impact of this vulnerability is severe, as it enables privilege escalation from a low-privileged container context to full control over the host machine. An adversary exploiting this flaw could exfiltrate sensitive data stored on the host, such as credentials, private keys, or proprietary source code. Furthermore, they could modify system configurations or deploy malware directly onto the host infrastructure, leading to potential service disruption, lateral movement across a network, and complete compromise of the organization's security posture. This type of container escape is particularly dangerous because it often goes undetected by standard perimeter defenses that assume containers are strictly isolated from their hosts. The ability to read and write arbitrary files on the host effectively grants root-level access if the process running inside the container has sufficient permissions, or allows for significant manipulation even with limited privileges depending on file ownership and ACLs.
This vulnerability aligns closely with CWE-250, which describes execution with unnecessary privileges, as well as CWE-78, improper neutralization of special elements used in an OS command (OS Command Injection), if the path resolution is manipulated via injection techniques. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to T1611 Escape to Host, a technique where attackers break out of restricted environments like containers or virtual machines to access the underlying host system. It also relates to T1083 File and Directory Discovery, as the attacker enumerates and accesses files outside their intended scope. The root cause is classified under CWE-256: Unprotected Storage of Credentials if sensitive data is accessed, but more accurately falls under architectural flaws related to namespace isolation failures.
To mitigate this vulnerability, immediate patching to a version later than 1.3.0 where the nsenter invocation correctly includes the --root flag or equivalent strict namespace confinement mechanisms is required. If upgrading is not immediately feasible, administrators should enforce stricter security policies on the host system using Linux capabilities and seccomp profiles to restrict which syscalls container processes can invoke. Additionally, implementing mandatory access control systems like SELinux or AppArmor can provide an additional layer of defense by limiting file access regardless of namespace configurations. It is also advisable to review all scripts utilizing sandboxed.sh for similar misconfigurations and ensure that no unnecessary privileges are granted to the containers running these workspaces. Regular auditing of container runtime settings against industry best practices, such as those outlined in CIS Benchmarks for Docker or Kubernetes, will help prevent recurrence of such isolation failures.