LiteLLM 於二零二六年十月二十三日發布攻擊鏈官方報告，確認十月二十一日惡意版本 litellm==1.107.0 遭寫入 PyPI 與官方容器映像，根因是五月二十七日誤把 Agent Platform 主密鑰提交至公開倉卻未撤銷；攻擊者十月十日取用該密鑰取得組織擁有者級 GitHub CLI OAuth 權杖，再劫持發布管線。惡意套件在 PyPI 上約兩小時內按 Wiz／ClickPy 約四萬九千次下載，可在每次啟動 Python 時盜取雲端與 AI 供應商憑證。來源真實性已核對 LiteLLM 事故與攻擊鏈報告，並與 Wiz、Microsoft Security 交叉核對。

LiteLLM／官方：AI 閘道 1.107.0 供應鏈遭劫持——公開主密鑰未撤銷釀組織擁有者權杖失竊；PyPI 約兩小時近五萬次下載

引言

企業把數十個大語言模型接到同一條「AI 閘道」時，閘道本身往往比任何單一模型 API 更接近生產密鑰、雲端角色與 CI 祕密。開源專案 LiteLLM 正是這類閘道的代表之一；二零二六年十月二十一日，其公開發布管線被攻陷，把帶憑證竊取與遠端程式碼載入能力的 litellm==1.107.0 推上 PyPI 與 Docker／GHCR。官方其後完成調查，把起點追溯到五個月前一枚「已刪提交、卻未撤銷」的主密鑰。本文已核對 LiteLLM 官方事故報告與攻擊鏈長文，並對照 Wiz、Microsoft Security Blog，來源真實性已驗證；焦點在AI 供應鏈憑證生命週期與發布閘口，而非個別模型能力評測。

一、核心事件：惡意 1.107.0 上架、隔離與影響面

按 LiteLLM 二零二六年十月二十一日事故報告（其後以十月二十三日攻擊鏈文為調查定本）：

• PyPI：litellm==1.107.0 全部七個 wheel 於協調世界時 11:39:51 至 13:23 上架，其後被隔離／下架；
• Docker Hub／GHCR：標籤 v1.107.0、latest、main-latest、main-stable 於約 11:46 至 14:20（GHCR 部分標籤約 13:51 起不可用）指向遭污染映像；
• 官方 GitHub 上的 v1.107.0 原始碼標籤不含惡意檔；實際產物來自攻擊者控制的外觀相近倉庫 Berri-AI/litellm（多一個連字符），經被改寫的發布工作流建置並簽名；
• 企業私有 registry／embargoed 發行未受影響；官方指可先釘選安全版本 1.106.2。

Wiz 引用 ClickPy 數據指，惡意 PyPI 版本約有 四萬九千次下載（含鏡像與自動化流量可能）。Microsoft Security 指惡意碼透過 Python 啟動機制執行：即使應用程式沒有 import litellm，只要在已安裝該版本的環境啟動 Python，就可能觸發蒐集器。

惡意產物在 site-packages 根目錄留下 cook.pth、cook.py、sitecustomize.py 等檔：前者在解譯器啟動時載入資訊竊取邏輯，後者可週期拉取並執行遠端程式碼。蒐集目標涵蓋瀏覽器憑證、AWS／GCP／Azure 憑證與實例中繼資料、CI／Kubernetes 祕密，以及 OpenAI、Anthropic、Cohere 等上游推理 API 金鑰；另有模組嘗試讀取 LiteLLM proxy 內的金鑰與模型設定。Wiz 觀察到外洩約四個半小時後，攻擊者對竊得的 AWS 實例角色憑證呼叫 sts:GetCallerIdentity 等 API，行為與 LLMjacking 探測一致。

二、機制解說：從「未撤銷主密鑰」到「合法簽名的毒包」

1. 五月曝光、十月才被用上

十月二十三日定本敘事寫明：二零二六年五月二十七日，設定檔被提交至公開倉 LiteLLM-Labs/lite-harness，當中含 LiteLLM Agent Platform（內部用於編排代理、代提 PR 的實驗服務）主密鑰。團隊很快發現並 force-push 覆蓋提交，亦標記須撤銷密鑰，但主密鑰實際未撤銷。

十月十日，攻擊者用該主密鑰呼叫 Agent Platform API，回應中帶回與組織擁有者帳戶綁定的 GitHub CLI OAuth 權杖。此類權杖屬「post-2FA」，敏感操作往往不再觸發 GitHub 的 sudo／二次驗證流程；自此攻擊者對組織內倉庫具備擁有者級存取。

2. 橫向盜取維護者權杖與 CI 祕密

持擁有者權杖後，攻擊者在內部倉建立拋棄式分支與工作流，把 CI 可用祕密 POST 至外部端點，取得另外兩名維護者的 GitHub CLI 權杖，以及其他內部系統權杖；官方指其活動重點包括上游推理 API 金鑰。十月十二日前後，更多私有倉祕密被同樣手法外洩。

3. 改寫發布源、雙權杖過閘、刪紀錄與洗歷史

十月二十一日，攻擊者先嘗試把發布器改為拉取惡意源，遭分支保護拒絕；隨即以擁有者權杖覆寫分支保護，把 BerriAI/project-releaser 指向外觀相似的 Berri-AI/litellm。適逢團隊為加快 backport 暫時放寬「須辦公室鎖定帳戶批准」的發布限制，改為兩名工程師即可觸發與批准——攻擊者用一枚權杖觸發、另一枚批准，使審計表面上像正常雙人流程。產物上架後，第三枚權杖刪除 staging／production 工作流執行紀錄，並再次覆寫保護以 revert／force-push，試圖清潔 main 可見歷史；相關 SHA 與組織審計日誌仍可追溯。

社區研究者 LidorMachluf 約在上架二十分鐘內於 GitHub Issue 指出污染；LiteLLM 於約 13:02 起應變，PyPI 於 13:23 前完成隔離，Docker 標籤至約 14:20 處理完畢，並撤銷相關權杖、鎖定公開 registry。

三、影響分析：誰中招、為何比「下錯套件」更棘手

1. 對開發者與 CI

在曝光窗口以未釘選版本執行 pip install litellm，或拉取受影響 Docker 標籤的環境，應假設已遭外洩。官方與 Microsoft 皆強調：不要在可疑環境內先開 Python／pip 做檢查，否則會再次執行啟動掛鉤；應先從檔案系統層刪除惡意檔與快取、終止相關行程，再重建虛擬環境或映像，並輪替主機可觸及的一切祕密（實例／任務 IAM、proxy 資料庫內供應商金鑰與 master／virtual key、DATABASE_URL、環境變數中的祕密等）。

2. 對企業 AI 閘道營運

LiteLLM 常部署在可觸及多雲與多模型金鑰的控制面。一旦 CI runner、開發筆電或閘道主機跑過 1.107.0，攻擊面不是「用家對話內容」，而是整條推理供應鏈的鑰匙串。企業私有 registry 未中招，反而凸顯公開 OSS 發布路徑與內部發行路徑隔離的價值。

3. 對香港與亞洲團隊

本地新創與系統整合商大量以 LiteLLM、自建 proxy 串多模型以降本；許多流水線習慣追 latest 或未鎖版。此案說明：AI 閘道的供應鏈風險等同核心支付或身分系統——主密鑰／組織權杖／發布批准策略任何一環鬆脫，合法簽名也救不了內容信任。

四、各方反應與官方建議

• LiteLLM：公開事故報告與攻擊鏈定本；撤銷所有可能外洩權杖；鎖定公開 registry；感謝 LidorMachluf、Socket、Trail of Bits 等協助；稱將另文交代流程改進，並只在有信心時再發新版。
• Wiz：量化約四萬九千次下載，描述憑證竊取與後續 AWS 角色探測／LLMjacking 跡象，並向客戶發出威脅情報通告。
• Microsoft Security：拆解 Python 啟動掛鉤、蒐集器與 Unix 載入器兩條執行路徑，提醒調查時避免在感染環境啟動解譯器，並提供 Defender 偵測與 hunting 指引。
• The Register（十月二十六日）：跟進定本調查，強調「刪除洩漏提交卻不撤銷密鑰」的風險教訓。

五、專業評價與潛在考量

可取之處

• 官方最終以可核對時間線、憑證表與 IOC 交代完整攻擊鏈，並修正早期「權杖來自內部 LiteLLM 日誌」等不完整假設，透明度高於許多開源事故。
• 社區在約二十分鐘內發現污染，大幅縮短暴露窗口；企業私有發行路徑未受波及，顯示分軌道發布的實務價值。

需要留意

• 約四萬九千次下載含鏡像與掃描器，真實落地感染數未公開；但不能用「窗口只有兩小時」低估 CI 自動升級的穿透力。
• 早期報告曾懷疑內部部署漏洞與日誌外洩 GitHub 權杖；定本改為 Agent Platform 主密鑰路徑——讀者應以十月二十三日攻擊鏈文為準。
• 「暫時放寬雙人發布」與「擁有者權杖可關分支保護」疊加後，單一密鑰生命週期失誤即可貫穿多道控制；僅靠映像簽名不足以證明建置源可信。

整體而言，這是一則針對AI 閘道供應鏈與密鑰撤銷紀律的可核對官方事故：毒包能帶合法發布外觀，但起點仍是五個月未撤銷的主密鑰。

結語

LiteLLM 確認惡意 1.107.0 經被劫持的官方發布管線進入 PyPI 與容器倉庫，根因是 Agent Platform 主密鑰公開提交後未撤銷，再連鎖導致組織擁有者與維護者 GitHub 權杖失竊；短暫窗口內仍錄得近五萬次級下載，並出現憑證被用於雲端探測的跡象。對正在把多模型閘道、代理編排與 CI 密鑰綁在同一套開源工具上的香港團隊，供應鏈防護已不能只盯應用程式碼審查，而要覆蓋密鑰輪替、發布源完整性與執行環境隔離。若需強化雲端與 AI 供應鏈的偵測、應變與架構加固，可參考 YSK Limited 的雲端遷移與網絡安全方案：https://ysk.hk/services/cloud-security

參考來源

• LiteLLM 官方攻擊鏈報告（2026-10-23，調查定本）：https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
• LiteLLM 官方事故報告（2026-10-21）：https://docs.litellm.ai/blog/security-incident-oct-21-2026
• Wiz Blog（2026-10-21）：https://www.wiz.io/blog/litellm-compromised-steals-credentials
• Microsoft Security Blog（2026-10-23）：https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/
• The Register（2026-10-26）：https://www.theregister.com/security/2026/10/26/litellm-supply-chain-attack-started-with-an-exposed-master-key/5305544