這是一篇針對 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？