LiteLLM 1.107.0 遭植入憑證竊取程式，作者核查 PyPI 並重現後門機制

今早，SafeDep 披露 LiteLLM 1.107.0——於今天（10月21日）在 PyPI 發布——遭植入後門。這並非只是「存在漏洞」。它的七個 wheel 檔無一例外，都會在 site-packages 安裝憑證竊取程式和遠端程式碼執行後門，並安排成 每當主機上的任何 Python 程序啟動時，兩者都會執行，包括從未匯入 litellm 的程序。

LiteLLM 是許多團隊用來將呼叫路由至 LLM 供應商的程式庫——這表示組織存放供應商 API 金鑰的地方，正是它的代理資料庫。竊取程式也清楚這一點：根據 SafeDep 的分析，其目標包括 SSH 金鑰、雲端憑證（~/.aws、Azure、gcloud、kubeconfig）、瀏覽器密碼及瀏覽記錄、Shell 歷史記錄、CI/CD 密碼、AI 工具設定（Claude Code、Cursor、Codex 等）、透過 /proc/<pid>/environ 取得其他程序的環境，以及 AWS 執行個體中繼資料——還有 LiteLLM_CredentialsTable 本身。收集到的資料經加密後，以 POST 方式傳送至一個仿冒網域。第二個載荷以 sitecustomize.py 的形式植入，會 fork 出一個分離式守護程序，每小時重新執行竊取程式，並從伺服器下載新程式碼至 exec()；它從 GitHub 檔案讀取該伺服器的位址。

我沒有安裝 1.107.0，你也不應該安裝——我查看時，已經沒有東西可供安裝。我改為親自核實 PyPI 目前的狀態，按照已發布的指標檢查自己的電腦，並用無害的 canary 重現其機制，因為這種機制才是可套用到下一宗事件的部分。

目前 PyPI 的情況（我今天下午的查詢）

GET pypi.org/pypi/litellm/1.107.0/json   → 404
GET pypi.org/pypi/litellm/1.106.2/json   → 200, 8 files
GET pypi.org/pypi/litellm/1.107.0rc2/json → 200, 8 files
project "latest" version                  → 1.106.2
"1.107.0" in the project's release list   → absent entirely

與 SafeDep 時間線相符的詳情（以下時間均為 UTC，日期為今天）：

1.107.0rc1  uploaded Oct 18 07:54   clean (per SafeDep)
1.107.0rc2  uploaded Oct 20 03:17   clean (per SafeDep)
1.106.2     uploaded Oct 21 10:44   7 wheels + sdist, none yanked
1.107.0     uploaded Oct 21 ~11:39  REMOVED — 404 everywhere
attacker's GitHub account (C2 pointer) deleted ~13:40

因此，惡意版本在 PyPI 上存留約兩小時，而套件登錄庫目前的狀態符合版本已完全移除、而非僅撤回的情況：該版本不只是檔案被撤下，而是已從發布索引消失；pip install litellm 現在會解析至 1.106.2。兩小時的窗口很短，也很長，視乎有多少 CI 系統沒有固定版本，並在星期三 12:00 UTC 安裝。

它是如何混入的？SafeDep 的取證分析——值得全文一讀——發現 sdist 中的 pyproject.toml 多了一行：一項 maturin data = "cook" 設定，會將名為 cook/ 的資料夾複製到 wheel 的 purelib 根目錄，即直接放進 site-packages。該資料夾既不在 sdist 中，也不在任何公開提交記錄中。wheel 帶有正確的 RECORD 雜湊值，以及與平台一致的建置指紋；這表明專案本身的（私有）發布流程使用遭攻擊者修改的原始碼進行建置，而非有人使用遭竊的 token 上載手動修改的 wheel。PyPI 溯源證明：無論是這個版本，還是相鄰的正常版本，都沒有。

用 canary 重現其機制

我能安全測試的部分，是為甚麼「在每個 Python 程序中執行」確實名副其實。Python 在直譯器啟動時，會執行位於 site-packages 的 .pth 檔案中以 import 開頭的行；如果找到 sitecustomize，也會在啟動時匯入它。我建立了一個臨時 venv，內有無害的 cook.pth/cook.py，只會將自己的 PID 附加到一個檔案中：

printf 'import cook\n' > site-packages/cook.pth
# cook.py: append "cook ran in pid <pid>" to /tmp/canary_cook_ran.txt

python -c "pass"
python -c "import sys; print('litellm' in sys.modules)"

litellm imported? False
--- canary marker file:
cook ran in pid 17899
cook ran in pid 17900

兩次執行都沒有匯入任何東西，卻都執行了植入的模組。這就是整個伎倆，而且並不罕見——.pth 執行是 Python 有文件記載的功能。竊取程式不需要匯入攔截器，不需要 sitecustomize 競態，也不需要任何執行時的巧妙手段。所有巧思都用在如何讓三個額外檔案通過真正的發布流程。

我自己的測試有一個坦白説來不太理想的細節：在這部 Ubuntu VM 上，我放在 venv 裡的 canary sitecustomize.py沒有執行，因為 /usr/lib/python3.12/sitecustomize.py 在 sys.path 中的位置較前，會遮蔽它。在沒有標準函式庫 sitecustomize 的系統上（原裝 python Docker 映像、macOS、Windows），Python 會找到 site-packages 副本。因此，後門載荷能觸及的範圍會因平台配置而異；但 .pth 載荷（竊密程式）並不受此限制。它會在任何地方無條件執行。

檢查一部機器（我在自己的機器上執行的檢查）

SafeDep 公佈了入侵指標。主機層級的檢查成本很低：

site-packages contains cook.pth / cook.py / sitecustomize.py (planted)?  NO
/tmp/.pc_once_72129118c59f5636c0bb  (stealer already uploaded)           NO
/tmp/remote_code_loader.lock        (backdoor daemon ran)                NO
PRIVCOLLECT_ACTIVE in environment                                        NO

這部 VM 從未安裝 LiteLLM，因此檢查結果正常是意料之中——公開這份檢查清單的用意，是讓任何今天可能安裝過 Python 相關軟件的機器都能在兩分鐘內完成檢查。如果你在今天約 11:39 至 13:40 UTC 期間執行了 pip install litellm，或建立了全新環境，就應將主機視為已遭入侵，而不是「大概沒事」：竊密程式的目標清單專門針對開發人員和 CI 機器上的機密資料，單靠更換 LLM 金鑰，並不足以涵蓋 SSH 金鑰、雲端憑證和瀏覽器密碼。

令人不安的普遍模式

撇開名稱，這種模式其實是：建置設定多出一行、site-packages 根目錄多出三個檔案，以及兩種早已存在多年的 Python 啟動機制。整件事完全不需要零日漏洞。能防範這種情況的措施同樣毫不起眼：檢查發布版本差異，追問「為甚麼這個 wheel 檔包含 repo 裡沒有的頂層模組」；上傳時附上來源證明；以及在安裝時審核 .pth 檔案——這種檔案的正當用途本來就有限，惡意用途的潛力卻十分巨大。

LiteLLM 會修正其建置流程。真正值得擔心的是下一個套件的建置流程。如果你的 CI 在建置時會安裝未固定版本的 Python 依賴項，今天這段兩小時的窗口就是針對你的。

來源：SafeDep，〈PyPI 上遭入侵的 LiteLLM 1.107.0 會安裝竊取憑證的程式和後門〉，2026 年 10 月 21 日（safedep.io）——載荷分析、時間線、建置取證及入侵指標均由 SafeDep 提供。PyPI 狀態、上傳時間戳記、主機指標檢查，以及 .pth/sitecustomize canary 重現測試，則是我今天下午自行進行的。我沒有下載或執行遭入侵的版本。