Docker Engine 近日被曝出一个高危安全漏洞，攻击者可在特定条件下绕过授权插件（AuthZ）的防护机制。该漏洞编号为 CVE-2026-34040（CVSS 评分：8.8），其根源可追溯至2024年7月披露的同组件高危漏洞 CVE-2024-41110，本质上是因为当时修复得不够彻底，遗留了隐患。
Docker 官方维护团队在上月底发布的公告中明确表示：“攻击者通过构造特殊的 API 请求，可使 Docker 守护进程在未转发完整请求体的情况下将请求发送至授权插件。此时，授权插件很可能因信息不全而放行本应拒绝的请求。”公告特别强调：“任何依赖授权插件通过检查请求体来实施访问控制的场景均可能受影响。”
包括 Asim Viladi Oglu Manizada、Cody、Oleh Konko 和 Vladimir Tokarev 在内的多名安全研究人员独立发现并报告了该漏洞。目前，Docker Engine 29.3.1 版本已发布修复补丁，建议用户尽快升级。
漏洞利用原理
根据 Cyera Research Labs 研究员 Tokarev 发布的详细报告，该漏洞的根源在于 CVE-2024-41110 的修复方案存在缺陷，未能正确处理超大的 HTTP 请求体。这直接导致攻击者可以通过“填充”单个 HTTP 请求的方式，成功创建一个拥有宿主机文件系统访问权限的特权容器。
想象一个典型的攻击场景：当攻击者的 Docker API 访问受 AuthZ 插件限制时，他可以通过将一个创建容器的请求（例如包含恶意挂载指令）填充至超过 1MB 的大小。这样一来，这个过大的请求体在抵达插件进行安全检查前就会被意外丢弃。“插件因为没有检测到任何需要拦截的依据，只能选择放行请求。”Tokarev 在其提交给 The Hacker News 的报告中解释道，“而 Docker 守护进程则会处理完整的请求，最终创建一个拥有宿主机 root 访问权限的特权容器——这意味着 AWS 凭证、SSH 私钥、Kubernetes 配置文件等所有机器上的敏感数据都将暴露。该漏洞对所有生态内的 AuthZ 插件都有效。”
AI自动化攻击链
更令人担忧的是，这个漏洞在自动化攻击场景下具有极高的危险性。例如，当那些基于 Docker 沙箱运行的 AI 编程助手（如 OpenClaw）在处理开发者日常工作流中的特制 GitHub 仓库时，可能会在无意中执行隐藏的提示注入攻击。恶意代码会利用 CVE-2026-34040 漏洞，通过上述方法绕过授权，创建特权容器并挂载宿主机文件系统。
一旦获得这个级别的访问权限，攻击者就能窃取云服务凭证，进而控制整个云账户、接管 Kubernetes 集群，甚至通过 SSH 密钥直接入侵生产服务器。
Cyera 的研究人员还发出警告，即使在没有恶意代码注入的情况下，AI Agent 本身也可能“自主”发现并利用这个漏洞。例如，当开发者在执行合法的调试任务（如排查 K8s 内存溢出问题）时，如果 AI Agent 因访问 kubeconfig 等文件被授权插件拒绝，它可能会尝试不同的方法。“AuthZ 插件拒绝挂载请求后，”Cyera 分析道，“一个具备 Docker API 访问权限且了解 HTTP 工作原理的 Agent，完全可以自主构造这种填充式的攻击请求。CVE-2026-34040 的利用不需要任何复杂的漏洞利用代码、特殊权限或特殊工具，仅仅需要一个被填充的 HTTP 请求。任何能阅读理解 Docker API 官方文档的 AI Agent 理论上都有能力实现这一点。”这无疑为云原生环境下的自动化安全带来了新的挑战。
临时缓解措施
在官方补丁全面部署之前，建议采取以下临时防护措施来降低风险：
- 停用依赖请求体检查的 AuthZ 插件：如果您的授权插件主要依靠检查请求体内容（如
Binds 挂载参数）来做决策，可考虑暂时停用。
- 严格限制 Docker API 访问：遵循最小权限原则，确保只有可信的、必要的实体才能访问 Docker 守护进程的 API 接口。
- 启用 rootless 模式运行 Docker：这是当前最有效的缓解手段之一。
“在 rootless 模式下，即使创建了所谓的‘特权容器’，容器内的 ‘root’ 用户也会被映射到宿主机上的一个非特权用户 ID（UID）。”研究员 Tokarev 强调，“这能将攻击的影响范围从‘完全主机沦陷’降级为‘仅某个非特权用户被入侵’。对于无法完全采用 rootless 模式的环境，可以使用 --userns-remap 参数来实现类似的 UID 映射效果。”
参考来源：
你对这类与容器编排和自动化工具深度耦合的安全漏洞怎么看？欢迎在云栈社区的相关板块分享你的见解和实践经验。 | 
发表于 2 小时前
|
查看: 3|
回复: 0
