LiteLLM 污染套件只活 40 分鐘，3 月偷走嘅 secrets 到 8 月先睇到規模
中過 1.82.7 或 1.82.8，淨係刪套件遠遠未夠
8 月曝光嘅係規模，攻擊早喺 3 月發生
LiteLLM 呢次供應鏈攻擊發生喺 2026 年 3 月 24 日，唔係 8 月先爆。新消息係 CloudSEK 同 Hudson Rock 話，佢哋分析咗攻擊者取得嘅大批資料，入面可能有逾 2,500 間機構嘅 credentials；Hudson Rock 更聲稱資料檔有 195TB。不過兩間公司都冇公開原始數據來源，所以呢兩個數字暫時只可以當研究機構嘅說法，未有獨立核實。
報告提到 Microsoft、Amazon、Cisco、Samsung 同 Salesforce 等名稱，意思只係資料入面見到同呢啲機構有關嘅 credentials，唔代表相關公司已確認俾人攻入內部系統。真正值得開發團隊即刻處理嘅問題，係 3 月有冇裝過受污染套件，同當時嗰部機接觸過咩 secrets。
邊兩個版本中招
確認受影響嘅 PyPI 版本係 LiteLLM 1.82.7 同 1.82.8。官方話兩個版本由 3 月 24 日 10:39 UTC 起上架，約 40 分鐘後俾 PyPI 隔離；不過官方排查指引用咗較闊嘅 10:39 至 16:00 UTC 時段，所以查 CI/CD、Docker build 同 deployment log 時應該照較闊範圍查，唔好見自己避開最初 40 分鐘就當安全。
用官方 LiteLLM Proxy Docker image、LiteLLM Cloud、1.82.6 或更舊版本，或者直接由官方 GitHub source 安裝，按 LiteLLM 而家嘅調查結果都冇受今次污染影響。麻煩位係間接 dependency：就算程式冇明寫 LiteLLM，某個 agent framework、MCP server 或編排工具都可能喺 build 時拉咗佢落嚟。
點解一個 Python 套件可以偷咁多嘢
1.82.7 嘅惡意 payload 藏喺 proxy_server.py，載入 LiteLLM Proxy 時就會行；1.82.8 仲多咗 litellm_init.pth，Python 一啟動就可以自動載入；就算程式冇 import litellm，惡意程式一樣有機會執行。惡意程式會掃 environment variables、.env、SSH key、AWS／GCP／Azure credentials、Kubernetes token、數據庫密碼同 CI/CD 設定，再將資料送去冒充官方網域嘅 server。
呢個位正正解釋咗點解 AI 開發環境咁值錢。LiteLLM 本身用嚟接駁多間模型供應商，周邊通常擺住幾組 AI API key；同一部開發機或 CI runner 又可能攞到 source repository、container registry 同雲端權限。攻擊者污染一個 dependency，就有機會一次過取得成條開發鏈嘅通行證。
刪咗 LiteLLM 都未算清乾淨
先用 pip show litellm、lockfile、CI job log、Docker build log 同 artifact inventory 查有冇出現 1.82.7 或 1.82.8，再搜尋 litellm_init.pth。Endor Labs 同 Sonatype 分析仲發現持久化程式會放喺 ~/.config/sysmon/sysmon.py，配合 ~/.config/systemd/user/sysmon.service，扮成「System Telemetry Service」繼續攞新 payload；/tmp/pglog、/tmp/.pg_state 都要查，亦要睇部機有冇連過可疑地址。
處理次序好重要：先隔離主機同停用可疑 service，保留 log／樣本畀保安團隊調查，再清走 .pth、sysmon.py 同 systemd unit；高風險環境最好由可信 image 重建。 唔好喺未清乾淨嘅機產生新 key，否則後門可以再偷一次。可疑 service 可由管理員用 systemctl --user disable --now sysmon.service 停低，但正式清理前應先按公司事故處理要求保存證據。
Secrets 應該點換
有條件就同步撤銷所有舊 credentials；資源有限時，先處理權限最大、可以再開新身份嘅 cloud IAM／管理員 key 同 Kubernetes token，跟住換 SSH key、Git／CI token、套件發佈同 container registry credentials，再處理數據庫密碼、TLS key，最後換 OpenAI、Anthropic、Google 等 AI API key。每換一組都要查 3 月 24 日之後嘅登入、API、IAM 同帳單紀錄，單純改密碼唔會清走攻擊者已開嘅帳戶或 access token。
之後要鎖死直接同間接 dependency 版本，保存完整 lockfile，核對 PyPI artifact、官方 release 同 checksum，CI action 就釘到完整 commit SHA。今次受污染版本冇經 LiteLLM 官方 release 流程，PyPI 同 GitHub 對唔上其實已經係警號。自動更新慳到少少維護時間，但會令一個只上架幾十分鐘嘅壞版本直接入到公司環境，呢筆數點計都唔抵。
參考來源
- Ars Technica — Terabytes of credentials leaked in massive supply-chain attack — original report
- LiteLLM：Security Update—Suspected Supply Chain Incident — 官方事故公告，確認受影響版本、安裝時段、檢查方法、安全版本同復修建議。
- LiteLLM GitHub Security Issue #24518 — 記錄惡意版本觸發方式、被偷資料種類、套件來源差異同初步處理建議。
- Endor Labs：TeamPCP Isn't Done — 技術分析惡意 payload、Python .pth 自動執行方式同 sysmon 持久化路徑。
- Sonatype：Compromised LiteLLM PyPI Package Exposes AI Systems — 交叉核對三階段惡意程式、外洩目標、持久化機制同重建主機建議。
- Aqua Security：Trivy Supply Chain Attack Update — 交代上游 Trivy 事故點樣牽連其他供應鏈，同點解要完整撤銷 credentials。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
