觀點 · 資訊分享
LiteLLM 發布管線被入侵：v1.107.0 帶著偷憑證程式上了 PyPI 與 Docker，約 2 小時後下架
常用的 AI 閘道套件 LiteLLM 在 10 月 21 日被攻擊者透過發布流程推出惡意的 v1.107.0。這個版本會竊取憑證，在 PyPI 約 2 小時、Docker 約 2.5 小時後被撤下，沒鎖版本的人要檢查並換金鑰。
- 發布
- 2026-10-22
- 篇幅
- 約 5 分鐘 · 2,305 字
- 結構
- 8 節 + 4 題常見問題
- 標籤
一句話看懂：AI 閘道套件 LiteLLM 的 v1.107.0 在 10 月 21 日被塞進偷憑證的程式，約 2 小時後下架；沒鎖版本的人要檢查、清理並換掉金鑰。
先用白話講：供應鏈攻擊是什麼？
想像你每天向同一家便當店訂餐。某天有人闖進便當店的「出貨流程」，在幾個小時內送出去的便當裡下了藥；店裡的食譜（原始程式碼）本身卻沒被改過。你沒做錯任何事，只是照常訂餐。
這就是供應鏈攻擊：不攻擊你，而是攻擊你信任的軟體供應來源。LiteLLM 是很多團隊使用的 Python 套件與 AI 閘道，用同一種寫法呼叫上百種大型語言模型，因此常常集中放著各家 AI 服務的金鑰。
發生什麼事
LiteLLM 官方在 10 月 21 日公布：他們的發布流程被入侵，攻擊者把惡意的 v1.107.0 推到 PyPI（Python 套件庫）與 Docker 映像檔。
| 管道 | 惡意版本可取得的時間（UTC） | 台灣時間（自行換算） |
|---|---|---|
| PyPI | 11:39 到 13:23 | 約 19:39 到 21:23 |
| Docker Hub | 11:46 到 14:20 | 約 19:46 到 22:20 |
| GHCR | 11:46 起，13:51 前已無法取得 | 約 19:46 起 |
- PyPI 上受影響的是 v1.107.0 的 7 個安裝檔（wheel）
- Docker 的
v1.107.0、latest、main-latest、main-stable四個標籤都指向過惡意映像檔 - GitHub 上官方的 v1.107.0 原始碼標籤沒有惡意檔案；惡意版本是從攻擊者控制的仿冒倉庫（名稱只差一個連字號）建出來的
- 官方說 1.107.0 之前的版本都安全；使用官方私有套件庫的企業版客戶也不受影響
它會偷什麼？
這份分析最早由資安公司 Upwind 的研究團隊貼在 LiteLLM 的 GitHub Issue 裡，官方事件報告也採用其中的處理建議。報告說明他們只做了靜態分析、沒有實際執行惡意程式：
- 惡意檔案
cook.pth、cook.py、sitecustomize.py會被放進 Python 的套件目錄；.pth檔的特性是 Python 每次啟動都會自動載入 - 蒐集的內容包含 SSH 金鑰、瀏覽器存的密碼、AWS 與其他雲端憑證、
.env檔、AI 工具的設定、所有可讀取行程的環境變數 - 如果設了
DATABASE_URL，還會去撈 LiteLLM 資料庫裡存的各家 AI 供應商金鑰 - 資料加密後送到仿冒的網域
litellm.dev，不是專案自己的litellm.ai
怎麼檢查、怎麼處理
檢查：用 pip show litellm 看版本；檢查容器是否跑過受影響的映像檔；搜尋檔案系統有沒有 litellm-1.107.0.dist-info、cook.pth、sitecustomize.py。找到就確定中標，找不到不代表安全。
處理（官方建議）：
- 不要先跑
pip install：受影響環境只要啟動 Python，惡意檔案就會再執行一次，包含執行 pip 本身 - 在命令列刪掉惡意檔案，結束背景的 Python 程式，再重新安裝並鎖定
litellm==1.106.2；更好的做法是整個環境與映像檔重建 - 只要 1.107.0 曾裝在可以連外網的主機，就假設資料已外洩，並更換主機碰得到的所有金鑰：IAM 角色、LiteLLM 資料庫裡的各家 AI 金鑰、主金鑰與虛擬金鑰、
DATABASE_URL的密碼，以及環境變數裡的任何機密 - 到 CloudTrail 查看有沒有可疑的
GetCallerIdentity呼叫
他們是怎麼被攻破的？
官方 10 月 21 日的初步說法是：攻擊者取得了三位工程師的 GitHub CLI 憑證，其中一位屬於組織擁有者，因此能關掉分支保護並強制推送，最後讓發布流程指向仿冒倉庫。官方在文中提到，三月出事後他們已經強化過 CI 流程，這次是攻擊者繞過了好幾道獨立的防線。
要注意，官方特別註明這篇文章寫於調查期間，部分推測後來被發現不準確或不完整，並另外發了定稿紀錄。所以這一段只當成當時的初步說法，細節以官方後續更新為準。
我的看法
LiteLLM 這類 AI 閘道很容易變成「所有金鑰集中保管的地方」，一旦中標，損失的就不只一把金鑰。我會從這次事件記下三件事：
- 版本一定要鎖：
requirements.txt寫死版本，Docker 用指定版本或摘要，正式環境不要用latest - 更新晚一步：新版本出來不必當天就追，給社群幾天檢查的時間，這次惡意版本只活了約 2 小時，晚一點更新的人就躲過了
- 金鑰分開放、設上限：各環境用不同金鑰，並在供應商那邊設好用量上限，外洩時損失才有限
自架 AI 閘道或常用 pip 更新的人，這幾天最好花十分鐘看一下自己機器上裝的版本。
名詞小辭典
- 供應鏈攻擊：攻擊軟體的提供流程（套件庫、建置、更新管道），讓使用者自己把惡意程式裝進去。
- PyPI：Python 的官方套件庫，
pip install預設從這裡下載。 - 鎖定版本（pin）：明確指定要用哪一版，而不是「永遠抓最新」，避免被悄悄換成別的內容。
- .pth 檔：Python 啟動時會自動讀取的小檔案，裡面的程式會被執行，這次被拿來當作自動啟動的入口。