LiteLLM 1.107.0 夾帶憑證竊取程式（2026 年 10 月）：受影響的 PyPI 版本與 Docker 映像檔，以及使用者該怎麼做

公司列出以下受影響的套件。所有時間均為 2026 年 10 月 21 日。

公司表示，如果你在該時段內用 pip 安裝 LiteLLM 而未固定版本，或在該時段內由這些標籤啟動了容器，就屬於受影響。如果你的 CI 每次建置都執行 pip install litellm，或你的 Dockerfile 以 latest 標籤作為 FROM 來建置，即使沒有人做任何操作，也可能已安裝到受影響的版本。

• 如果某個環境可能受影響，請不要為了查看版本而啟動 Python 或 pip。請先隔離它，再從另一台乾淨的機器檢視部署記錄或映像檔摘要值。如果無法排除曾暴露的可能，就視為受影響，並進行下方的重建與憑證輪換（本站註記）。公司的版本檢查指令同樣會啟動 Python，因此在清理之前請勿執行
• 公司已公布要尋找的檔案名稱與映像檔摘要值。找到即可確認曾暴露，但找不到並不能證明環境是乾淨的
• 如果你已明確固定使用 1.106.2 或更早版本，或 1.107.0rc1 或 rc2，則不受影響（公司表示較早的版本不在此次入侵範圍內）
• 從私有企業版 registry 拉取的客戶未受影響（公司說明）

依公司公告所引用的通報者分析，該惡意程式以Python 每次啟動時都會自動載入的檔案形式安裝。任何 Python 行程都會再次執行它，包括從未 import litellm 的行程，以及 pip 本身。

公司給出的清理順序如下（檔案名稱與位置在其公告頁面）：

• 在不啟動 Python 的情況下，從 shell 刪除公司指名的惡意檔案（及其快取檔案），涵蓋每一個受影響的 site-packages 目錄
• 停止在背景持續執行的 Python 行程
• 之後才以固定的 litellm==1.106.2 重新安裝。公司表示從頭重建映像檔與虛擬環境會更好

如果是在容器中執行，最快的做法通常是停止由受影響映像檔建立的容器，並以固定在乾淨版本的映像檔重新建立（本站註記）。

公司在第一篇貼文中請使用者固定使用 1.106.2，或本次事件之前發布的任何明確版本。10 月 24 日（UTC），公司接著發布了 1.103.8、1.104.6、1.105.4 和 1.106.3。PyPI 上的最新版本是 1.106.3，1.107.0 仍已移除。依版本說明，這些版本從 SDK、proxy 和 Docker 映像檔所信任的每個憑證套件中移除了 eMudhra 根憑證機構。eMudhra 的問題請見Python 使用者針對 eMudhra 中繼 CA 金鑰需要做什麼。

在 Docker 中，請以版本標籤，或更好的是以摘要值（digest，由映像檔內容計算出的值）來引用映像檔，而不要使用 latest 或 main-stable 這類內容會變動的標籤。這樣標籤所指向的內容一有變動，就不會影響到你。

依版本說明，自 10 月 24 日的版本起，Docker 映像檔與 Helm chart 以新的 cosign 金鑰簽署（cosign 是簽署與驗證容器映像檔的工具），以舊金鑰驗證會失敗。如果你在 cosign verify 指令碼、CI 檢查或檢查簽章的 Kubernetes 政策（例如 Kyverno）中固定使用舊的 cosign.pub，請改用版本說明所指提交中的新金鑰。版本說明也列出了新金鑰的 SHA-256，因此在切換前，請將你下載的金鑰與之比對（本站註記）。

公司表示，如果 1.107.0 曾安裝在可對外連網的主機上，你應假設被竊資料已成功外送。公司特別點名以下項目：

• 附加在伺服器或容器上的雲端角色（例如 AWS 執行個體或任務的 IAM 角色）
• 儲存在 LiteLLM proxy 資料庫中的每一把 LLM 供應商金鑰
• proxy 主金鑰，以及你發出的所有虛擬金鑰
• 資料庫連線字串（DATABASE_URL）中的密碼
• 主機上任何執行中行程的環境裡的所有機密

在通報者的分析中，該惡意程式還被設計用來蒐集 SSH 金鑰、Git 與套件發布憑證、Kubernetes 權杖、瀏覽器中儲存的密碼，以及 AI 程式輔助工具的設定。如果你曾在開發者的筆記型電腦上執行 1.107.0，該電腦上的憑證也需要輪換。

請在各服務的管理介面核發新金鑰並撤銷舊金鑰（本站註記：先設定新金鑰，再撤銷舊金鑰，以避免服務中斷）。API 金鑰的處理方式請見.env 檔案與 API 金鑰為何有風險。

公司請你在 AWS 稽核記錄（CloudTrail）中，檢查安裝前後是否有以執行個體角色發出的身分檢查呼叫（GetCallerIdentity），再檢查該角色的憑證是否曾從你自己的基礎設施以外的地方被使用。

本站另外建議，也請檢查你的 LLM 供應商管理介面，看自 2026 年 10 月 21 日 11:39 UTC（日本時間傍晚）以來，用量或費用是否有非預期的增加。被竊的 LLM 金鑰一旦被使用，可能會反映在用量與帳單上。被竊金鑰會造成什麼後果，請見被竊的 API 金鑰如何導致帳號遭停權。

受影響的環境，是以 pip 安裝而未固定版本，或使用 latest、main-latest、main-stable 等內容會變動的標籤的環境。固定使用 1.106.2、並以摘要值引用 Docker 映像檔的環境，即使在該時段內重建，也未受影響。

第一步，請以含雜湊值的鎖定檔固定正式環境與 CI 所用的相依套件（pip install --require-hashes，或 uv 或 Poetry 的鎖定檔）。採用避開剛發布不久版本的設定（例如 uv 的 exclude-newer，會忽略在指定時間之後發布的內容），也有助於防範數小時內就被撤下的版本。做法請見以 OSV-Scanner 稽核相依套件。

proxy 資料庫中存放著你所連接的每一家供應商的金鑰。像現在這樣必須輪換時，如果不知道哪把金鑰屬於哪個環境，你只能在可能漏掉一些，或全部停用之間做選擇。

開發、測試與正式環境使用各自獨立的供應商金鑰，並在供應商端設定花費上限與警示，可以縮小輪換範圍，也有助於更早發現濫用。金鑰外洩時的處理方式請見從 AI 撰寫的程式碼外洩的 API 金鑰。

依根本原因分析，起點是 5 月被誤提交到公開儲存庫的一把主金鑰。該提交很快被覆寫，已暴露的金鑰也被判定需要撤銷，但主金鑰並未撤銷，並在大約四個半月後被使用。公司表示，這起事件有力地說明了不輪換可能已暴露的金鑰所帶來的風險。

如果你把機密推送到公開儲存庫，請先撤銷並替換金鑰，再去處理歷史記錄。輪換之後，請檢查已替換金鑰的清單，確認沒有遺漏（本站註記）。此問題請見仍然有效的外洩憑證。

依分析，第一個被取走的權杖，是為了讓代理平台能開啟 pull request 而設定在其中的。它未綁定服務帳號，也未縮減權限範圍：那是某位組織擁有者的個人 GitHub CLI 權杖。公司指出，GitHub CLI 權杖是在雙重驗證之後核發的，且不受 GitHub 在敏感操作前要求重新驗證的規定約束。

請為代理與機器人使用只限於其工作範圍的專用權杖（GitHub App 或細粒度權杖），並將擁有者權限與日常工作使用的帳號分開（本站註記）。讓 CI 機密只提供給需要它們的工作流程與環境，也能限制被竊權杖的影響範圍（本站註記）。保護 GitHub 帳號請見設定 GitHub 雙重驗證。

事後證明這並非原因，但公司的第一篇貼文曾指出，在特定情況下，AI 程式輔助工具可能把使用者的 GitHub CLI 權杖嵌入回應內容中，而在會記錄回應內容的地方，這些權杖可能出現在 LiteLLM 的記錄檔中。

對於自行執行的閘道，請檢查三件事：管理介面與 API 無法從網際網路直接連到、保留回應內容的記錄設定已經過檢視，以及若有保留，保存期限要短。保護 GitHub 帳號請見設定 GitHub 雙重驗證。