Docker Desktop ECI Flaw: High-Severity LPE Vulnerability Enables Container Escapes

Docker Desktop is affected by a local privilege escalation (LPE) vulnerability within its Enhanced Container Isolation (ECI) component, carrying a CVSS score of 8.8. Disclosed on April 23, 2026, in advisory ZDI-26-299, the flaw allows an attacker with low-privileged container access to bypass security boundaries and compromise protected resources. For developers and DevOps teams relying on ECI as a hardened barrier between containers and the host workstation, this discovery challenges a core security assumption: "enhanced" isolation is insufficient if an exposed function in CLI processing remains accessible to malicious actors.

Anatomy of the CLI Processing Vulnerability

Advisory ZDI-26-299 characterizes the issue at a technical level: "The specific flaw exists within the processing of Docker CLI arguments. The issue results from an exposed dangerous function." While the description is concise, it pinpoints the risk area. This is not a bug within the container runtime itself, nor a Linux kernel vulnerability, but rather a dangerous function left accessible during the handling of arguments passed to the Docker command-line interface.

The location of this flaw is significant for two reasons. First, CLI processing occurs at the boundary between the user and the system, where input data is inherently less trustworthy. Second, Enhanced Container Isolation (ECI) was specifically designed to create a secure perimeter around these touchpoints. An exposed function in that processing logic suggests a structural gap in the perimeter rather than a simple configuration error that could be mitigated with a basic rule adjustment.

Specific exploitation mechanics have not been detailed in the advisory, and no public proof-of-concept (PoC) code is currently available. It is established, however, that an attacker inside a low-privileged container can interact with this function to escalate privileges. The "Scope Changed" status in the CVSS vector (S:C) indicates that the impact extends beyond the directly vulnerable component, potentially affecting host resources normally shielded by isolation layers.

Exploitation Prerequisites and Risk Profile

The prerequisite for exploiting this flaw is specific: "An attacker must first obtain the ability to execute low-privileged code within a container in order to exploit this vulnerability." While this precludes unauthenticated remote attacks, the threat remains significant. In modern development pipelines, a low-privileged container is often the initial entry point for an attacker who has compromised a container image, injected malicious code into a dependency, or exploited a vulnerable application running within the container.

Developer workstations represent the primary environment at risk. Docker Desktop typically operates with privileged access to the host machine to manage containers, volumes, and networking. If ECI fails, an attacker could potentially interact with the host filesystem, accessing credentials, source code, SSH keys, and other development secrets. The very architecture that makes Docker Desktop efficient—native OS integration, file sharing, and port forwarding—acts as an impact multiplier when isolation boundaries fail.

The risk profile is particularly acute for enterprise environments with strict security policies. Where ECI was mandated as a primary security control, this flaw renders that control unreliable until the patch is applied. The advisory does not list any temporary workarounds other than updating the software.

Disclosure and Patch Timeline

Nitesh Surana, a researcher with Trend Research, reported the vulnerability to Docker on January 9, 2026. The coordinated publication of advisory ZDI-26-299 followed on April 23, 2026, after a disclosure embargo of more than three months. This window is consistent with the complexity of patching CLI processing in a product widely deployed across diverse developer environments, though public details regarding the communications between the researcher and vendor remain unavailable.

The advisory identifies version 4.59.0 as the version containing the fix. Users should verify the availability of this package for their specific operating system. Notably, the lack of a CVE identifier at the time of publication may complicate formal tracking within some corporate patch management systems.

"Fixed in Docker Desktop 4.59.0" — Advisory ZDI-26-299, Zero Day Initiative

Recommended Remediation Steps

1. Verify the installed version of Docker Desktop and prioritize an update to 4.59.0 or higher. In managed environments, coordinate with IT teams for prioritized patch distribution.
2. Review ECI usage policies until the fix is deployed. If enhanced isolation was relied upon to protect sensitive data, consider compensatory measures such as running untrusted containers in more strictly virtualized or isolated environments.
3. Audit containers running with reduced privileges that have access to critical resources. While the vulnerability requires existing low-privileged code execution, the attack surface remains relevant wherever containers interact with internal networks or secrets.
4. Monitor for CVE assignment and updates to the ZDI advisory for additional technical details or the emergence of PoC code, which could lead to functional exploits.

Impact on the ECI Trust Model

ECI was introduced to address a tangible problem: developers frequently use containers from unverified sources, and the traditional Docker Desktop security model left a significant attack surface exposed on the host machine. Vulnerability ZDI-26-299 demonstrates that even security-focused architectures can fail at unexpected points, particularly where interface code—in this case, CLI processing—is tasked with sensitive operations without sufficient hardening.

This case raises broader questions for the industry regarding the auditability of the path between CLI input and privileged execution in integrated development tools. As unified interfaces between hosts and containers become more common, the systemic risk of "dangerous functions" within those interfaces remains a critical concern for anyone building sandbox environments with similar security promises. Docker Desktop 4.59.0 addresses this specific flaw, but the robustness of CLI processing as an attack surface remains a valid area of inquiry.

FAQ

Does this vulnerability affect Docker Engine on Linux servers?

No. The advisory specifically identifies Docker Desktop, the workstation product, and its Enhanced Container Isolation component. Docker Engine running on Linux servers is not listed as affected.

Is it necessary to disable ECI as a temporary measure?

The advisory does not recommend disabling ECI or suggest any specific workarounds. Upgrading to version 4.59.0 is the primary remediation. If the patch cannot be applied immediately, assess your risk profile to determine if compensatory measures are required.

Are there any public exploits or reports of active attacks?

At the time of writing, advisory ZDI-26-299 and available sources report no known public exploits or active attacks. While the current lack of technical details and PoC code limits the immediate probability of mass exploitation, this may change as more information becomes available.

Information has been verified against cited sources and is current as of the time of publication.

Sources

• Zero Day Initiative Advisory ZDI-26-299