CVE-2026-121614 in Sandboxes
Summary
by MITRE • 11/04/2026
Docker Sandboxes versions 0.31.0 before 0.50.0 do not neutralize repository-controlled Git configuration when running certain host-side Git commands. An attacker who can modify a host repository's Git configuration, for example through a direct-mode sandbox with the repository mounted read-write, can configure core.fsmonitor or another Git setting that invokes an external program. Git can execute the program during a later clone-mode fetch or, starting in version 0.39.0, an sbx kit push initiated by the user. The program runs on the host with the invoking user's permissions, outside the sandbox's microVM isolation. The read-only host repository mount provided to a clone-mode sandbox does not itself allow that sandbox to modify the host repository's Git configuration. The issue is fixed in version 0.50.0.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/04/2026
The vulnerability identified in Docker Sandboxes versions prior to 0.50.0 represents a critical failure in input validation and isolation enforcement, specifically concerning how external configurations are handled during host-side operations. This flaw allows an attacker who possesses the ability to modify Git configuration files within a repository mounted on the host system to execute arbitrary code with elevated privileges outside the intended microVM sandbox boundary. The core of this issue lies in Docker Sandboxes' handling of Git's extensibility features, particularly settings such as core.fsmonitor or other hooks that can be configured to invoke external programs. When these configurations are present and triggered by specific host-side commands, they bypass the security controls designed to contain execution within the isolated environment.
From a technical perspective, the vulnerability exploits the trust relationship between Git and its configuration files. An attacker who gains write access to a repository mounted in direct mode can inject malicious entries into the .git/config file or associated global configurations. These entries specify external programs that Git will execute during subsequent operations such as fetches initiated by users in clone-mode sandboxes, or kit pushes starting from version 0.39.0 of Docker Sandboxes. Although clone-mode sandboxes are provided with read-only mounts to the host repository, preventing them from directly modifying configuration files, an attacker who has already compromised a direct-mode sandbox can alter these settings beforehand. Once modified, any subsequent interaction by a legitimate user or automated process triggers the execution of the malicious program on the host system.
The operational impact is severe because the executed code runs with the permissions of the invoking user but completely outside the microVM isolation that Docker Sandboxes are designed to provide. This effectively neutralizes the security boundary intended to protect the host environment from untrusted workloads. If an attacker can manipulate a shared repository used by multiple users or services, they could achieve remote code execution on the host machine whenever another user performs a git fetch or push operation using their own credentials. This scenario is particularly dangerous in multi-tenant environments where different teams share repositories but rely on sandboxing to prevent cross-contamination and privilege escalation.
This vulnerability aligns with CWE-94, which describes Improper Control of Generation of Code (Code Injection), as it involves the injection of executable commands through configuration files that are interpreted by a trusted application. Furthermore, from an ATT&CK perspective, this behavior maps to techniques involving Command and Scripting Interpreter abuse for lateral movement or privilege escalation, specifically leveraging legitimate system utilities like Git to execute malicious payloads without triggering typical security alerts associated with direct binary execution. The lack of neutralization of repository-controlled configuration settings constitutes a significant deviation from secure coding practices regarding the handling of untrusted input in security-critical applications.
Mitigation strategies primarily involve upgrading Docker Sandboxes to version 0.50.0 or later, where this issue has been resolved by implementing stricter validation and isolation mechanisms for Git configurations. In environments where immediate patching is not feasible, administrators should enforce strict read-only access controls on repository directories mounted in direct mode to prevent unauthorized modification of .git/config files. Additionally, restricting the use of external hooks and fsmonitor settings within organizational policies can reduce the attack surface. Security teams should also monitor for unusual Git activity patterns that might indicate exploitation attempts, such as unexpected invocations of external programs during standard version control operations.