跳至主要內容

14 篇文章 含有標籤「security」

檢視所有標籤

6 月 Townhall 更新:94 個 Bug 修正、OCR + Realtime 已採用 Rust,以及零回歸承諾

Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

感謝所有參加我們 6 月 town hall 的人。

三個數字概括了這個月:24 個安全性修正94 個 bug 修正,以及78 個功能提交。以下各節將逐一拆解,並說明我們對零已回報回歸的公開承諾,以及 LiteLLM gateway 逐步遷移到 Rust 的進程。

已在 1.84.0+ 修正 - 版本更新:透過 Host Header Injection 的認證繞過(GHSA-4xpc-pv4p-pm3w)

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

針對 LiteLLM proxy 這個 Host-header 認證繞過的更新已於 v1.84.0 發布,後續的路徑處理強化則已完成,並在 v1.84.3v1.85.2v1.86.2v1.83.10-stable.patch.3 中回補到所有維護中的發行線。繞過的潛在風險僅限於同時具備下列三項特定條件的部署。此繞過由 Le The Thang(KCSC)與 Kim Ngoc Chung(One Mount Group)回報。

在 proxy listener 可透過任意 Host 標頭存取時,這些條件可能允許未經驗證的存取進入受保護的管理路由。

沒有任何 LiteLLM Cloud 客戶受到影響。此次更新已在本公告發表前,部署到所有 LiteLLM Cloud 環境中——並回補到使用中的發行線。

  • 已在以下版本修正:v1.84.0
  • 建議:使用最新版本;後續的路徑處理強化已回補至 v1.84.3v1.85.2v1.86.2
  • 採取行動:升級至 v1.84.0 或更新版本。無需變更設定。

關於此公告的更多資訊請見這裡:https://github.com/BerriAI/litellm/security/advisories/GHSA-4xpc-pv4p-pm3w. CVE:https://www.cve.org/CVERecord?id=CVE-2026-48710.

安全更新: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 的指引

LiteLLM Proxy 的安全更新:CVE-2026-42208

Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

我們最近針對 LiteLLM Proxy 發布了一則安全公告。

我們透過 bug bounty program 收到一份關於 LiteLLM Proxy 的 API key 驗證路徑中存在 SQL injection 漏洞的回報,該漏洞追蹤編號為 CVE-2026-42208

此問題已由我們的團隊審查、在穩定版本中修正,並以 GitHub Security Advisory 的形式發布。

  • 受影響版本: v1.81.16v1.83.6
  • 已修正版本: v1.83.7 及之後版本
  • 建議版本: v1.83.10-stable

穩定版本:https://github.com/BerriAI/litellm/releases/tag/v1.83.10-stable

公告:https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc

安全更新:CVE-2026-30623 — 透過 Anthropic 的 MCP SDK 進行命令注入

Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

2026 年 4 月 15 日,OX Security 發布了一則公告,說明 Anthropic 的 MCP SDK 的 stdio 傳輸中的命令注入StdioServerParameters 會執行它拿到的任何 command)。LiteLLM 自 v1.83.6-nightly 起已修復此問題。

此修補已在 commit 7b7f304(PR #25343)中完成,且自 v1.83.6-nightly 起的每個版本都已包含。v1.83.7-stable 也包含此修補。

重點摘要;

  • 未經驗證的使用者無法利用此問題。 受影響的端點(MCP server 建立與 /mcp-rest/test/* 預覽端點)都位於 LiteLLM 的驗證之後。攻擊者必須先具備有效的 LiteLLM API 金鑰——而且在套用修補後,還需要 PROXY_ADMIN 角色——才能 पहुँच पहुँच到這段程式路徑。
  • 此修補自 v1.83.6-nightly 起已上線。 含有修補的第一個 stable 版本是 v1.83.7-stable。完整的已修補版本清單請見下方
  • 如果您發現其他漏洞,請告訴我們。 我們有漏洞賞金計畫,並會針對 P0(供應鏈)與 P1(未驗證的 proxy 存取)問題發放獎金。請參閱我們先前的安全更新以查看目前的獎金表。

安全更新:漏洞揭露與持續強化

Krrish Dholakia
CEO, LiteLLM
Ishaan Jaffer
CTO, LiteLLM

在 3 月的 供應鏈事件 之後,我們請 Veria Labs 針對 LiteLLM proxy 進行稽核,並修正了來自獨立研究人員的多項漏洞回報。以下所有問題都已在 v1.83.0 中修正。如果您受到影響,特別是如果您已啟用 JWT 驗證,我們建議升級。

我們也已推出 漏洞賞金計畫,而 Veria Labs 也持續對 proxy 進行稽核。更多修正將在後續版本中推出。

這兩個高嚴重性問題(CVE-2026-35029GHSA-69x8-hrgq-fjj8都要求攻擊者已經持有 proxy 的有效 API 金鑰。未經驗證的使用者無法利用這些問題。

這個關鍵嚴重性問題(CVE-2026-35030)是驗證繞過,但只有在明確啟用 enable_jwt_auth 的部署中才會受影響,而該功能預設為關閉。預設的 LiteLLM 設定不受影響,且沒有 LiteLLM Cloud 客戶啟用此功能。

宣佈 LiteLLM 的 CI/CD v2

Krrish Dholakia
CEO, LiteLLM

CI/CD v2 現已於 LiteLLM 上線。


承接我們的 安全事件 路線圖,CI/CD v2 為 LiteLLM 導入了隔離環境、更強的安全防護欄,以及更安全的發佈分離。

有哪些變更

  • 安全掃描與單元測試在隔離環境中執行。
  • 驗證與發佈分離到不同的儲存庫,讓攻擊者更難取得發佈憑證。
  • PyPI 發佈採用 Trusted Publishing——這表示發佈時不會使用長效憑證。
  • 不可變更的 Docker 發佈標籤——這表示發佈後無法竄改 Docker 發佈標籤 了解更多。注意:也規劃了 GHCR docker 發佈的相關工作。
  • 使用 Cosign 進行 Docker 映像簽章——所有發佈映像都已簽署,因此使用者可以自行驗證它們確實來自我們。

驗證 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 tag 驗證(方便):

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

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

接下來是什麼

接下來,我們計劃:

  • 採用 OpenSSF(這是一組專案應遵守的安全標準,用來展現強健的安全態勢——了解更多

    • 我們已將 Scorecard 和 Allstar 加入我們的 Github
  • 將 SLSA Build Provenance 加入我們的 CI/CD pipeline——這表示我們允許使用者獨立驗證發佈確實來自我們,並防止發佈在公開後遭到靜默修改。

我們希望這將意味著您可以放心,您所使用的發佈是安全且確實來自我們的。

原則

新的 CI/CD pipeline 反映了以下列出的原則,並設計得更安全且更可靠:

  • 限制 每個套件可以存取的內容
  • 減少 敏感環境變數的數量
  • 避免 已遭入侵的套件
  • 防止 發佈遭竄改

如何協助:

協助我們規劃 4 月的穩定性衝刺——https://github.com/BerriAI/litellm/issues/24825

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

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 而被阻擋。影響是敏感請求標頭在可觀測性與記錄路徑中被暴露。