服务对象与地域限制
PuppyIP 仅面向海外合规企业及其授权人员提供服务，不面向中国大陆地区开放或提供代理服务。本服务仅限用于中国大陆境外的合法业务活动，严禁在中国大陆境内使用本服务。
代理 IP 或服务器位于境外，不改变上述限制。不得通过中转、转接、共享或转售向中国大陆境内的最终使用者提供本服务。使用前请阅读用户服务协议。
本文要点
- 先找到实际承接 Duo 请求的网关和维护人，避免升级了错误组件。
- 把目标镜像、运行镜像和功能结果分别确认，不以下载成功代替完成。
- 准备恢复配置的方案；排错期间不要把脆弱旧版本当作长期恢复目标。
先对照公告：哪些网关需要升级
GitLab 2026 年 10 月 2 日公告修复 CVE-2026-90970，CVSS 9.9。具有 Duo Agent Platform 访问权限的已认证用户，在特定条件下可能绕过模板沙箱，在网关执行任意命令。
受影响范围为 AI Gateway ≥18.1.6 且 <19.2.4、≥19.3 且 <19.3.2、≥19.4 且 <19.4.1；对应修复版为 19.2.4、19.3.2、19.4.1。GitLab 托管网关已修复，包括 GitLab.com、Dedicated，以及使用托管网关的 Self-Managed，无需自行处理本补丁。
第一步：查网关部署，不只看 GitLab 网页版本
GitLab Duo 支持托管、自托管及混合配置。因此，Self-Managed 这个名称本身不能说明网关由谁维护；应按官方 Configure GitLab Duo 文档，确认当前功能实际使用的部署模式。
建议从配置负责人处取得三项信息：GitLab 主程序版本、网关所在部署及运行镜像、该部署的维护人。不要把网页页脚版本填进网关版本栏。使用内部域名时，还要查清域名后面接的是哪套服务；入口名称相同，不代表测试与生产共用一个实例。
先列出需要替换的实例和维护窗口。若存在多个副本，将每个副本都纳入后面的验收，防止只改了一台就宣布完成。本文给出的是基于公开文档的操作方法，并非对读者环境的实测。
第二步：选兼容补丁，保留原部署参数
官方安装文档要求使用与 GitLab 主版本、次版本匹配的最新稳定 AI Gateway 标签，格式为 self-hosted-vX.Y.*-ee；不要使用 nightly。
把兼容性与补丁范围一起核对：若自己的旧分支没有满足修复要求的受支持镜像，不宜直接跨分支套用最高版本。应先向维护团队或官方支持确认 GitLab 与网关的配套升级路线。
更新前保留原部署声明、配置文件位置及凭据引用方式，并确认有人能恢复它们。核对端口、网络、挂载和证书配置是否会随重建保留；工单只记引用和脱敏值，不复制密钥。建议先确认目标镜像能够获取，再进入停机步骤。
第三步：沿原部署方式替换镜像
Docker 部署按官方 Updating 路径停止、移除旧容器，再用新镜像重建，并带齐环境变量。Helm 部署须分别核对 chart 版本与 image.tag；沿用原 release、命名空间和必要配置，不能把 chart 升级成功当成镜像已更新。
具体执行以官方安装页和本环境原部署文件为准。先让维护人核对拟执行命令中的容器名、服务名和配置来源，再操作；不要把新装示例直接覆盖到现有生产部署。
Kubernetes 的标签可以指向不同镜像，digest 用于固定镜像内容；IfNotPresent 可能复用本地镜像。采用哪种策略应与现有发布流程一致，更新后仍要检查实际运行结果，不能只看标签文字没有变化。
第四步：确认服务真正使用了目标镜像
Docker 的 inspect 支持只输出指定字段。可在容器宿主机执行只读示例：docker inspect --type=container --format '{{.Config.Image}} {{.Image}}' gitlab-aigw。先把 gitlab-aigw 换成实际容器名；结果依次是配置的镜像引用和容器使用的本地镜像 ID。
再用 docker image inspect --format '{{.Id}} {{json .RepoDigests}}' 镜像引用 查询已取得的目标镜像。末尾中文占位符须换成完整引用。将第一条的 Image 与第二条的 Id 比较；RepoDigests 是另一类标识，不能直接拿来与本地镜像 ID 比相等。
例如，更新记录中的标签已经改好，而运行容器的 ID 仍与目标镜像不同，就应继续检查重建是否执行、是否查错容器或宿主机。镜像列表中出现新版，只证明该主机已有镜像，不能替代这一步。多个实例须逐个确认，保留版本和比对结果即可，无需导出完整环境变量。
第五步：把版本验收与功能验收分开
官方提供 Admin > GitLab Duo 健康检查入口。完成版本核对后，再检查网关连接，并让有权限的用户在测试项目执行一次原本可用的普通 Duo 操作。
建议选无敏感内容、结果容易确认的任务，观察它能否正常完成。健康检查和业务请求成功用来验证可用性；修复版本是否已运行，仍以刚才的镜像核对为依据。无需尝试利用漏洞来证明补丁有效。
失败时按发生阶段分流：镜像获取失败先查引用和仓库访问；容器启动失败先核对新旧配置差异；已经启动但请求报认证或连接错误，再查对应设置与日志。不要同时改镜像、密钥和网络，让下一次失败更难定位。
升级失败时，恢复配置而非恢复漏洞
建议预先约定失败处理负责人和暂停范围。如果暂时无法恢复正常功能，先通过既有管理流程暂停受影响的入口，再在受支持的修复版本上排查。不要为了短期恢复服务，长期重新启用已确认脆弱的镜像，也不要用关闭认证来通过验收。
提交支持请求时提供部署方式、GitLab 与网关版本、目标镜像引用、出错阶段、脱敏错误和发生时间。若确需恢复某项旧配置，先确认它与修复版兼容，单项恢复并复验；这样既能缩小差异，也能避免整套回退重新引入漏洞。
资料来源
常见问题
升级后 Duo 能用了，就可以结束处理吗？
建议分别签收两项结果：所有目标实例的运行镜像已核对，以及普通功能请求通过。只凭某一次请求成功，无法确认其他副本也已完成替换。
可以直接照搬新安装命令吗？
不建议。先由维护人对照现有部署文件，确认容器或 release 名称、配置引用、证书和网络参数；再执行经过核对的更新命令，避免重建时丢失原设置。