觀點 · 資訊分享

GPU 叢集管理工具 GPUStack 漏洞遭實際利用：躲在反向代理後面，外人就變成管理員

開源 GPU 叢集管理工具 GPUStack 2.2.0 以前的版本，會把「來自本機」的請求直接當成管理員；放在同機反向代理後面時，所有外部請求都像來自本機。CISA 11 月 9 日將它列入已遭利用漏洞清單，要求 3 天內處理。

一句話看懂：GPUStack 舊版把「來自本機」的請求當成管理員，放在反向代理後面時等於對所有人敞開大門；這個漏洞已被實際利用，CISA 11 月 9 日列入必修清單。

GPUStack 認證繞過遭實際利用資訊圖卡：把「來自本機」當成管理員的設計，碰上同機反向代理就全面失守

先用白話講：「信任本機」為什麼危險？

想像一棟大樓的管理室規定：「從大樓內線打來的電話，一律當成主委本人。」聽起來合理，外人打不了內線嘛。

問題是，大樓門口的總機會把所有外線電話轉接成內線。結果路人打電話進來，管理室看到的都是「內線來電」，於是照單全收。

反向代理（例如 Nginx）就是這個總機：它擋在服務前面幫忙轉送請求。如果代理和服務在同一台機器上，服務看到的連線來源永遠是 127.0.0.1（本機）。

GPUStack 是開源的 GPU 叢集管理工具，用來集中管理多台顯示卡機器、部署 AI 模型
2.2.0 以前的版本，在預設設定（force_auth_localhost 為 false）下，會把來自本機的請求直接當成內建管理員
兩種情況會被誤判成本機：同機反向代理轉送的請求，以及帶有偽造 X-GPUStack-Real-IP 標頭的請求
結果是不需任何帳密就能拿到管理權：改使用者與模型、建立長期有效的管理員存取憑證、讀取工作節點與雲端供應商的機密設定，還能透過自訂推論後端在工作節點上執行程式
專案早在 7 月 31 日就發布安全公告，並記錄有一台 2.1.1 部署已遭實際利用；修補版 2.2.0 在 6 月 18 日釋出
NVD 在 11 月 4 日公開 CVE-2026-102895，CVSS 9.8；11 月 9 日 CISA 列入已遭利用漏洞清單（KEV），要求聯邦機關在 11 月 12 日前處理

狀況	建議做法
可以升級	直接升到 2.2.0 以上
暫時不能升級	把 `force_auth_localhost` 設為 true，本機請求也要驗證
前面有反向代理	在代理層移除使用者送來的 `X-GPUStack-Real-IP` 標頭
服務對外開放	改走 VPN 或在入口加一層驗證，不要直接曝露在網路上

升級後別只看版本號。漏洞能建立長期有效的存取憑證，攻擊者可能早就留了後門，建議逐一檢查管理員帳號、存取憑證與自訂推論後端，並更換曾存放在系統裡的雲端憑證。

這個漏洞的模式在自架服務很常見：「本機來的就放行」在開發時很方便，一旦前面加了 Nginx 或 NAS 內建的反向代理，假設就整個崩掉。自架 AI 服務的人特別容易踩到，因為大家習慣把 Web 介面接在反向代理後面，再開個網址從外面連。

我的原則是：任何服務都不要用 IP 來判斷身分，自己寫的程式也一樣。要讀真實 IP 的標頭，只能信任自己的代理送來的，並在代理層先把使用者送進來的同名標頭清掉。另外，GPU 機器通常也放著模型和雲端憑證，被拿下的代價比一般網站更高。

GPUStack 是什麼？

一套開源的 GPU 叢集管理工具，可以把多台有顯示卡的機器集中管理，用來部署和提供 AI 模型推論服務。

我沒用反向代理，也會中嗎？

仍有風險。安全公告寫明，偽造一個特定的 IP 標頭也能讓請求被當成來自本機；只要版本低於 2.2.0、服務能被外部連到，就應該處理。

已經升級了，還要做什麼？

因為漏洞允許建立長期有效的管理員存取憑證、讀取雲端供應商的機密設定，升級後建議檢查是否有不認得的使用者、模型後端與存取憑證，並更換曾存在系統裡的雲端憑證。

這個漏洞是 11 月才發現的嗎？

不是。GPUStack 專案在 7 月 31 日就發布了安全公告，修補版 2.2.0 更早在 6 月 18 日釋出；11 月 4 日 NVD 才公開 CVE 頁面，11 月 9 日被 CISA 列入已遭利用清單。

作者

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。