GPU VulnDB

Database/Container, Kubernetes & orchestration

Docker Sandboxes: repository-controlled git config executes programs on the host outside the microVM

CVSS 7.1CVE-2026-121614Container, Kubernetes & orchestrationcurated

Impact

A repository whose .git/config an attacker can modify can set core.fsmonitor (or another hook-like setting) that git then runs on the host during a later clone-mode fetch or an sbx kit push. The program runs as the invoking user, outside the microVM boundary that Docker Sandboxes exists to provide, so the isolation an operator relies on when running agent or untrusted-code workloads against checked-out repos does not hold. On a shared build or agent host this turns a poisoned repo into code execution in the developer or CI account that drives the sandbox. Requires the attacker to already be able to write the host repo (for example via a direct-mode sandbox mounted read-write) and requires a user-initiated git action afterwards.

Who can reach it

An attacker who can modify a host repository's git configuration - for example code running in a direct-mode sandbox with that repo mounted read-write - then waits for the user to run a clone-mode fetch or sbx kit push. No authentication to the host is needed beyond that write access; user action is required. Clone-mode's read-only mount alone does not grant the write.

What to do

Upgrade Docker Sandboxes to 0.50.0; affected range is 0.31.0 through 0.49.x. Replacing the sbx binary and restarting any running sandboxes is sufficient - no host reboot. Until then, avoid mounting untrusted repositories read-write in direct mode.

References

Related entries

All Container, Kubernetes & orchestration entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.