目前報導及資安研究文章指出，LiteLLM 1.107.0 是於 2026 年 10 月 21 日透過 PyPI 與部分官方容器標籤發布的惡意版本。據報可安全回退的版本為 1.106.2；對於已安裝或執行受影響套件的人而言，應採取比一般升級更嚴格的措施：隔離環境、從乾淨的基礎環境重建，並輪換可存取的憑證。

據報哪些 LiteLLM 成品遭入侵

目前報導指向 LiteLLM 1.107.0 為遭入侵的版本，影響範圍據報涵蓋 PyPI 套件與官方容器映像檔。提供的警報點名 PyPI 套件及 Docker 映像檔，包括 latest 和 main-stable；Wiz 與 Aikido 的資安分析也列出 v1.107.0 和 main-latest。

這個範圍之所以重要，是因為部分受影響使用者未必曾直接選用 1.107.0。依賴浮動映像檔標籤的團隊，可能是在日常部署流程中拉取受污染的建置版本，而非明確升級版本時受到影響。

在目前披露的影響範圍內，最關鍵的資訊如下：

現有報導對不同管道的清理時間並不一致。與 BerriAI/litellm 相關的一段 GitHub issue 內容稱，PyPI 已完成清理，但 10 月 21 日某個時間點，浮動 Docker 標籤仍受感染；Wiz 後來則稱相關標籤已被移除。這些資訊支持事件的大致輪廓，但無法據此確定單一最終清理時間。

為何據報的惡意載荷風險特別高

JFrog 表示，惡意 LiteLLM wheel 使用了 Python 啟動掛鉤，使惡意載荷可在受影響環境啟動 Python 時執行，而不必等待應用程式直接匯入 LiteLLM。根據此處提供的片段，JFrog 將該行為歸因於 Python 一般 site 初始化期間處理的 cook.pth 檔案。

若此機制確實存在，風險邊界便不只是一次有問題的函式庫呼叫。在受影響環境中啟動 Python 即可能觸發竊取憑證的邏輯，這也說明為何應對建議著重於隔離與輪換密鑰，而不只是替換一個套件版本。

提供的警報指出，面臨風險的敏感資料包括雲端憑證、AI API 金鑰及 SSH 私鑰。另有 2026 年 3 月的報導摘要了安德烈·卡帕西（Andrej Karpathy）的貼文，稱一起規模更大的 LiteLLM PyPI 攻擊曾竊取 SSH 金鑰、雲端憑證、Kubernetes 設定、Git 憑證、環境變數、CI/CD 金鑰及資料庫密碼；但該較早報導並未證實 10 月事件中 Docker 標籤的影響範圍，或確切的 1.107.0 成品清單。

受影響使用者現在應如何處理

據報建議的應對方式是停止使用 1.107.0、回退或鎖定至 1.106.2，隔離任何曾安裝或執行受影響成品的主機或容器，從乾淨環境重建，並輪換該環境可存取的憑證。Aikido 與 JFrog 均將重點放在惡意套件或映像檔是否曾被安裝或執行，而非其現在是否仍可取得。

這項區別十分重要。就地升級或許能在後續移除有問題的版本，但無法解答受污染的 wheel 或映像檔運作期間，密鑰是否已經外洩。

對營運人員而言，採取行動的判定範圍應從寬：任何曾安裝 litellm==1.107.0、拉取據報受影響的浮動標籤，或在暴露環境中啟動 Python 的人，都應將該主機或容器視為可能已遭入侵。現有報導支持從乾淨映像檔或環境重建，並輪換該執行環境可存取的雲端、API、SSH、資料庫或類似憑證。