Docker 11月安全更新分两类看：跑 Swarm 的抓紧，单机的顺手升级

11 月 3 日发布的 Docker Engine 29.9.3，版本号看着像例行小更新，发行说明里实际躺了四个 CVE 和两条 BuildKit 安全公告。这批漏洞不用全员恐慌，但风险人群分得很清楚：跑 Swarm 集群的最急，自己写 Go 服务解析外部数据的排在第二，单机跑容器的顺手升级就行。

四个 CVE，按人群拆

第一组是解析库的洞。CVE-2026-116587（评分 7.5）藏在 go-jose 库里，解析构造过的 RSA JWK 会把 CPU 打满，go-jose 4.1.6 修复；CVE-2026-116591（评分 8.7）在 klauspost/compress 里，特定的 zstd 双块帧能让进程直接 panic，1.20.2 修复。这两个洞对 Docker daemon 本身影响有限，发行说明没写清 daemon 哪条路径碰了这些库，CISA 的评估也认为 zstd 这条被实际利用的可能性低。真正要紧张的是拿 Go 写服务的人：如果程序解析外部传来的 JWK 或 JWT，或者解压不是自己生成的 zstd 数据，翻 go.mod 把这两个模块升上去，比升 Docker 更要紧。

第二组针对 Swarm，严重度上了一个台阶。CVE-2026-115538：firewalld 重载时会冲刷 Docker 写进 iptables 的规则，本该加密、防伪造的 overlay 网络就这么裸奔了——加密没了，伪造包也能进来。CVE-2026-115539 更扎心：攻击者只要先拿到一台 worker 节点的 TLS 证书和私钥，就能在 Swarm leader 切换后的短窗口内换成 manager 证书，从普通节点权限一路升到控制平面。worker 机器通常是最暴露的那台，这个前提并不难满足。

BuildKit 两条，CI 机器重点查

随版本更新的 BuildKit v0.34.2 修了两条：一条是同一个 Git 源引用的元数据被解析两次时，解析器缓存投毒能打崩 daemon；另一条是有权限访问 BuildKit 控制 API 的恶意客户端，能在 BuildKit 状态目录之外给文件设扩展属性，进而提权。生产节点和 CI 机器都在射程内，多人共用的构建机尤其要看最后这条。

不跑 Swarm 的怎么办

没用 Swarm 的读者看到 CVE-2026-115539 那条先别慌，两个前提你大概率都不满足：攻击者得先拿到 worker 节点的证书和私钥，你的机器还得跑在 Swarm 集群里。但要顺手做两件防患的事。一是检查有没有暴露的 Docker daemon：docker ps 能被外网直接访问的机器，2375 端口裸奔等于把 root 交给互联网，这类配置在任何安全公告面前都是放大器。二是给监控加一条规则，PHP worker 或容器进程拉起 shell、往外连陌生地址时告警——SwarmKit 这类证书升级漏洞爆出来时，能不能提前发现取决于日志粒度，不取决于补丁速度。

另一个判断标准值得记住：版本号 7.5 和 8.7 是分数，不是你的风险。解析库的洞评分再高，你的服务不解析外部 JWK 就跟你无关；Swarm 的洞描述再长，你不用 Swarm 就可以慢慢排期。把 CVSS 分数当成排序依据而不是恐慌依据，是这个行业最该普及的常识。

升级动作清单

1. docker version 看当前版本，低于 29.9.3 的进入下一步。
2. 宿主机按发行版把 docker-ce 升到 29.9.3 或更高，升级完 Swarm 节点逐台滚动重启。
3. 容器侧用到 docker 镜像的，把标签固定到 docker:29.9.3 或 docker:29.9.3-dind，别再挂 latest。
4. docker buildx version 确认 BuildKit 到了 v0.34.2，CI 机器一台台查。
5. 自己的 Go 服务查 go.mod：go-jose 升 4.1.6 以上，klauspost/compress 升 1.20.2 以上。
6. 用 firewalld 的 Swarm 节点，重载防火墙规则后进 overlay 网络里验一遍加密是否还生效。

顺带说一句，这版还修了个很烦的老毛病：daemon 在高负载下 container、image、system 三类 API 请求会挂起。被卡过监控面板的用户升级后应该有体感。

放在时间线里看，Docker 最近这三个月的补丁节奏明显变密了：29.9.0（10 月 8 日）修 Go 运行时的两条 HTTP/2 洞；29.9.1（10 月 14 日）跟着 containerd 2.4.2 修了三条——畸形 manifest digest 打崩 daemon、恶意 registry 返回伪造 Content-Length 撑爆磁盘、并行拉层时被假头信息搞崩；29.9.2（10 月 20 日）处理的是 Go 证书链问题，八个被吊销的 eMudhra 中间证书被拒收，依赖这些证书链的私有 registry 镜像拉取会直接失败。三个月四个版本，说明上游依赖的暴露面在接连出事，把「daemon 版本跟着安全公告走」当成常态运维项，比等大版本靠谱。

还有个容易漏的角落：DinD（docker-in-docker）。CI 里大量流水线用 docker:latest 起内层构建容器，外层宿主机升完了，内层镜像标签还在用旧版，等于洞还在。排查命令很简单，宿主机上跑 docker run --rm docker:latest docker version 看输出，或者直接翻流水线模板里的镜像引用，把 latest 全部换成 29.9.3 这种精确标签。标签固定这件事平时嫌麻烦，安全公告一出就值回票价。

我的看法

这批公告里我最在意的反而是 CVE-2026-115538——firewalld 和容器运行时抢 iptables 这笔烂账拖了多少年，双方各写各的规则，谁重载谁背锅。单机用户这次确实一条命令就能过关，但只要还在跑 Swarm，升级后的规则验证就不能省。安全补丁的意义从来不在打上那一刻，在打完之后确认它真的生效。