Docker Desktop Zero-Day Allows Container-to-Host Privilege Escalation; Vendor Rejected Fix
A 0-day vulnerability in Docker Desktop for Windows lets attackers with high-privileged container access escalate to arbitrary code execution on the host, after Docker rejected the report as outside its threat model.
A critical zero-day vulnerability in Docker Desktop for Windows (ZDI-26-258, CVE pending) allows local attackers who have already obtained high-privileged code execution inside a container to escalate privileges and execute arbitrary code on the host system. The flaw, disclosed publicly on April 15, 2026, by Trend Micro's Zero Day Initiative, carries a CVSS score of 8.2 and currently has no patch available.
The vulnerability resides in the Docker Extensions functionality, specifically within the extension-manager component. According to the advisory, the issue stems from an exposed dangerous function that an attacker can leverage to break out of the container sandbox and run code in the context of the current user. The attack chain requires the adversary to first achieve high-privileged execution inside a container — a scenario that is realistic in multi-tenant environments, CI/CD pipelines, or compromised development machines where containers run with elevated permissions.
The disclosure timeline reveals a contentious back-and-forth between the researcher and Docker. Nitesh Surana of TrendAI Research reported the vulnerability to Docker on May 28, 2025. Docker requested technical clarification in June, and the researcher provided additional details in September. However, on September 12, 2025, Docker communicated that the attack scenario was outside its security threat model. After further discussion — including ZDI noting that the issue was a bypass of a previously exploited incident — Docker formally rejected the report on November 11, 2025, because exploitation required prior privileged access.
ZDI notified Docker of its intention to publish the case as a 0-day advisory on April 8, 2026, and the advisory was released one week later. The advisory notes that the only salient mitigation is to restrict interaction with the product — effectively limiting which users can run Docker Desktop or which containers can access the extension-manager. No official patch or workaround has been issued by Docker.
The decision to publish a 0-day advisory after a vendor rejection is relatively rare but not unprecedented. ZDI's policy allows for coordinated disclosure when a vendor declines to fix a vulnerability, particularly when the researcher demonstrates that the issue represents a real bypass of existing security boundaries. In this case, ZDI's timeline indicates that the vulnerability was a bypass of a previously exploited incident, suggesting that the underlying attack surface has been a repeated source of risk.
For organizations using Docker Desktop on Windows, the immediate risk is highest in environments where containers run with elevated privileges — such as development workstations, CI/CD runners, or shared container hosting platforms. An attacker who compromises a container in such an environment can use this flaw to gain code execution on the host, potentially accessing sensitive data, credentials, or other containers. The CVSS vector (AV:L/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H) reflects the need for prior high privileges but also the severe confidentiality, integrity, and availability impact once exploited.
This disclosure adds to a growing list of container escape vulnerabilities that challenge the assumption that containers provide strong isolation. While container security has improved significantly, flaws in the orchestration layer — such as Docker Desktop's extension system — continue to provide escape vectors. Until Docker addresses this issue, users should audit their container privilege configurations and consider restricting access to the Docker Extensions feature on Windows hosts.