Skip to main content
CVE-2025-9074VulnerabilityPublished Updated

CVE-2025-9074: Docker Desktop · Resource Exposure

Affects Docker DesktopSource CVE Database V5

0

Not known to be exploited · public exploit available (Exploit-DB) · CVSS 9.3 Critical.

Data as of 25 Oct 2026, 19:02 UTC

CVSS 4.0 base score
9.3Critical
How severe the flaw is on the 0–10 CVSS scale.
EPSS
1.8% chance of exploitation in 30 days – higher than 79% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

Exploitation evidence

t = 0 is the CVE’s publication on cve.org

  1. Disclosed: evidence found.

    CVE published 20 Aug 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  4. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

Timeline

  1. CVE ID reserved

    by Docker

    , 5 days before disclosure

  2. CVE published

    on cve.org

    , t = 0

  3. In Threat Radar

    record ingested

    , 19 minutes after disclosure

  4. First Exploit-DB entry (opens in a new tab)

    Docker Desktop 4.44.3 - Unauthenticated API Exposure

    , 168 days after disclosure

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

Affected software

ProductAffectedFixed in
Docker Docker DesktopAffected
  • =4.25
Fixed in–

AI-suggested

2) Restrict local container access to trusted users only and avoid running untrusted containers on Docker Desktop environments. 3) Disable or tightly control any Docker daemon exposure settings, especially the 'Expose daemon on tcp://localhost:2375 without TLS' option, even though the vulnerability exists regardless of this setting. 4) Use Enhanced Container Isolation (ECI) and other container security features as additional defense layers, though they do not fully mitigate this issue. 5) Monitor network traffic on the Docker subnet (192.168.65.7:2375) for unauthorized API calls or unusual container activity. 6) In Windows environments with WSL backend, limit permissions and consider additional host-level security controls to prevent unauthorized filesystem mounting. 7) Employ runtime security tools that can detect anomalous container behavior or privilege escalations. 8) Educate developers and DevOps teams about the risks of running privileged or untrusted containers locally. 9) Consider isolating development environments or using virtual machines to reduce risk exposure. These targeted measures go beyond generic advice by focusing on controlling local container access, monitoring Docker API usage, and preparing for patch deployment.

Description

A vulnerability was identified in Docker Desktop that allows local running Linux containers to access the Docker Engine API via the configured Docker subnet, at 192.168.65.7:2375 by default. This vulnerability occurs with or without Enhanced Container Isolation (ECI) enabled, and with or without the "Expose daemon on tcp://localhost:2375 without TLS" option enabled. This can lead to execution of a wide range of privileged commands to the engine API, including controlling other containers, creating new ones, managing images etc. In some circumstances (e.g. Docker Desktop for Windows with WSL backend) it also allows mounting the host drive with the same privileges as the user running Docker Desktop.

References

Community reviews

Loading reviews…