文章总结： CVE-2026-17106是Dockercp命令的容器逃逸漏洞，利用TOCTOU竞争条件与符号链接，使CLI解包时向宿主机任意路径写文件从而接管宿主机。该漏洞影响DockerEngine29.7.0以下版本。建议立即升级Docker至29.7.0及以上版本，避免对不可信容器执行dockercp，并在运行时启用只读模式增加利用难度。 综合评分： 95 文章分类： 漏洞分析,漏洞POC,漏洞预警,供应链安全,云安全
docker cp一个命令，宿主机就被接管：CVE-2026-17106逃逸漏洞复盘
零日手记 零日手记
随笔漫记安全路
2026年8月12日 08:37 北京
在小说阅读器读本章
去阅读
Docker的docker cp命令，每个用Docker的人都用过。复制文件进出容器，日常操作。
现在这个命令可以被恶意容器利用，往宿主机任意路径写文件——包括覆盖/usr/bin/runc，直接接管整台宿主机。
CVE-2026-17106，Imperva红队研究员Ron Masas发现，命名为CopyEscape。
漏洞原理：竞争条件+符号链接
docker cp的工作流程是这样的：Docker CLI向daemon请求容器内某个路径的文件，daemon把文件打包成tar流发回来，CLI在宿主机上解包。
问题出在打包和解包之间。
恶意容器在daemon打包文件的时候，跑一个竞争线程：daemon的文件系统遍历器走过的路径上，容器内进程把一个目录替换成一个绝对路径的符号链接。daemon打包出来的tar流里就同时包含了符号链接和它下面的子条目。
Docker CLI解包时，先创建了符号链接，然后解包子条目——顺着符号链接写到了宿主机上的任意路径。
这是一个TOCTOU（Time-of-Check-Time-of-Use）竞争条件。 daemon检查文件类型的时候看到的是目录，打包到一半容器把目录换成符号链接，CLI解包时跟随了符号链接。
写入的文件带着执行docker cp的用户的权限。如果用户是root，写入的文件就是root所有。
两个PoC：从创建文件到覆盖runc
研究员提供了两个演示。
macOS版：在宿主机home目录创建~/pwnd文件。非破坏性，证明逃逸可行。
cd macos
./demo-macos.sh
# docker cp <container>:/watched/file.txt ./file.txt
# 结果：宿主机上多了一个 ~/pwnd
Linux版：覆盖/usr/bin/runc。
sudo -s
cd linux
docker build -t copyescape-linux .
docker run --name copyescape-linux copyescape-linux
# 另一个终端触发
docker cp copyescape-linux:/watched/file.txt ./file.txt
# /usr/bin/runc 已被替换为攻击者脚本
# 下一次Docker执行任何容器命令时，以root身份运行攻击者代码
ls -l /imperva_red_team # 攻击标记文件
容器里的/watched/file.txt看起来是个正常文件——容器内进程cat它返回”top-level file”。但底层实际上是个目录，daemon遍历时容器内监控线程把它换成指向/usr/bin/runc的绝对路径符号链接。tar流里带了符号链接+子条目，CLI解包时通过符号链接把攻击者的shell脚本写进了/usr/bin/runc。
runc是Docker运行容器的底层runtime。 它被替换后，下一次Docker启动任何容器，执行的就是攻击者的代码，root权限。
不需要利用daemon权限提升，不需要逃逸容器namespace，只需要诱导有Docker CLI权限的用户执行一次docker cp。
影响版本和修复
漏洞在moby/go-archive库中，影响Unpack、UnpackLayer、Untar、UntarUncompressed和ApplyLayer等函数。
| 组件 | 受影响版本 | 修复版本 | | — | — | — | | moby/go-archive | < v0.3.0 | v0.3.0（7月30日） | | Docker Engine | < 29.7.0 | 29.7.0（7月30日） | | Docker Desktop | < 4.82.0 | 4.82.0 |
PoC测试环境：Docker Engine/CLI 29.6.1、Docker Desktop 4.81.0。
修复方式：升级到go-archive v0.3.0+，解包时拒绝跟随逃逸目标目录的符号链接。后续v0.3.1、v0.3.2、v0.3.3修了几个回归bug（绝对符号链接和硬链接的处理）。
攻击场景
这个漏洞的利用前提是：攻击者已经控制了容器内部，且能诱导宿主机上有Docker CLI权限的用户执行docker cp从该容器复制文件。
典型场景：
- 供应链攻击：攻击者在Docker Hub或私有镜像仓库上传恶意镜像，用户拉取后运行，然后
docker cp日志文件出来查看——触发逃逸 - 多租户环境：云平台上用户有Docker CLI访问权，平台用
docker cp做文件传输，恶意容器趁机逃逸 - CI/CD管道：构建脚本用
docker cp从构建容器里复制产物，如果镜像是第三方的，每次cp都是一次赌博 - 运维操作：管理员习惯用
docker cp从容器里拷日志、配置文件出来排查问题——这是最常见的触发方式
修复建议
- 立即升级Docker Engine到29.7.0+，Docker Desktop到4.82.0+
- 如果已经升级到29.7.0但遇到
docker cp报错，升级到29.7.1或29.7.2修复回归bug - 不要从不信任的镜像运行容器后执行
docker cp - CI/CD管道中如果必须从容器复制文件，确保镜像来源可信
- 运行容器时加
--read-only或限制容器内文件系统操作能力，增加竞争条件利用难度
参考链接
- PoC仓库：github.com/masasron/CopyEscape-CVE-2026-17106
- go-archive修复：github.com/moby/go-archive/releases/tag/v0.3.0
- GHSA-hfg8-hc9c-6c3h
- Docker Engine 29.7.0发布说明：github.com/moby/moby/releases/tag/docker-v29.7.0
- 研究员：Ron Masas（Imperva红队）
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：随笔漫记安全路 零日手记 零日手记《docker cp一个命令，宿主机就被接管：CVE-2026-17106逃逸漏洞复盘》
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论