CVE-2019-15752: Docker Desktop Community Edition Privilege Escalation Vulnerability

CVE-2019-15752 is a local privilege-escalation vulnerability in Docker Desktop Community Edition. It stems from incorrect permissions on a directory that the product uses, allowing a local user to plant a malicious executable that the software may later run with higher privileges. For IT and security teams, this matters because any workstation or shared host running the affected product can become a path from a low-privilege account to elevated control, increasing the blast radius of phishing, malware, or insider activity.

Public detail is limited to the CISA description and the CWE classification; confirm exact affected builds, fixed versions, and platform scope against the vendor advisory before acting.

How it works

The weakness is CWE-732: Incorrect Permission Assignment for Critical Resource. Docker Desktop Community Edition uses a directory under %PROGRAMDATA%\DockerDesktop\version-bin\ that is writable in a way that permits a local user to place a file named docker-credential-wincred.exe. When the product later invokes credential-helper logic, it can execute that planted binary, giving the attacker the privileges of the process that loads it.

An attacker who already has local code execution or an interactive session on the machine does not need remote network access. They simply drop the trojan horse into the world-writable (or insufficiently restricted) path and wait for, or trigger, a Docker Desktop operation that calls the helper. No remote exploit chain is described in the available facts; the abuse is local and relies on the insecure permissions of that specific directory and filename.

Am I affected? How to find it in your systems

Docker Desktop Community Edition is commonly installed on developer workstations, CI agents, and lab machines running Windows. Inventory every endpoint that has Docker Desktop present:

• Query software inventory or endpoint-management tools for “Docker Desktop” and record the edition and build.
• On Windows hosts, check for the existence of %PROGRAMDATA%\DockerDesktop\ and the version-bin subdirectory; note the ACLs on that folder.
• Confirm against the vendor advisory which Community Edition builds are vulnerable; do not assume Enterprise or other SKUs are identical.

Telemetry signs of exploitation are limited because the attack is local file placement. Look for:

• Unexpected creation or modification of docker-credential-wincred.exe under %PROGRAMDATA%\DockerDesktop\version-bin\.
• Process-creation events showing that binary launched by a Docker Desktop component, especially from non-standard paths or by low-privilege users.
• Sudden privilege elevation or new administrative sessions originating from developer accounts that normally lack admin rights.

If your EDR or file-integrity monitoring can baseline that directory, enable alerts on write activity by non-SYSTEM / non-admin principals.

How to remediate

Patch first. Apply the updates supplied by the vendor for Docker Desktop Community Edition exactly as described in the vendor advisory and in the CISA-required action (“Apply updates per vendor instructions”). After patching, verify that the version-bin directory permissions no longer allow unprivileged users to write arbitrary executables.

Additional hardening appropriate to this class of flaw:

• Re-apply or tighten NTFS ACLs on %PROGRAMDATA%\DockerDesktop\ so that only trusted administrative identities can create or modify files there.
• Remove or restrict local admin rights for developer accounts wherever feasible; privilege escalation is far less useful if the starting account is already constrained.
• Prefer least-privilege Docker configurations and avoid running the Desktop UI or daemon under highly privileged contexts when not required.

If you can't patch immediately

Until the vendor update can be deployed, reduce risk with compensating controls:

• Segment developer workstations from sensitive networks and crown-jewel systems so that a compromised Desktop host cannot easily reach production assets.
• Use application-control or WAF/endpoint rules (virtual patching) to block execution of binaries loaded from %PROGRAMDATA%\DockerDesktop\version-bin\ unless they are signed and known-good.
• If the credential-helper functionality is not required, disable or remove the wincred helper so the trojan filename is never invoked.
• Increase monitoring: alert on any write to the version-bin path and on process starts of docker-credential-wincred.exe. Retain these logs for later investigation.
• Temporarily remove local write access for standard users to the DockerDesktop program-data tree via Group Policy or configuration-management scripts.

These steps do not replace the patch; they only buy time.

If your data may have been exposed

Actively exploited local privilege-escalation vulnerabilities frequently become the foothold that leads to broader compromise and data theft. While ransomware use of this specific CVE is not documented, any successful elevation can enable credential dumping, lateral movement, or exfiltration. If you suspect the vulnerability was abused on a host that handled sensitive data or credentials, treat the incident as a potential breach: isolate the system, preserve forensic images, rotate secrets that may have been accessible, and review authentication logs for follow-on activity. You can also run a free exposure scan of your email addresses against known breach data sets to determine whether associated accounts already appear in public dumps.