Is CVE-2019-15752 (Docker Desktop Community Edition Privilege Escalation) being exploited in the wild?

What the KEV listing tells you about active exploitation

CISA’s inclusion of a CVE in the Known Exploited Vulnerabilities catalogue is the strongest practical signal that exploitation has moved beyond theory. For defenders, that changes the question from “could this be used?” to “where is it exposed, and how quickly can we remove the path?” For CVE-2019-15752, the issue is local privilege escalation in Docker Desktop Community Edition.

The exploit condition matters because it does not require remote unauthenticated access. A local foothold, a low-privilege account, or a foothold gained through another issue can be enough to turn a Docker Desktop weakness into a broader host compromise. That is why exploited-in-the-wild CVEs in desktop and developer tooling deserve the same urgency as server-side issues when they can cross a privilege boundary.

For broader exploit-prioritisation context, CISA’s KEV catalogue is the operational reference, while the national CVE record and vulnerability databases provide the canonical record for the flaw itself. A practical triage workflow is to confirm whether the vulnerable product is installed, then determine whether any standard user on the host can reach the vulnerable path or binary placement location.

• CISA Known Exploited Vulnerabilities Catalog
• CVE Program
• NIST National Vulnerability Database

Why this Docker Desktop flaw is operationally significant

This vulnerability is important because Docker Desktop is often present on developer workstations, build hosts and other machines that already hold sensitive credentials, source access and deployment authority. A local privilege escalation on that kind of endpoint can become a stepping stone to code repositories, signing material, cloud credentials or CI/CD access if the workstation is poorly segmented.

Container Security Guide is useful here because the issue sits at the intersection of desktop hardening, container runtime trust and host escape risk. The practical concern is not only the vulnerable binary placement, but whether developers run Docker with excessive host access, shared mounts, or other configurations that make a local escalation materially more damaging.

Current guidance for exploited container-adjacent flaws is to treat the host as part of the blast radius. If a developer workstation can reach production secrets, cloud consoles or internal package signing workflows, a local escalation can become an enterprise issue rather than a single-machine problem.

• NIST SP 800-190 Container Security
• FIRST EPSS

What to do when patching or removal is not immediate

If the affected Docker Desktop build is still present, the safest response is to remove exposure first, then verify whether the host has already been abused. If patching must wait, reduce the number of users who can log on interactively, restrict local admin rights, and review whether the Docker installation path and supporting directories are writable by unintended users.

The specific file-placement pattern in this CVE means that integrity checks matter. Look for unexpected binaries in the version-bin directory, review recent changes to Docker Desktop support files, and validate whether any suspicious process execution lines up with a normal update or install event. If the machine is a developer endpoint, also inspect whether the local compromise could have exposed registry logins, cloud tokens or build credentials.

Zero-Day and Exploited Vulnerabilities Guide aligns with the right response pattern here: emergency mitigation, then compromise assessment, then follow-up hunting. The key decision is whether the host is merely exposed or whether the host should now be treated as potentially compromised.

• Vulnerability Management Guide
• MITRE ATT&CK Enterprise Matrix

Risk and Threat Considerations

The main risk is privilege boundary collapse on a workstation that may already hold trusted access, developer tooling and sensitive sessions. Because the flaw is local, an attacker who already has a foothold can use it to move from ordinary user access to elevated host control, which can materially widen the impact of a separate initial compromise.

Failure mechanism: The attacker abuses the trusted Docker Desktop path by placing a trojan horse docker-credential-wincred.exe file in the writable version-bin location, causing a higher-privilege process or update path to execute attacker-controlled code.

Impact: Successful exploitation can grant elevated host privileges, enabling credential theft, persistence, local defense evasion and access to development or deployment assets on the affected machine.

Practitioner Guidance

What to verify: Confirm whether Docker Desktop Community Edition is installed, whether standard users can write to the vulnerable path, and whether the host has any evidence of unexpected binary replacement or recent privilege escalation activity.

Decision rule: If the endpoint has developer, build or cloud access, treat the host as high value and prioritise containment and credential review before you assume the machine is clean.

Practitioner takeaway: For an exploited local privilege escalation, the right question is not just whether the CVE exists on disk, but whether the workstation’s trust relationships turn a local bug into a wider environment compromise.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2019-15752 (Docker Desktop Community Edition Privilege Escalation)?
• CVE-2019-15752 (Docker Desktop Community Edition Privilege Escalation)
• Is CVE-2019-1388 (Microsoft Windows Certificate Dialog Privilege Escalation) being exploited in the wild?
• Is CVE-2019-0880 (Microsoft Windows Privilege Escalation) being exploited in the wild?