CVE-2026-126329: Docker Sandboxes privilege escalation through untrusted state directories
Docker Sandboxes reuses existing state and configuration directories without verifying their ownership. If sbx or sandboxd is run as root with HOME or, on Linux, XDGSTATEHOME pointing to an attacker-controlled location, a local unprivileged user can substitute control-plane sockets and configuration trusted by the root process, potentially executing commands as root. Exploitation requires a privileged invocation with an attacker-influenced environment. The issue affects Linux and macOS and is fixed in version 0.53.0.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Docker Sandboxesto a version that resolves this vulnerability.Fixed in 0.53.0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Linux and macOS systems are exposed when sbx or sandboxd is invoked as root while HOME, or on Linux XDG_STATE_HOME, points to a location controlled by an unprivileged user. A normal unprivileged invocation is not described as affected.
What does an attacker need to exploit it?
The attacker needs local access and influence over the environment used for a privileged sbx or sandboxd invocation. They must be able to control the state or configuration directory that the root process reuses.
How can I determine whether a system may be vulnerable?
Check whether the installed Docker Sandboxes version is earlier than 0.53.0 and review root-level sbx or sandboxd launch paths. Investigate whether HOME or, on Linux, XDG_STATE_HOME can be inherited from or set to a user-controlled directory.
What can be done before upgrading?
Do not run sbx or sandboxd as root with HOME or XDG_STATE_HOME directed to attacker-controlled locations. Ensure privileged invocations use root-owned state and configuration directories and do not inherit attacker-influenced environment values.