Docker Desktop 针对 Windows 和 macOS 系统的版本存在一个严重漏洞，即便 " 增强容器隔离（ECI）" 保护功能处于开启状态，攻击者仍可通过运行恶意容器入侵主机。

该安全问题属于服务器端请求伪造（SSRF）漏洞，目前已被编号为 CVE-2025-9074，其严重等级被评定为 9.3 分（极高）。

在 Docker Desktop 上运行的恶意容器，无需挂载 Docker 套接字，就能访问 Docker 引擎并启动更多容器。这可能导致主机系统上的用户文件被未授权访问，且增强容器隔离（ECI）无法缓解该漏洞带来的风险。

安全研究员兼漏洞赏金猎人 Felix Boulet 发现，任何运行中的容器都能未经认证访问 "http://192.168.65.7:2375/" 地址下的 Docker Engine API。他通过演示证明，只需两个 wget HTTP POST 请求，就能创建并启动一个新容器，将 Windows 主机的 C 盘挂载到该容器的文件系统中。

Boulet 的概念验证（PoC）漏洞利用代码无需在容器内获取代码执行权限。Pvotal Technologies 公司的 DevSecOps 工程师、NorthSec 网络安全会议的挑战设计员 Philippe Dugre 证实，该漏洞影响 Docker Desktop 的 Windows 和 macOS 版本，但不涉及 Linux 版本。

由于操作系统本身的安全防护机制，该漏洞在 macOS 系统上的危险性相对较低。他能在 Windows 系统的用户主目录中创建文件，但在 macOS 系统上，若未获得用户许可，则无法完成同样的操作。 

在 Windows 系统中，Docker Engine 通过 WSL2 运行，攻击者可作为管理员挂载整个文件系统，读取任何敏感文件，最终甚至能通过覆盖系统 DLL 文件，将权限提升至主机系统管理员级别。

然而在 macOS 系统中，Docker Desktop 应用仍存在一层隔离机制，尝试挂载用户目录时会向用户请求许可。默认情况下，Docker 应用无法访问文件系统的其他部分，也不会以管理员权限运行，因此相比 Windows 系统，macOS 主机要安全得多。

不过，Philippe Dugre 也提醒，即便在 macOS 系统上，仍存在恶意活动的操作空间——攻击者可完全控制应用程序和容器，这意味着他们可能在无需许可的情况下植入后门或修改配置。他还指出，该漏洞极易被利用，其漏洞利用代码仅由三行 Python 代码构成，这一点也印证了这一说法。 

目前，该漏洞已被报告给 Docker 公司，Docker 上周发布的 Docker Desktop 4.44.3 版本中修复了该问题。