这是一篇针对 GPUStack（在 GPU 集群上运行 AI 模型并配置 GPU 实例的开源管理器）中漏洞的解析：未认证的一方可以冒充管理员。本文以防御视角，说明发生什么、谁受影响以及如何应对，不涉及攻击步骤。
- CVE
- CVE-2026-102895（GitHub 公告 GHSA-gj9m-f8ph-pmhr）
- 严重度
- CVSS v3.1 9.8（Critical）。公告、CVE 记录和 NVD 的数值相同
- 类型
- 认证不当（CWE-287）。公告还列出了通过欺骗绕过认证（CWE-290）和来源验证错误（CWE-346）
- 前提条件
- 无需认证；能通过网络到达 GPUStack 即可。据公告，默认设置即受影响
- 受影响版本
- pip gpustack 2.2.0 之前
- 修复
- gpustack 2.2.0
- 日期
- 公告：2026年7月31日 / CVE 记录：2026年11月4日
- 利用情况
- 公告报告了在野利用。2026年11月9日列入 CISA KEV（期限11月12日）
放任不管的风险
据公告，未认证的一方可以更改用户、模型和 worker 设置，并创建可从任何来源地址使用的管理员 API 密钥。worker 和云服务商的凭据可被读取，与仅限管理员的功能结合，会导致 worker 主机上的代码执行。公告称已观察到在野利用。CISA 对这一 KEV 条目标注需要取证分诊。
这是什么样的漏洞
在默认设置下（force_auth_localhost 为 false），GPUStack 会把来自同一台机器（loopback）的请求当作内置管理员。这本是为了在本地使用时省去认证的麻烦。问题在于，判断「是不是同一台机器」的依据可以被外部影响。
据公告，有两条无需认证就能成为管理员的路径。第一条是同一主机上的反向代理：一旦代理转发到 GPUStack，即使是外部请求，在 GPUStack 看来也来自 loopback。这是常见的自托管布局，不需要任何请求头或凭据。第二条是请求转发头；公告称，客户端提供的值可以让请求看起来像来自 loopback。本站不描述如何利用。
修复前（2.2.0 之前）
- loopback 来源无需认证即成为管理员
- 在同一主机的反向代理之后，外部流量看起来像 loopback
- 转发头可以伪造来源
2.2.0 中的变化
- 移除了把 loopback 当作管理员的路径
- 加强了对客户端 IP 和转发头的处理
- 只接受来自已认证的可信网关的真实客户端 IP 头
影响范围
| 项目 | 内容 |
|---|---|
| 产品 | GPUStack（开源 GPU 集群管理器） |
| 受影响的软件包 | pip gpustack |
| 受影响版本 | 2.2.0 之前（公告和 CVE 记录） |
| 修复版本 | 2.2.0 |
| 现实中的危害 | 公告：已观察到针对 v2.1.1 的在野利用 |
| 可能发生的事 | 所有管理员操作（更改用户、模型、worker）、创建管理员 API 密钥、读取 worker 和云服务商凭据、worker 上的代码执行（据公告和 KEV） |
- 据公告，默认设置即受影响。
- 公告只列出了 pip 软件包 gpustack。如果您以其他方式安装（例如容器镜像），请向供应商确认版本信息。
如何确认自己是否受影响
确认 GPUStack 的版本
查看已安装的 gpustack 版本。2.2.0 之前的版本受影响。如果有生产、预发布和开发环境，请逐一检查（资产清点清单）。
确认外部能否到达
确认 GPUStack 的端口或其前面的反向代理，能否从互联网等不可信范围到达。据公告，这个缺陷可以通过同一主机的反向代理起作用，所以位于代理之后并不能说明安全。
检查 force_auth_localhost 设置
确认 force_auth_localhost 是否为 true。据公告，默认值为 false，这会使存在漏洞的路径保持开放。
今天该做什么
更新到 2.2.0（最优先）
把 gpustack 更新到 2.2.0 或更高版本。KEV 期限为2026年11月12日。
在此之前，收窄入口
公告列出的临时办法如下，它们都不能代替更新。
- 把 force_auth_localhost 设为 true，使 loopback 请求也需要认证。
- 确保反向代理或网关不会让外部流量看起来像 loopback，并在边缘剥离客户端提供的 X-GPUStack-Real-IP 头。
- 让 API 远离不可信网络，置于 VPN 或边缘认证之后。
更新后，审计管理员 API 密钥
据公告，创建出来的管理员 API 密钥此后可以从任何来源地址使用。更新不会移除它，所以请列出现有的 API 密钥，并删除创建者或创建时间您不认识的密钥。尤其要查看更新之前创建的密钥。
撤销并重新签发凭据
公告称 worker 凭据和云服务商的密钥可能被读取。请撤销并重新签发您在 GPUStack 中登记的内容：worker 连接信息、云服务商密钥、模型下载令牌等。作为本站的补充建议，即使没有发现被滥用的痕迹也请重新签发。请参阅漏洞修复实务手册和安全基础：.env 与 API 密钥。
检查设置和 worker
检查不熟悉的自定义后端、用户和模型设置。在 worker 上，检查不熟悉的进程和对外连接。由于已确认存在利用，请把任何不熟悉的配置都视为可能的入侵迹象。如果发现可疑之处，请隔离该 worker，并考虑重建。
利用情况
- 公告称，已观察到针对 v2.1.1 部署的在野利用。该利用归功于一位第三方报告者。
- CISA 于2026年11月9日把它列入 KEV（已确认存在利用的漏洞目录；版本 2026.11.09），期限为11月12日。勒索软件活动中的使用情况列为未知，取证分诊列为需要。
- NVD 记录的状态为 Analyzed。CVSS v3.1 为 9.8，与公告和 CVE 记录相同。
- 公告记载了数位独立报告这一漏洞的报告者。
本站的观点：不要因为是内部网络或在代理之后，就不做认证
这与其说是编码上的失误，不如说是设计假设有缺陷。「来自本机的请求就是我」这种想法，在前面放上反向代理的瞬间就崩溃了。同一主机上的反向代理，还是添加 HTTPS 和对外发布服务时被广泛使用的方式，所以让人觉得受到保护的部署，反而成了入口。
AI 平台的管理控制台把模型运行时、GPU 资源和云端凭据集中在一处。如果它接受未认证的请求，损害就不会止于一台机器，而会通过云端凭据向外扩散。请用认证来保护管理控制台和管理 API，而不是靠位置或来源地址。设计上信任转发头时，也会出现同类问题（XFF 伪造与可信代理）。更新之后，只有清理了已创建的 API 密钥和可能被读取的凭据，工作才算完成。
信息来源
- GPUStack — GHSA-gj9m-f8ph-pmhr: Authentication bypass via trusted loopback source（2026年7月31日发布；受影响版本、修复、临时办法、利用报告）
- CVE.org — CVE-2026-102895（2026年11月4日发布；2.2.0 之前，CVSS 9.8）
- NVD — CVE-2026-102895（状态 Analyzed）
- CISA KEV — Known Exploited Vulnerabilities Catalog（2026年11月9日列入，期限11月12日）
最后确认：2026年11月10日。
延伸阅读
- 实务：漏洞修复实务手册 / 资产清点清单
- 判断：用 CVSS、EPSS、KEV 确定优先级
- 认证：XFF 伪造与可信代理 / 认证与授权的区别
- 密钥：安全基础：.env 与 API 密钥 / 什么是 CVSS？