實際事件 發布於 AIA: 2026年7月2日

LiteLLM 控制平面正在遭攻擊：AI 閘道已是攻擊者的首要目標

Zenity 回報，攻擊者正在實際嘗試兩條針對 LiteLLM（用來集中轉接 LLM 請求的 AI 閘道）control plane（控制平面，集中管理設定、測試與路由的那一層）的利用路徑：自訂程式碼 guardrail（安全檢查規則）測試器，以及連線測試 API。這兩條路徑指向同一個結論：AI 閘道（集中轉接模型請求的服務）已經是攻擊者優先鎖定的目標，因為它握有或能碰到模型供應商金鑰、路由政策、在沙箱裡執行的自訂程式碼，以及下游 AI 應用仰賴的模型流量。

Remote Code ExecutionCredential TheftRuntime IsolationCredential GovernanceAPI Routers
9 項對應的 AIDEFEND 防禦手法
來源: What You Don't Know Can Hurt You: Why AI Security Research Needs to Move Out of the Lab and Into the Wild 
作者: Ayush RoyChowdhury & Avishai Efrat
原文發布: 2026年6月30日 下午1:41

威脅分析

  • guardrail 測試器這條路徑，會把輔助測試功能變成遠端程式碼執行（RCE，攻擊者可在遠端執行程式）。 Zenity 看到大量送往 /guardrails/test_custom_code 的 POST request，內容包含 Python 探測程式碼和 CVE-2026-40217 的 sandbox escape（沙箱逃逸，從隔離環境跑出去）惡意程式碼。由於標準 LiteLLM proxy image（代理服務映像檔）以 root 執行，一旦攻擊者逃出沙箱，就可能在 container（容器）裡以 root 權限執行程式碼。
  • 連線測試這條路徑，會把路由彈性變成金鑰外洩通道。 攻擊者對 /health/test_connection 送出 request，把攻擊者控制的 api_base（模型服務目標位址）塞進 litellm_params，再把 api_key 設成指向伺服器端環境變數的值，例如 LITELLM_MASTER_KEY。
  • 這不只是一般 web app 漏洞。 LiteLLM 是 AI 閘道；如果控制平面被打穿，攻擊者碰到的可能是模型供應商金鑰、路由決策、測試端點，以及許多下游 AI app 共用的管理功能。
  • 修補範圍同時包含廠商版本和部署架構。 團隊需要升級 LiteLLM、讓 container 不以 root 執行、限制動態程式碼執行、預設拒絕對外連線、不要讓 request 參數決定模型目的位址或路由政策，並能快速讓外洩金鑰失效。
  • 防禦對應要誠實。 LiteLLM 內部解析環境變數參照字串的行為，是特定實作缺陷。AIDEFEND 可以精準對應周邊控制，但 resolver（參數解析器）這個缺陷，仍然需要 LiteLLM 修補後的行為和 regression test（避免同一問題回來的回歸測試）來關閉。

適用的 9 項 AIDEFEND 防禦手法

AID-H-004.002
Service & API Authentication
極高
在 LiteLLM API 或 gateway，先驗證呼叫端服務、workload、應用程式或外部整合的 machine identity，再把請求送進 guardrail tester（安全規則測試器）與 connection-test（連線測試）端點。這項控制不會修掉兩個 CVE、不能授權已驗證身分，也不負責 AID-H-004.001 所管的人類管理者存取。
AID-H-025.002
Safe Interpreter Enforcement
極高
guardrail tester 是動態程式碼邊界。受限制的 interpreter（程式碼直譯器）、預設拒絕的執行閘道，以及短生命週期執行環境，可以直接降低 custom Python 能碰到檔案系統、網路或高權限 API 的機會。
AID-I-001.001
Container-Based Isolation
極高
Zenity 特別點出官方 LiteLLM Docker 映像檔有以 root 執行的問題。非 root container、移除不必要 capability（容器額外權限）、read-only filesystem（唯讀檔案系統）和 security context（容器安全設定），可以在攻擊者成功於 proxy 裡執行程式碼時，降低影響範圍。
AID-I-001.004
Sandbox Network Egress Restrictions
高
如果 guardrail 程式碼真的被攻擊者拿來執行，sandbox 預設拒絕對外連線，可以擋掉 reverse shell（反向 shell 連線）和金鑰外傳 callback（回連到攻擊者端點）。這是在漏洞利用預防失敗時，很重要的最後一道防線。
AID-I-002.002
Secure External AI Service Connectivity
高
connection-test 攻擊需要 LiteLLM 去呼叫攻擊者控制的 api_base。預設拒絕 egress（對外連線）、DNS/SNI allowlist（網域與 TLS 名稱允許清單），以及受治理的 outbound gateway（對外連線閘道），可以直接阻止攻擊者任意指定的目的位址收到 provider key 或 master key。
AID-H-033.004
Route Policy Bundle Versioning, Approval, Canary & Rollback
高
模型供應商目的位址和 route policy（路由政策）應該是經審查的安全設定產物，而不是 health check request 裡的一段字串。把目的位址移到核准過的 route bundle（路由設定包），才能讓 nested api_base 這種濫用方式不能再被當成正常執行期輸入。
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
高
把已部署的 LiteLLM 版本與兩個遭利用的控制平面 CVE 逐一核對，重建修正版，先排空 canary 節點再分階段推出，最後以 digest 層級的 fleet readback 驗證已無弱點 proxy。這項控制負責兩條攻擊路徑的完整 patch lifecycle。
AID-E-001.001
Root & Long-Lived Credential Object Eviction
高
如果 LiteLLM 的 master key，或上游 provider 的 API key，可能已經被送到攻擊者控制的端點，用手動輪替太慢。應該由警示直接觸發撤換流程：到當初簽發這些 key 的地方把它們停用、換發新的，新憑證一律走核准過的 secrets 管理流程發放，並刪掉任何攻擊者自己偷加的 key。這些 master key 和 provider API key 都是長期有效的憑證，不像 session 會自己過期，所以一定要主動撤銷。
AID-E-004
Incident Exploit-Path Closure Verification
高
修正版 LiteLLM 與補償控制部署完成後，在隔離的環境複本中獨立重新發送原始 guardrail tester 與巢狀 api_base payload，並證明事件範圍內的所有系統都無法再走通這兩條路徑。這是 closure proof，不是 upgrade owner。

身為資安防禦者，我們應該這麼做

  • 找出所有 LiteLLM proxy，記錄版本、對外暴露介面、驗證模式、管理路由、container 執行身分、master key 設定和對外連線政策。
  • 升級到不受 CVE-2026-40217 和 nested api_base 連線測試行為影響的版本。AI 閘道修補應該視為高優先順序的正式環境變更。
  • 在正式環境停用或嚴格限制自訂程式碼 guardrail 測試。如果一定要保留，就放進非 root、短生命週期、受限制的 interpreter 或 microVM（輕量虛擬機）裡執行，而且不能掛正式金鑰，對外連線也要預設拒絕。
  • 不要讓 request 決定模型供應商目的位址。核准的模型端點應該來自經審查的路由政策，而不是使用者或管理端請求內容裡任意指定的 api_base。
  • 搜尋 log 裡是否出現 /guardrails/test_custom_code、/health/test_connection、litellm_params.api_base、os.environ、LITELLM_MASTER_KEY，以及 LiteLLM 對陌生網域的對外呼叫。如果無法排除外洩，就輪替相關金鑰。

結論

LiteLLM 不只是方便串接模型的 proxy。在很多部署裡，它是模型路由、provider 憑證、政策檢查、預算控制和開發者測試功能交會的地方。也因此，gateway 已經是攻擊者的首要目標：要快速套用修補、隔離執行路徑、限制對外連線（egress），並把每個暴露的管理功能都當成 AI 控制平面來保護。