3月25日凌晨，LiteLLM維護(hù)者Krrish Dholakia的手機(jī)響了。PyPI（Python包索引）團(tuán)隊(duì)發(fā)來(lái)緊急通知：你們項(xiàng)目被劫持了，兩個(gè)惡意版本正在瘋狂傳播。

此時(shí)距離1.82.7和1.82.8版本上線還不到12小時(shí)。這兩個(gè)看似正常的更新包，已經(jīng)以每天340萬(wàn)次的下載速度沖向全球開(kāi)發(fā)者的機(jī)器——包括那些正在運(yùn)行AI大模型服務(wù)的生產(chǎn)環(huán)境。

一張圖看懂攻擊鏈：從"正常更新"到"全盤(pán)淪陷"

攻擊者TeamPCP的作案手法，像極了那些在裝修隊(duì)里安插內(nèi)鬼的盜竊團(tuán)伙。

第一步，他們拿到了LiteLLM項(xiàng)目的發(fā)布權(quán)限。具體怎么拿到的，目前還沒(méi)公開(kāi)披露，但結(jié)果是一樣的：兩個(gè)惡意版本被推送到了官方倉(cāng)庫(kù)。

第二步，惡意代碼被塞進(jìn)litellm/proxy/proxy_server.py，用base64編碼偽裝成正常文件。開(kāi)發(fā)者只要執(zhí)行import litellm，這段代碼就會(huì)自動(dòng)解碼運(yùn)行——不需要任何額外操作。

第三步，1.82.8版本更進(jìn)一步，往Python環(huán)境里扔了顆"定時(shí)炸彈"：一個(gè)名為litellm_init.pth的文件。這個(gè)后綴的文件有個(gè)特性——Python解釋器啟動(dòng)時(shí)會(huì)自動(dòng)執(zhí)行其中的代碼。這意味著即使開(kāi)發(fā)者后來(lái)卸載了LiteLLM，或者根本沒(méi)用這個(gè)功能，惡意代碼依然會(huì)在每次啟動(dòng)Python時(shí)蘇醒。

Endor Labs的研究員打了個(gè)比方：這就像有人在你家水管的入戶總閥上裝了竊聽(tīng)器，不是某個(gè)水龍頭的問(wèn)題，是你整個(gè)房子的用水都在被監(jiān)聽(tīng)。

偷什么？TeamPCP的"購(gòu)物清單"有多長(zhǎng)

一旦激活，payload會(huì)展開(kāi)三階段攻擊。第一階段是"掃蕩"：SSH密鑰、云服務(wù)商的訪問(wèn)令牌、Kubernetes集群的secrets、加密貨幣錢(qián)包、.env環(huán)境文件——全部打包。

第二階段是"橫向移動(dòng)"：在Kubernetes集群的每個(gè)節(jié)點(diǎn)上部署特權(quán)pod，相當(dāng)于在數(shù)據(jù)中心的每臺(tái)機(jī)器上都開(kāi)了后門(mén)。

第三階段是"持久化"：安裝systemd級(jí)別的后門(mén)，定期回連攻擊者服務(wù)器下載新指令。

據(jù)BleepingComputer從消息人士處獲得的信息，數(shù)據(jù)外泄量約為50萬(wàn)條——不過(guò)其中包含大量重復(fù)記錄。VX-Underground也報(bào)告了相近的"感染設(shè)備"數(shù)字。但BleepingComputer明確表示，這些數(shù)字尚未得到獨(dú)立核實(shí)。

有趣的是，TeamPCP這個(gè)組織此前還干過(guò)另一票大的：Aqua Security的Trivy漏洞掃描器。那次供應(yīng)鏈攻擊引發(fā)了連鎖反應(yīng)——Aqua的Docker鏡像、Checkmarx的KICS項(xiàng)目相繼淪陷。這次的LiteLLM攻擊，手法與Trivy事件中的憑證竊取邏輯"幾乎完全相同"。

為什么偏偏是LiteLLM？

LiteLLM的定位很特殊：它是一個(gè)"大模型路由器"，讓開(kāi)發(fā)者用同一套API對(duì)接OpenAI、Anthropic、Azure、本地模型等十幾家服務(wù)商。對(duì)企業(yè)來(lái)說(shuō)，這省去了大量適配成本；對(duì)攻擊者來(lái)說(shuō)，這意味著一旦攻破，就能同時(shí)拿到多家云平臺(tái)的訪問(wèn)憑證。

過(guò)去30天，LiteLLM的下載量超過(guò)9500萬(wàn)次?？紤]到Python包管理的特性——很多是CI/CD環(huán)境的自動(dòng)拉取——實(shí)際受影響的生產(chǎn)系統(tǒng)可能遠(yuǎn)超想象。

更麻煩的是排查難度。很多開(kāi)發(fā)者習(xí)慣在requirements.txt里寫(xiě)litellm>=1.80.0這種寬松版本約束，CI流水線會(huì)自動(dòng)拉取最新版。如果1.82.7或1.82.8恰好落在范圍內(nèi)，惡意代碼就會(huì)在構(gòu)建環(huán)節(jié)悄無(wú)聲息地進(jìn)入鏡像。

PyPI團(tuán)隊(duì)在發(fā)現(xiàn)后迅速下架了這兩個(gè)版本，但"下載過(guò)"和"運(yùn)行過(guò)"是兩回事。那些已經(jīng)構(gòu)建的Docker鏡像、已經(jīng)部署的Kubernetes pod、已經(jīng)啟動(dòng)的Python進(jìn)程，不會(huì)因?yàn)镻yPI上的刪除而自動(dòng)凈化。

現(xiàn)在該做什么：一張檢查清單

如果你或你的團(tuán)隊(duì)用過(guò)LiteLLM，按這個(gè)順序排查：

1. 檢查版本歷史

運(yùn)行pip show litellm或查看requirements.txt的鎖定文件。如果出現(xiàn)過(guò)1.82.7或1.82.8，進(jìn)入下一步。

2. 檢查Python環(huán)境殘留

搜索litellm_init.pth文件。路徑通常在site-packages目錄下。如果存在，說(shuō)明持久化機(jī)制已被激活，需要手動(dòng)刪除并重啟相關(guān)服務(wù)。

3. 輪換所有憑證

包括SSH密鑰、云服務(wù)訪問(wèn)密鑰、Kubernetes service account令牌、數(shù)據(jù)庫(kù)連接字符串。不要假設(shè)"應(yīng)該沒(méi)泄露"——攻擊者的外泄數(shù)據(jù)已經(jīng)加密傳輸，你無(wú)從得知自己的是否在列。

4. 審查Kubernetes集群

檢查是否有陌生特權(quán)pod運(yùn)行，特別是那些掛載了主機(jī)根目錄或擁有cluster-admin權(quán)限的。

Krrish Dholakia在事件平息后發(fā)了條推文："供應(yīng)鏈安全不是某個(gè)維護(hù)者的責(zé)任，是整個(gè)社區(qū)的免疫系統(tǒng)。"他附上了LiteLLM團(tuán)隊(duì)正在推進(jìn)的改進(jìn)方案：更嚴(yán)格的發(fā)布權(quán)限分離、簽名驗(yàn)證機(jī)制、以及針對(duì)PyPI劫持的應(yīng)急響應(yīng)預(yù)案。

但評(píng)論區(qū)最高贊的回復(fù)來(lái)自一個(gè)DevOps工程師："我們凌晨4點(diǎn)被叫起來(lái)滾回1.81.x，現(xiàn)在所有密鑰都換了一遍。下次能不能別在周二發(fā)版？"