2026 年 10 月 25 日，GitHub Advisory Database 收錄編號 CVE-2026-116180 的漏洞公告，指出開源推理框架 vLLM 由 0.8.5 起、0.31.0 之前的版本存在跨租戶阻斷服務（denial of service）缺陷，CVSS v4 基礎評分為 8.3，屬高嚴重程度[1]。公告說明，任何與他人共用同一個推理引擎的使用者，只要針對由 KV connector 快取的前綴送出附帶 prompt_logprobs 的請求，即可令 EngineCore 崩潰，並同時中斷其他租戶正在處理的請求。官方已在 0.31.0 修補。
漏洞的技術成因
根據公告與 vLLM 專案本身的安全通報[2]，問題出在 vllm/v1/outputs.py 之中的 LogprobsTensors.empty_cpu()。該函式會配置一個未經初始化的 int32 tensor，而 V1 model runner 在部分情況下，會把由 KV connector 回報為「已計算」的 prompt 位置留空未寫入。當客戶端對這類由 connector 快取的前綴要求 prompt_logprobs，或以 echo 配合 logprobs 取回完整序列時，tokenizer 在解碼階段便會讀到未初始化的數值，最終拋出 OverflowError。
由於例外發生於推理引擎的核心執行路徑，錯誤並非單獨回傳給某一個請求，而是直接使 EngineCore 崩潰。同一個引擎上正在排隊與執行中的所有請求會一併失敗。此缺陷在弱點分類上屬於 CWE-908「使用未初始化資源」，屬可用性層面的問題：機密性與完整性均無影響，但可用性評為高；攻擊者亦只需具備低權限帳戶、經網路即可觸發，無須使用者互動。
影響範圍
受影響版本為 0.8.5 及以上、0.31.0 之前的所有版本；已修補版本為 0.31.0。該 CVE 由美國國家漏洞資料庫發布[3]，GitHub Advisory Database 於同日收錄，並連到 vLLM 專案自身的安全通報 GHSA-rhcx-5729-88vg，以及第三方漏洞資料庫的同名條目。
實際風險高低取決於部署形態。若推理服務只供單一內部應用使用的話，呼叫方本身已在信任邊界之內，風險相對有限；但若平台以共用引擎方式服務多個客戶，例如按 API key 區分租戶、或把同一批 GPU 分時租予不同使用者，則任何一個租戶都可以令整個引擎連同其他租戶一併下線，屬典型的跨租戶影響。公告亦指出，同一日資料庫尚有其他 vLLM 的同級高危公告，維運人員宜一併檢查，而非只處理單一條目。
自建推理服務的處理建議
最直接的做法是升級至 0.31.0 或更新版本，並在升級後以相同的前綴快取情境重新測試，確認請求不再觸發例外。若短期內無法升級，可考慮在閘道層攔截或改寫帶有 prompt_logprobs、以及 echo 配合 logprobs 的請求，並收緊租戶之間的引擎隔離，例如讓不同租戶使用獨立 instance，而非共用同一個 engine。
對於以 vLLM 支撐對外服務的團隊，此類公告亦值得納入例行弱點掃描流程，避免同批公告被逐條漏處理。需要留意的是，公告把嚴重程度定為高，但其影響集中於可用性，並不涉及資料外洩或內容篡改；因此優先次序可按實際暴露面調整，惟推理服務中斷往往直接等於業務中斷，對外服務仍應優先修補。自行編譯或 fork vLLM 的團隊，亦要確認修補已進入自己的分支，而非只更新上游版本號。
參考資料
[1] CVE-2026-116180 · GitHub Advisory Database（2026-10-25）
[2] GHSA-rhcx-5729-88vg · vLLM Security Advisory
[3] CVE-2026-116180 · National Vulnerability Database（2026-10-25）