Docker 29.6.2 已发布，这次更新的重点不是新增功能，而是修复 Docker Engine 中的多个安全漏洞。已披露的问题涉及从捆绑文件检出 Git 源代码、前端参数处理以及 LLB 文件操作。对运行共享构建平台、接收外部构建上下文或允许团队提交 Dockerfile 的环境，这类缺陷值得优先处理。
三个漏洞对应的风险入口
本次摘要列出了三个 CVE：
- CVE-2026-15793：从捆绑文件检出 Git 源代码时可能触发命令注入。
- CVE-2026-15792：前端发送错误参数可能导致系统崩溃。
- CVE-2026-15791：LLB 文件操作可能被诱导执行非预期删除；现有摘要中的路径与影响描述并不完整，部署前应结合正式安全公告确认边界。
这些问题共同指向 Docker 构建链路，而不只是容器启动阶段。BuildKit 使用 LLB 描述底层构建图，Dockerfile 前端负责把上层构建定义转换为该图。因此，负责构建的节点、远程 BuildKit 实例和 CI Runner 都应纳入排查范围。
需要注意的是，仅凭版本摘要无法判断漏洞是否要求本地权限、是否能跨租户利用，也不能据此推断所有 Docker 部署都能被远程攻击。实际优先级还应结合构建输入是否可信、构建服务是否共享以及攻击者能否控制前端参数等条件确定。
先盘点真正执行构建的节点
不要只检查开发者电脑上的 Docker CLI。CLI 可能连接远程 daemon，而 docker buildx 也可能把任务发送给独立 BuildKit 节点。可以这样实践：运行下面的只读命令，记录 Engine 版本、当前上下文和 Builder 节点。
set -eu
echo '== Docker client and server =='
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
echo '== Current Docker context =='
docker context show
echo '== Buildx version =='
docker buildx version
echo '== Builder nodes =='
docker buildx ls
如果 server 版本为空或命令报连接错误，应先确认当前 Docker context。若 docker buildx ls 展示多个远程节点，则每个节点都需要单独核对，升级本机 CLI 并不会自动修复远端 Engine 或 BuildKit。
在 Debian/Ubuntu 上升级到 29.6.2
下面示例假设机器使用 Docker 官方 APT 仓库，且仓库已经提供 29.6.2。脚本会先查找实际的软件包版本字符串，找不到时直接退出，避免误装其他版本。运行前应在测试节点确认发行版仓库和维护窗口。
set -euo pipefail
ENGINE_VERSION="$({ apt-cache madison docker-ce 2>/dev/null || true; } \
| awk '$3 ~ /(^|:)29\.6\.2([-.~]|$)/ {print $3; exit}')"
if [ -z "$ENGINE_VERSION" ]; then
echo 'docker-ce 29.6.2 is not available in the configured APT repositories' >&2
exit 1
fi
echo "Installing Docker packages: $ENGINE_VERSION"
sudo apt-get update
sudo apt-get install -y \
docker-ce="$ENGINE_VERSION" \
docker-ce-cli="$ENGINE_VERSION" \
containerd.io \
docker-buildx-plugin \
docker-compose-plugin
sudo systemctl restart docker
docker version --format 'client={{.Client.Version}} server={{.Server.Version}}'
包版本通常带有 epoch、发行版代号和修订号，因此不应猜测完整字符串。升级前还要保存当前包版本与 daemon 配置，以便出现插件兼容性或运行时回归时按组织流程回退：
dpkg-query -W 'docker-ce' 'docker-ce-cli' 'containerd.io' \
'docker-buildx-plugin' 'docker-compose-plugin' 2>/dev/null || true
sudo systemctl cat docker
sudo test -f /etc/docker/daemon.json && sudo cat /etc/docker/daemon.json || true
把最低版本检查放进运维流程
完成升级并不等于所有节点都会持续保持合规。自动扩容的 Runner、长期离线的开发机和旧镜像创建的构建节点都可能重新引入低版本。可以在节点启动或 CI 预检阶段加入版本门禁：
#!/usr/bin/env bash
set -euo pipefail
required='29.6.2'
installed="$(docker version --format '{{.Server.Version}}')"
lowest="$(printf '%s\n%s\n' "$required" "$installed" | sort -V | head -n1)"
if [ "$lowest" != "$required" ]; then
echo "Docker Engine $installed is below required version $required" >&2
exit 1
fi
echo "Docker Engine $installed satisfies minimum version $required"
这个检查适合常见的数字版本，但预发布版本和供应商自定义后缀可能需要改用发行版包管理器或资产管理平台进行比较。它也只验证当前 context 指向的 Engine，不能替代对所有 Buildx 节点的资产盘点。
升级后的检查清单
升级应优先覆盖接受不可信构建输入的共享 Builder 和 CI Runner，然后处理开发与内部构建节点。维护窗口内建议完成以下检查：
- 确认客户端和服务端版本，避免只更新
docker-ce-cli。 - 枚举 Docker contexts、Buildx builders 和远程节点。
- 重跑包含 Git 构建上下文、Dockerfile 前端和文件复制操作的代表性流水线。
- 检查
docker服务日志、构建缓存和磁盘占用是否异常。 - 在无法立即升级时，暂时限制外部构建上下文、不受信任的 Dockerfile 和共享 Builder 访问。
- 阅读完整安全公告，确认 CVE-2026-15791 被截断的影响描述、受影响版本范围和供应商缓解措施。
Docker 29.6.2 的处理重点是构建基础设施，而不仅是生产容器宿主机。最稳妥的落地方式，是先列出真正执行构建的所有 Engine 与 BuildKit 节点，再分批升级、验证典型流水线，并用最低版本策略防止旧节点重新接入。