跳至主要內容

13 篇文章 含有標籤「incident-report」

檢視所有標籤

事件報告:Bedrock Invoke 上 Claude Code 的提示快取失效

Mateo Wang
AI Engineer, LiteLLM
Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

**日期:**2026 年 7 月 4 日至 2026 年 7 月 10 日
受影響版本: v1.91.0v1.91.1
嚴重性: 中等(靜默成本回歸;不影響正確性)
狀態: 已在 v1.91.2 修正

注意: 如果您透過 LiteLLM 在 Amazon Bedrock 上執行 Claude Code,且使用 v1.91.0v1.91.1,請升級至 v1.91.2 或更新版本。

摘要

在 7 月 4 日到 7 月 10 日之間,執行 v1.91.0v1.91.1 的代理程式,會在透過 Amazon Bedrock 的 Invoke API 路由 Claude Code 工作階段時,靜默破壞 Anthropic 提示快取。對於回報此問題的客戶而言,暖工作階段的快取命中率從大約 90% 降到 25% 到 45%,而團隊每日支出在相同用量下上升了 2 到 3 倍。請求仍然回傳 200,且完成內容正確;唯一的症狀是快取未命中率與帳單。

原因是:PR #31364messages 中每個 role: "system" 項目移到 Invoke 路徑上的頂層 system 欄位,這會讓工具定義與系統提示之後的每個快取斷點失效。修正已於 7 月 10 日隨 v1.91.2 釋出(#32578#32831#32882),並附上在修正前程式碼上會失敗的回歸測試。

這個結果完全由我們承擔。觸發因素是 Claude 新模型與 Claude Code 使用系統訊息方式的一項文件不佳的變更,但客戶之所以使用閘道,正是因為不需要追蹤提供者的怪異行為。忠實轉譯請求(包括其快取語意)是我們的核心工作,而這次我們沒有做好。這篇文章會精確說明發生了什麼事、為什麼我們的測試與審查沒能抓到,以及我們做了哪些改變,避免這類回歸再次釋出。

安全更新:Mistral AI PyPI 供應鏈攻擊 — LiteLLM 未受影響

2026 年 5 月 11 日,來自 Aikido Security 的資安研究人員發現了一起名為 "Mini Shai-Hulud" 的協同供應鏈攻擊,該攻擊發布了超過 170 個 npm 套件與 2 個 PyPI 套件的惡意版本,其中包括 mistralai==2.4.6

LiteLLM 不受影響。 我們透過 httpx 直接經由 HTTP 呼叫 Mistral 的 API,且在程式碼庫中的任何地方都不會匯入 mistralai Python SDK。

重點摘要;

  • LiteLLM 不會安裝或匯入 mistralai 套件。 我們呼叫 Mistral 的 API 方式與呼叫其他所有提供者相同(透過 httpx)。這個遭入侵的套件在任何 LiteLLM 環境中都不會被執行。
  • 這次攻擊未使任何 LiteLLM 使用者憑證面臨風險。 惡意程式在 import mistralai 時執行。由於 LiteLLM 從未觸發該匯入,因此負載永遠不會執行。
  • LiteLLM 使用者無需採取任何行動。 如果您為了自己的應用程式程式碼,已在相同環境中另外安裝 mistralai==2.4.6,請立即遵循 Mistral AI 的指引

事件報告:Prisma DB 重連會阻塞事件迴圈並終止存活檢查

Yuneng Jiang
Senior SWE @ LiteLLM

日期: 2026 年 4 月 持續時間: 在修正推出前,客戶部署中發生多起事件 嚴重性: 高 — 在 Kubernetes 中表現為完整的 proxy 當機 狀態: 已解決

注意: 此修正自包含 PR #26225 的版本開始可用(於 2026 年 4 月 29 日合併)。

摘要

當上游 Postgres 資料庫無法連線時,LiteLLM proxy 的 Prisma 重連路徑會呼叫 await self.db.disconnect()。在 prisma-client-py 下,該呼叫會對 Rust query-engine 子程序執行一個同步subprocess.Popen.wait()。由於 wait() 不會讓出執行權,asyncio 事件迴圈會凍結,直到引擎關閉所需的時間為止——在生產環境中通常是 30–120 秒,因為引擎在對失去回應的資料庫進行 TCP close 操作時卡住。

在迴圈凍結期間,沒有任何 coroutine 會執行,包括 /health/liveliness。Kubernetes 的存活探針逾時,kubelet 便以 SIGKILL 終止該 pod。從操作人員的角度來看,proxy 彷彿已經死亡,儘管根本問題其實只是 reconnect 邏輯本應撐過去的暫時性 DB 中斷。

影響: 任何 Postgres 短暫變得無回應的客戶,都會看到 proxy pod 被終止並重新啟動,而不是在 DB 恢復後優雅降級並重新連線。此問題由 FLock 對外回報,並在內部重現。

安全更新:疑似供應鏈事件

Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

狀態: 調查進行中 最後更新: 2026 年 3 月 27 日

更新(3 月 30 日): LiteLLM 的全新安全版本現已可用(v1.83.0)。這是由我們新的 CI/CD v2 管線發佈,該管線加入了隔離環境、更強的安全閘道,以及更安全的 LiteLLM 發佈分離機制。

更新(3 月 27 日): 請查看 Townhall 更新,包括事件說明、我們已採取的措施,以及後續內容。了解更多

更新(3 月 27 日): 新增 已驗證的安全版本 區段,提供所有經審核的 PyPI 與 Docker 發佈版的 SHA-256 檢查碼。

更新(3 月 26 日): 新增 checkmarx[.]zone入侵指標

更新(3 月 25 日): 新增社群貢獻的腳本,用於掃描 GitHub Actions 與 GitLab CI 管線中是否使用了受影響版本。請參閱 如何檢查您是否受影響。感謝 @Zach Fury 提供這些腳本。

重點摘要;

  • 受影響的 PyPI 套件為 litellm==1.82.7litellm==1.82.8。這些套件於 2026 年 3 月 24 日 UTC 10:39 起上線,持續約 40 分鐘後遭 PyPI 隔離。
  • 我們相信此入侵源自於我們 CI/CD 安全掃描工作流程中使用的 Trivy 依賴項
  • 使用官方 LiteLLM Proxy Docker 映像檔的客戶未受影響。該部署路徑在 requirements.txt 中固定依賴版本,且不依賴受影響的 PyPI 套件。
  • 我們已暫停所有新的 LiteLLM 發佈,直到完成更廣泛的供應鏈審查並確認發佈路徑安全。 更新: 我們現在已透過新的 CI/CD v2 管線發佈了 LiteLLM 的全新安全版本(v1.83.0),該管線加入了隔離環境、更強的安全閘道,以及更安全的 LiteLLM 發佈分離機制。我們也已驗證程式碼庫是安全的,且未將惡意程式碼推送到 main

概覽

LiteLLM AI Gateway 正在調查一起疑似供應鏈攻擊,涉及未經授權的 PyPI 套件發佈。目前證據顯示,一名維護者的 PyPI 帳戶可能已遭入侵,並被用來散布惡意程式碼。

目前我們認為此事件可能與更廣泛的 Trivy 安全入侵 有關;據報導,遭竊的憑證被用來未經授權存取 LiteLLM 發佈管線。

此調查仍在進行中。以下細節在我們確認更多發現後可能會變更。

已確認受影響版本

以下發佈到 PyPI 的 LiteLLM 版本受到影響:

  • v1.82.7:在 LiteLLM AI Gateway proxy_server.py 中包含惡意負載
  • v1.82.8:包含 litellm_init.pth,以及在 LiteLLM AI Gateway proxy_server.py 中包含惡意負載

如果您安裝或執行了這兩個版本中的任一版本,請立即查看以下建議。

注意:這些版本已從 PyPI 移除。

發生了什麼事

初步證據顯示,攻擊者繞過官方 CI/CD 工作流程,直接將惡意套件上傳到 PyPI。

這些受影響版本似乎包含一個憑證竊取程式,設計目的為:

  • 透過掃描以下項目蒐集機密:
    • 環境變數
    • SSH 金鑰
    • 雲端提供者憑證(AWS、GCP、Azure)
    • Kubernetes 權杖
    • 資料庫密碼
  • 透過對 POSTmodels.litellm.cloud 請求加密並外洩資料,該網域不是官方 BerriAI / LiteLLM 網域

受影響對象

如果以下任何情況為真,您可能受影響:

  • 您在 2026 年 3 月 24 日 UTC 10:39 到 UTC 16:00 之間,透過 pip 安裝或升級 LiteLLM
  • 您執行 pip install litellm 時未固定版本,並收到 v1.82.7v1.82.8
  • 您在此時間窗內建置了一個包含 pip install litellm 但未固定版本的 Docker 映像檔
  • 您專案中的依賴項以傳遞方式將 LiteLLM 拉入,且未固定版本 (例如透過 AI 代理程式框架、MCP 伺服器或 LLM 協調工具)

如果以下任何情況為真,您受影響:

LiteLLM AI Gateway/Proxy 使用者: 使用官方 LiteLLM Proxy Docker 映像檔的客戶未受影響。該部署路徑在 requirements.txt 中固定依賴版本,且不依賴受影響的 PyPI 套件。

  • 您正在使用 LiteLLM Cloud
  • 您正在使用官方 LiteLLM AI Gateway Docker 映像檔:ghcr.io/berriai/litellm
  • 您使用的是 v1.82.6 或更早版本,且未在受影響期間升級
  • 您是從 GitHub 儲存庫以原始碼安裝 LiteLLM,而該儲存庫遭入侵

如何檢查您是否受影響

pip show litellm

由社群貢獻的 CI/CD 腳本(原始 gist)。執行前請先審查。

入侵指標(IoCs)

請檢查受影響系統是否有以下指標:

  • 您的 site-packages 中存在 litellm_init.pth
  • models.litellm[.]cloud 的對外流量或請求 此網域隸屬於 LiteLLM
  • checkmarx[.]zone 的對外流量或請求 此網域隸屬於 LiteLLM

受影響使用者的立即行動

如果您安裝或執行了 v1.82.7v1.82.8,請立即採取以下行動。

1. 旋轉所有機密

將受影響系統中存在的任何憑證視為已遭入侵,包括:

  • API 金鑰
  • 雲端存取金鑰
  • 資料庫密碼
  • SSH 金鑰
  • Kubernetes 權杖
  • 儲存在環境變數或組態檔中的任何機密

2. 檢查您的檔案系統

檢查您的 site-packages 目錄中是否有名為 litellm_init.pth 的檔案:

find /usr/lib/python3.13/site-packages/ -name "litellm_init.pth"

如果存在:

  • 立即移除
  • 調查主機是否有進一步入侵
  • 若您的資安團隊正在進行鑑識,請保留相關證物

3. 稽核版本歷史

檢視您的:

  • 本機環境
  • CI/CD 管線
  • Docker 建置
  • 部署記錄

確認是否在任何地方安裝了 v1.82.7v1.82.8

將 LiteLLM 固定到已知安全的版本,例如 v1.82.6 或更早版本,或在稍後公告的已驗證版本。

回應與修復

LiteLLM AI Gateway 團隊已採取以下步驟:

  • 已從 PyPI 移除遭入侵的套件
  • 已輪替維護者憑證並建立新的授權維護者
  • 已邀請 Google 的 Mandiant 安全團隊協助分析建置與發布鏈的鑑識資料

驗證 Docker 映像簽章

v1.83.0-nightly 起,所有發布到 GHCR 的 LiteLLM Docker 映像都已使用 cosign 進行簽署。每個版本都使用在 commit 0112e53 中引入的相同金鑰簽署。

使用固定的 commit hash 驗證(建議):

commit hash 在密碼學上不可變,因此這是確認您使用的是原始簽署金鑰的最強方式:

cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/0112e53046018d726492c814b3644b7d376029d0/cosign.pub \
ghcr.io/berriai/litellm:<release-tag>

使用 release 標籤驗證(方便):

本儲存庫中的標籤受到保護,並會解析為相同的金鑰。此選項較容易閱讀,但仰賴標籤保護規則:

cosign verify \
--key https://raw.githubusercontent.com/BerriAI/litellm/<release-tag>/cosign.pub \
ghcr.io/berriai/litellm:<release-tag>

請將 <release-tag> 替換為您正在部署的版本(例如 v1.83.0-stable)。

預期輸出:

The following checks were performed on each of these signatures:
- The cosign claims were validated
- The signatures were verified against the specified public key

已驗證安全的版本

我們已審查在 v1.78.0 到 v1.82.6 之間發布的每個 LiteLLM 版本,涵蓋 PyPI 與 Docker。每個構件都已透過以下方式驗證:

  1. 下載已發布的構件並計算其 SHA-256 摘要
  2. 掃描已知的入侵指標(IOC)
  3. 將構件內容與 BerriAI/litellm 儲存庫中對應的 Git commit 進行比對

下列列出的所有版本都已確認乾淨。

版本SHA-256未發現入侵指標符合 GitGit 提交狀態
1.82.6164a3ef3e19f309e乾淨38d477507dad乾淨
1.82.5e1012ab816352215乾淨1998c4f3703f乾淨
1.82.4d37c34a847e7952a乾淨cfeafbe38811乾淨
1.82.3609901f6c5a5cf8c乾淨61409275c8d8乾淨
1.82.2641ed024774fa3d5乾淨f351bbdb3683乾淨
1.82.1a9ec3fe42eccb161乾淨94b002066e3a乾淨
1.82.05496b5d4532cccdc乾淨6c6585af568e乾淨
1.81.16d6bcc13acbd26719乾淨678200ee4887乾淨
1.81.152fa253658702509c乾淨2e819656cee9乾淨
1.81.146394e61bbdef7121乾淨96bcee0b0af7乾淨
1.81.13ae4aea2a55e85993乾淨cc957a19a560乾淨
1.81.12219cf9729e5ea30c乾淨ba0d541b1982乾淨
1.81.1106a66c24742e082d乾淨231aedeeff7e乾淨
1.81.109efa1cbe61ac051f乾淨7488abece8e7乾淨
1.81.924ee273bc8a62299乾淨a09d3e9162eb乾淨
1.81.878cca92f36bc6c26乾淨4fea649f519b乾淨
1.81.758466c88c3289c6a乾淨3f6a281d0f7a乾淨
1.81.6573206ba194d49a1乾淨8da3a93e6e63乾淨
1.81.5206505c5a0c6503e乾淨2cc3778761d4乾淨
1.81.33f60fd8b72758795乾淨f30742fe6e8e乾淨

問題與支援

如果您認為您的系統可能受到影響,請立即聯絡我們:

  • 安全性: security@berri.ai
  • 支援: support@berri.ai
  • Slack: 直接聯絡 LiteLLM 團隊

如需即時更新,請追蹤 X 上的 LiteLLM (YC W23)

事件報告:Guardrail 記錄將秘密標頭暴露於 spend logs 和 traces 中

LiteLLM Team
LiteLLM Core Team

日期: 2026 年 3 月 18 日 持續時間: 不明 嚴重性:狀態: 已修復

摘要

當自訂 guardrail 傳回完整的 LiteLLM request/data dictionary 時,LiteLLM 記錄的 guardrail 回應可能包含 secret_fields.raw_headers,其中包括含有 API 金鑰或其他憑證的明文 Authorization 標頭。

這些資訊接著可能傳播到會消耗 guardrail 中繼資料的記錄與可觀測性表面,包括:

  • LiteLLM UI 中的 spend logs: 對可存取 spend-log 資料的管理員可見
  • OpenTelemetry traces: 對任何可存取相關 telemetry 後端的人可見

LLM 呼叫、proxy 路由,以及提供者執行都不會因這個 bug 而被阻擋。影響是敏感請求標頭在可觀測性與記錄路徑中被暴露。

事故報告:快取驅逐關閉了使用中的 httpx 用戶端

Ryan Crabbe
Performance Engineer, LiteLLM
Ishaan Jaffer
CTO, LiteLLM
Krrish Dholakia
CEO, LiteLLM

日期: 2026 年 2 月 27 日 持續時間: 約 6 天(2 月 21 日合併 -> 2 月 27 日修正) 嚴重性:狀態: 已解決

注意: 此修正自 LiteLLM v1.81.14.rc.2 或更高版本開始可用。

摘要

一項用於改善 Redis 連線池清理的變更引入了迴歸問題,會關閉仍被 proxy 積極使用的 httpx 用戶端LLMClientCache(一個記憶體中的 TTL 快取)將 Redis 用戶端與 httpx 用戶端都存放在相同的驅逐政策下。當快取項目過期或被驅逐時,新的清理程式碼會對被驅逐的值呼叫 aclose()/close();這對 Redis 用戶端運作正確,但會摧毀系統中其他部分仍持有參考且正在用於 LLM API 請求的 httpx 用戶端。

影響: 任何命中快取 TTL(預設 10 分鐘)或容量上限(200 筆項目)的 proxy 實例,都會在其下方被關閉 httpx 用戶端,導致對 LLM 提供者的請求因連線錯誤而失敗。

事件報告:多區域 Responses API 負載平衡中的加密內容失敗

Sameer Kankute
SWE @ LiteLLM (LLM Translation)
Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

日期: 2026 年 2 月 24 日
期間: 持續進行中(直到修正部署)
嚴重性: 高(適用於在不同 API 金鑰之間對 Responses API 進行負載平衡的使用者)
狀態: 已解決

摘要

當在具有不同 API 金鑰的部署之間對 OpenAI 的 Responses API 進行負載平衡時(例如,不同的 Azure 區域或 OpenAI 組織),包含加密內容項目(例如 rs_... reasoning items)的後續請求會失敗,錯誤如下:

{
"error": {
"message": "The encrypted content for item rs_0d09d6e56879e76500699d6feee41c8197bd268aae76141f87 could not be verified. Reason: Encrypted content organization_id did not match the target organization.",
"type": "invalid_request_error",
"code": "invalid_encrypted_content"
}
}

加密內容項目在密碼學上與建立它們的 API 金鑰所屬組織綁定。當路由器將後續請求負載平衡到使用不同 API 金鑰的部署時,解密就會失敗。

  • 含加密內容的 Responses API 請求: 路由到錯誤部署時完全失敗
  • 初始請求: 不受影響 — 只有包含加密項目的後續請求會失敗
  • 其他 API 端點: 無影響 — chat completions、embeddings 等功能正常

事件報告:成本對照表重新載入後,萬用字元封鎖新模型

Sameer Kankute
SWE @ LiteLLM (LLM Translation)
Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

日期: 2026 年 2 月 23 日
期間: 約 3 小時
嚴重性: 高(適用於具有提供者萬用字元存取規則的使用者)
狀態: 已解決

摘要

當將一個新的 Anthropic 模型(例如 claude-sonnet-4-6)加入 LiteLLM 模型成本對照表,並觸發成本對照表重新載入時,對新模型的請求會被拒絕,並顯示:

key not allowed to access model. This key can only access models=['anthropic/*']. Tried to access claude-sonnet-4-6.

重新載入正確更新了 litellm.model_cost,但從未重新執行 add_known_models(),因此 litellm.anthropic_models(供萬用字元解析器使用的記憶體內集合)仍然是舊資料。即使成本對照表已知曉該新模型,對 anthropic/* 萬用字元而言,它仍然是不可見的。

  • LLM 呼叫: 所有對新加入 Anthropic 模型的請求都被 401 封鎖。
  • 既有模型: 不受影響——只有在舊的提供者集合中缺失的模型受到影響。
  • 其他提供者: 任何提供者萬用字元(例如 openai/*gemini/*)都存在相同的錯誤類型。

事故報告:SERVER_ROOT_PATH 回歸導致 UI 路由失效

Yuneng Jiang
Senior SWE @ LiteLLM
Ishaan Jaffer
CTO, LiteLLM
Krrish Dholakia
CEO, LiteLLM

日期: 2026 年 1 月 22 日 持續時間: 約 4 天(直到修正於 2026 年 1 月 26 日合併) 嚴重性:狀態: 已修復

注意: 此修正自 LiteLLM v1.81.3.rc.6 或更高版本開始可用。

摘要

一個 PR(#19467)意外地從 proxy_server.py 中的 FastAPI 應用程式初始化移除了 root_path=server_root_path 參數。這導致代理程式在提供 UI 時忽略 SERVER_ROOT_PATH 環境變數。當 LiteLLM 部署在具有路徑前綴的反向代理之後(例如 /api/v1/llmproxy)時,使用者發現所有 UI 頁面都回傳 404 Not Found。

  • LLM API 請求: 無影響。API 路由未受影響。
  • UI 頁面: 使用 SERVER_ROOT_PATH 的部署中,所有 UI 頁面都回傳 404。
  • Swagger/OpenAPI 文件: 透過設定的根路徑存取時無法運作。

事件報告:vLLM Embeddings 因 encoding_format 參數失效

Sameer Kankute
SWE @ LiteLLM (LLM Translation)
Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

日期: 2026 年 2 月 16 日 持續時間: 約 3 小時 嚴重性: 高(針對 vLLM embeddings 使用者) 狀態: 已解決

摘要

一個原本用來修正 OpenAI SDK 行為的提交(dbcae4a)因為在 API 請求中明確傳入 encoding_format=None,導致 vLLM embeddings 失效。vLLM 會拒絕此項並顯示錯誤:"unknown variant \`, expected float or base64"`。

  • vLLM embedding 呼叫: 完全失敗 - 所有請求都被拒絕
  • 其他提供者: 無影響 - OpenAI 與其他提供者皆正常運作
  • 其他 vLLM 功能: 無影響 - 只有 embeddings 受影響

Claude Code 無效 beta 標頭事件報告

Sameer Kankute
SWE @ LiteLLM (LLM Translation)
Ishaan Jaffer
CTO, LiteLLM
Krrish Dholakia
CEO, LiteLLM

日期: 2026 年 2 月 13 日 持續時間: 約 3 小時 嚴重性:狀態: 已解決

注意: 此修正將自 LiteLLM 的 v1.81.13-nightly 或更高版本開始提供。

摘要

Claude Code 開始將不受支援的 Anthropic beta 標頭傳送給非 Anthropic 提供者(Bedrock、Azure AI、Vertex AI),造成 invalid beta flag 錯誤。LiteLLM 在未進行提供者特定驗證的情況下轉送了所有 beta 標頭。當透過 LiteLLM 將 Claude Code 請求路由至這些提供者時,使用者會遇到請求失敗。

  • 對 Anthropic 的 LLM 請求: 無影響。
  • 對 Bedrock/Azure/Vertex 的 LLM 請求: 在出現不受支援的標頭時,會以 invalid beta flag 錯誤失敗。
  • 成本追蹤與路由: 無影響。

事件報告:main 上無效的 model cost map

Ishaan Jaffer
CTO, LiteLLM

日期: 2026 年 1 月 27 日 持續時間: ~20 分鐘 嚴重程度:狀態: 已修正

摘要

model_prices_and_context_window.json 中一筆格式錯誤的 JSON 項目被合併到 main562f0a0)。這導致 LiteLLM 悄悄回退到已過時的本機 model cost map 副本。使用較舊套件版本的使用者僅對較新的模型(例如 azure/gpt-5.2)失去成本追蹤。沒有任何 LLM 請求被阻擋。

  • LLM 請求與 proxy 路由: 無影響。
  • 成本追蹤: 受影響的僅是本機備份中未包含的較新模型。較舊模型不受影響。此事件持續約 20 分鐘,直到提交被還原。