部落格 發布於 AIA: 2026年7月2日

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

Zenity 回報，攻擊者正在實際嘗試兩條針對 LiteLLM 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 的管理和測試端點，應該要求強身分的服務或管理者驗證。這本身不會修掉兩個 CVE，但能大幅縮小誰可以觸及 guardrail tester（安全規則測試器）或 connection-test（連線測試）控制平面。
AID-H-026.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-034.004
Route Policy Bundle Versioning, Approval, Canary & Rollback
高
模型供應商目的位址和 route policy（路由政策）應該是經審查的安全設定產物，而不是 health check request 裡的一段字串。把目的位址移到核准過的 route bundle（路由設定包），才能讓 nested api_base 這種濫用方式不能再被當成正常執行期輸入。
AID-D-005.002
Security Monitoring & Alerting for AI
高
偵測規則要看得懂這些路徑：/guardrails/test_custom_code、Python bytecode（位元碼）或 os.environ 請求內容、nested api_base、環境變數參照字串，以及 LiteLLM 對陌生網域發起的 outbound call（對外呼叫），都應該觸發高風險警示。
AID-E-001.002
Automated & Real-time Invalidation
高
如果 master key 或 provider key 可能已經被送到攻擊者控制的端點，手動輪替太慢。由警示觸發的即時失效流程，應該能停用外洩 key，並要求新憑證透過核准的 secret-management（機密資料管理）流程重新發放。
AID-E-004
Post-Eviction System Patching & Hardening
高
這兩條路徑最後都需要修補，也需要證明真的擋住了。升級 LiteLLM、移除以 root 執行、關閉不安全的驗證路徑、把新偵測寫成規則，並在隔離環境重放原本 guardrail 和 connection-test 的請求內容，確認擋下後才算收斂。

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

  • 找出所有 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 控制平面來保護。