Docker Desktop is widely used across NZ development teams for local container work, CI pipelines, and dev/test environments. A newly disclosed privilege escalation flaw (CVE-2026-6406, CVSS 8.8) breaks the Enhanced Container Isolation boundary that many teams rely on as a safety net — meaning a compromised container can escape its sandbox and gain access to the host.
What Happened
Zero Day Initiative has published ZDI-26-299, a local privilege escalation vulnerability in Docker Desktop discovered by Nitesh Surana of Trend Research. The flaw sits in how Docker CLI arguments are processed and stems from an exposed dangerous function that should not be callable from within a container context.
To exploit the issue, an attacker first needs the ability to run low-privileged code inside a container. From there, they can abuse the exposed function to escalate privileges and reach resources that Enhanced Container Isolation (ECI) is specifically designed to protect. Because the scope changes (CVSS S:C), the impact crosses the trust boundary between container and host.
Enhanced Container Isolation is the hardening feature many organisations enable to let developers run untrusted images or third-party tooling more safely — particularly on managed developer machines. This vulnerability effectively undermines that assumption. A malicious image pulled from a public registry, a compromised build dependency, or a supply-chain attack inside a container could be enough to pivot onto the developer's workstation.
Docker has released a fix in Docker Desktop 4.59.0. Given the disclosure is now public and the technical details point clearly at the CLI argument handling path, working exploits should be expected in short order.
Key Takeaways
-
CVE-2026-6406 is a local privilege escalation in Docker Desktop with a CVSS score of 8.8.
-
The bug bypasses Enhanced Container Isolation — a feature many orgs enable specifically to contain untrusted workloads.
-
Exploitation requires code execution inside a container, which is achievable via malicious images or compromised dependencies.
-
The fix is available in Docker Desktop 4.59.0; earlier versions remain exposed.
-
Developer workstations are high-value targets — they typically hold source code, cloud credentials, and signing keys.
-
The vulnerability was discovered by Trend Research, reinforcing the value of coordinated disclosure through ZDI.
What NZ Businesses Should Do
-
Patch Docker Desktop to 4.59.0 or later across all developer and engineering workstations. Track compliance through your endpoint management tooling and treat laggards as a priority.
-
Audit container image sources. Restrict developers to trusted registries where practical, and scan images in CI for known-bad content. Trend Vision One™ Cloud Security / CNAPP provides image and registry scanning that integrates into developer workflows.
-
Harden developer endpoints. TrendAI Standard Endpoint Protection on developer machines gives behavioural detection for post-exploitation activity — valuable given developer devices often run with elevated local privileges and hold sensitive secrets.
-
Correlate developer workstation telemetry with your SOC. Feed endpoint, identity, and cloud signals into Trend Vision One™ SecOps so that a container escape followed by credential theft or anomalous cloud API activity is caught as a single incident rather than isolated alerts.
-
Review your container attack surface. Use Trend Vision One™ Cyber Risk Exposure Management (CREM) to identify unpatched Docker installs, exposed developer assets, and related risk factors across the environment.