LiteLLM 3月供應鏈攻擊新推算：兩個毒版本點查、API key 點換
官方 Docker image 冇中招，PyPI 用家要翻查安裝紀錄
LiteLLM 今年3月嗰次供應鏈攻擊，惡意套件只喺 PyPI 留咗大約40分鐘，但後續影響可能遠大過當時估計。原因好直接：自動 build、測試同部署唔會等人睇清楚先下載套件，而 LiteLLM 身處 AI app、模型 API 同雲端服務之間，運行環境通常擺住一堆值錢憑證。
2,500間公司係推算，唔係確認受害者
iThome 報道，CloudSEK 最新調查估計，今次連鎖式供應鏈事件可能牽涉逾2,500間機構，同約43.4萬條 CI/CD pipeline。呢個數要小心解讀：CloudSEK 自己亦講明，CloudSEK 係按 Trivy、Checkmarx KICS 同 LiteLLM 等攻擊路徑重組潛在暴露範圍；搵到機構名或者相關紀錄，只代表要再查清楚，唔足以證明惡意程式成功執行、資料已外洩或者攻擊者用過偷返嚟嘅憑證。暫時亦冇可靠資料顯示有香港機構中招。
圖片：CloudSEK
中招範圍其實幾清楚
LiteLLM 官方確認，受污染嘅 PyPI 套件只有 1.82.7 同 1.82.8。1.82.7 將惡意程式塞入 proxy_server.py，載入 litellm.proxy 時先會啟動；1.82.8 多咗 litellm_init.pth，Python 一開就有機會執行，個 app 有冇直接 import LiteLLM 都未必避得到。攻擊者直接將兩版上載去 PyPI，冇經官方發佈機制，GitHub main source 冇發現同一段惡意程式。官方 LiteLLM Proxy Docker image ghcr.io/berriai/litellm 用咗鎖定依賴版本，官方指呢條安裝路徑冇受影響；1.82.6 或之前亦已核實乾淨，之後官方再用新發佈系統推出 1.83.0。
偷到一條 key，可能繼續摸入成套系統
惡意程式會掃環境變數、.env、SSH key、AWS／GCP／Azure 憑證、Kubernetes token、資料庫密碼同 CI secret，再將資料加密送去冒認 LiteLLM 嘅網域。獨立研究亦發現佢會嘗試喺 Kubernetes 節點橫向移動同加入持續存取機制。對 AI 團隊嚟講，OpenAI、Anthropic 或其他模型供應商嘅 API key 固然要換，但 GitHub／GitLab token、container registry、套件發佈權限同雲端 service account 通常更危險，因為呢啲憑證可以掂到 source、部署環境甚至正式服務。
排查要睇歷史紀錄，唔好淨係睇而家版本
先喺所有開發機、runner、virtual environment 同 container 執行 python -m pip show litellm，再查 requirements*.txt、poetry.lock、uv.lock、Pipfile.lock、image layer 同 dependency cache，有冇出現 1.82.7 或 1.82.8。現時已升級乾淨版本，唔代表3月冇裝過；GitHub Actions、GitLab、Jenkins 同雲端 build log 都要翻查。官方建議將 2026年3月24日 10:39 至 16:00 UTC 列入調查範圍，即香港時間3月24日18:39至25日凌晨零時。另要搵 litellm_init.pth、~/.config/sysmon/，同檢查有冇連去 models.litellm[.]cloud 或 checkmarx[.]zone。
先隔離同清走後門，再喺乾淨裝置換 key
一見過毒版本，就應該當嗰部機可讀到嘅憑證已外洩。先隔離相關 runner 或開發機、保留 log 同可疑檔案，再重建環境及移除持續存取機制；跟住喺乾淨裝置撤銷舊憑證、登出現有 session，同換 OpenAI／Anthropic API key、雲端 access key、Kubernetes token、Git token、SSH key、資料庫密碼及套件發佈 token。只做 pip uninstall 唔夠，過早喺仍受控嘅主機換 key，攻擊者有機會連新 key 都再攞走。換完亦要查3月24日之後嘅登入 IP、API 用量、雲端 audit log、repo 操作同異常部署。
自動更新要加一道閘
今次最值得改嘅係依賴管理：正式環境鎖實版本同 hash，新版本先入內部 package mirror 或隔離環境觀察，確認 PyPI artifact、Git tag 同 source 對得上先放行。CI runner 盡量即用即棄，雲端權限改用 OIDC 短效 token，亦要限制對外連線同每個 job 可見嘅 secret。安全掃描工具本身都有機會成為入侵路線，所以「有 scanner」唔等於可以自動信晒新依賴；負責 Python、AI gateway 同自動部署嘅團隊，應該將今次排查納入正式事故處理。
參考來源
- iThome — LiteLLM供應鏈攻擊恐波及逾2,500家企業組織 — original report
- CloudSEK：2,500+ Companies and 434,000 CI/CD Pipelines Exposed — 新影響範圍推算來源，亦列明數字屬重建暴露資料，唔等於全部確認中招。
- LiteLLM：Security Update — Suspected Supply Chain Incident — 官方公告，確認毒版本、受影響時段、乾淨版本、Docker／GitHub 範圍同補救指引。
- FutureSearch：LiteLLM PyPI Supply Chain Attack — 最早發現事件嘅獨立技術分析，拆解自動執行、憑證收集、Kubernetes 移動同持續存取手法。
- Unit 42：TeamPCP's Multi-Stage Supply Chain Attack — 獨立資安研究，補充 Trivy、KICS 同 LiteLLM 之間嘅連鎖攻擊背景。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
