一个新披露的Docker漏洞(CVE-2026-17106)被命名为“CopyEscape”。该漏洞允许恶意容器覆盖宿主机上的文件,并且在特定配置下,还能实现完整的Root级代码执行。
该漏洞由Imperva红队发现,影响广泛使用的docker cp命令,以及用于AI Agent工作流的Docker沙箱中的相关sbx cp命令。
如果被利用,CopyEscape可让恶意容器逃逸出其隔离环境,在客户端主机上写入或覆盖任意文件,并且在Linux系统的特定条件下,实现Root级代码执行。
Part01
该漏洞可获取Root访问权限
该漏洞位于Docker的归档传输管道中,也就是在容器与宿主机之间移动文件的机制。当用户执行类似docker cp container:/path/to/file.txt ./file.txt的简单命令时,Docker并非直接进行文件系统复制。
相反,守护进程会遍历容器的实时文件系统,将所选路径打包成tar归档文件,然后将该归档文件交给Docker CLI在本地机器上进行解压。
这一设计基于两个假设:守护进程生成一致的归档文件,CLI将每个解压出的文件都保留在用户所选的目标目录内。Imperva的研究人员找到了一种方法,能在一次复制操作中同时打破这两个假设。
该漏洞的利用方式将文件系统竞态条件与一个有缺陷的符号链接检查结合了起来。由于Docker在遍历归档时只锁定其内部状态,而不会锁定容器内运行的进程,攻击者可以在扫描过程中操纵文件。
通过一系列精心定时的目录交换操作,恶意容器先诱骗Docker的遍历器记录某个目录,然后悄悄将该目录替换成一个指向预期目标之外(例如/usr/bin)的符号链接。
Docker解压代码中的一项验证检查会检查一个构造出的路径,但实际上却使用归档中另一个未经验证的路径来创建符号链接。这种不匹配使得攻击者的文件能够落到符号链接指向的任何位置,从而完全绕过沙箱。
由于docker cp是收集构建产物、日志和取证证据等日常任务的基础操作,该漏洞直接威胁到CI/CD流水线、开发者工作站和应急响应工作流。具有讽刺意味的是,安全分析师为了调查而从受感染容器中提取证据时,可能会在不知不觉中触发该漏洞。
在macOS上,Docker Desktop的守护进程运行在虚拟机内,但CLI仍然在本地解压文件。这意味着攻击者可以覆盖shell启动脚本、SSH配置或LaunchAgents,从而在下次打开终端时实现代码执行。
在Linux上,如果docker cp以提升的权限运行(这在自动化场景中很常见),同样的写入原语可以替换runc等系统二进制文件,将文件覆盖直接变成即时的Root访问权限。
研究人员还证实,该漏洞影响Docker沙箱的sbx cp命令,这使得AI编码Agent环境在从不受信任的沙箱中检索文件时,面临同样的目标逃逸风险。
Part02
修复与缓解措施
Docker已在Docker Engine和CLI 29.7.2、Docker Desktop 4.86.0以及Docker Sandboxes 0.38.0中修复了该漏洞。漏洞披露流程始于2026年4月,期间多次延期,以解决早期修复方案引发的回归问题。
无法立即升级的组织应避免对不受信任或正在运行的容器执行docker cp,在复制文件前先停止容器,杜绝使用sudo docker cp,并且只通过隔离的一次性环境检索可疑数据。
这一事件带来的根本教训是:归档解压本身就是一个安全边界,一旦符号链接和并发文件更改进入场景,仅靠路径字符串检查是无法保证安全的。
参考来源:
CopyEscape Docker Vulnerability Lets Malicious Containers Overwrite Host Files and Gain Root
https://cybersecuritynews.com/copyescape-docker-vulnerability/