如果你最近在用OpenClaw跑Agent、裝Skill，或者即便只是正常裝了幾個常見依賴，那你可得好好注意了！

今日，資深開發(fā)者Daniel Hnyk在社交平臺X上緊急發(fā)文警告稱：LiteLLM的PyPI官方發(fā)布版本1.82.8已被注入惡意代碼，并著重強(qiáng)調(diào)“DONOTUPDATE”（請勿更新）。

隨后OpenAI聯(lián)合創(chuàng)始人、前特斯拉AI主管Andrej Karpathy也親自發(fā)帖稱：“軟件恐怖事件：litellm PyPI供應(yīng)鏈攻擊?！?/p>

不要認(rèn)為LiteLLM被投毒和OpenClaw沒有任何關(guān)系。

即使你沒有主動安裝LiteLLM，只要你用于OpenClaw的某個Skill或組件依賴了它，它就已經(jīng)在你的項目里運(yùn)行了。

這就是所謂的依賴鏈：你依賴一個工具，這個工具再依賴另一個庫，而那個庫再依賴更多東西。只要其中一環(huán)被投毒，風(fēng)險就會順著整條鏈條傳導(dǎo)下來。

而且一旦某個底層依賴庫被投毒，最麻煩的地方在于，你幾乎沒有任何體感。你不會看到報錯，也不會收到提示，一切看起來都在正常運(yùn)行，但在某一層你看不到的依賴深處，敏感信息可能已經(jīng)被悄悄帶走。

01

投毒破壞力從何而來？

在了解可能的風(fēng)險之前，我們先來說說LiteLLM是什么。

LiteLLM是大模型生態(tài)中幾乎人手必備的關(guān)鍵適配層，其地位如同AI開發(fā)界的通用翻譯官。

在GitHub上，該項目（BerriAI/litellm）已斬獲超4萬顆星，月下載量高達(dá)9700萬次，是連接開發(fā)者與上百個LLM（如OpenAI、Anthropic、GoogleVertex等）的底層樞紐。

它的核心價值在于將復(fù)雜的各家API統(tǒng)一為OpenAI標(biāo)準(zhǔn)格式，使得開發(fā)者只需寫一套代碼就能無縫切換模型。

另外，在很多企業(yè)架構(gòu)里，LiteLLM不僅僅是一個庫，更是作為“AI網(wǎng)關(guān)”管理著全公司的模型調(diào)用權(quán)限與成本追蹤。

正因為LiteLLM處于這種咽喉要道的位置，此次供應(yīng)鏈投毒事故的破壞力呈指數(shù)級放大。

攻擊者在官方倉庫發(fā)布的惡意版本（1.82.7和1.82.8）利用了Python極高權(quán)限的初始化機(jī)制，這意味著只要執(zhí)行pip install，惡意代碼就會像病毒一樣靜默潛伏。

由于LiteLLM的主要職能就是處理API密鑰，它成了竊取憑證的最佳跳板：從OpenAI密鑰到AWS/Azure云端密鑰，再到SSH訪問權(quán)限甚至Kubernetes集群配置，所有核心數(shù)字資產(chǎn)都在黑客的洗劫范圍內(nèi)。

Andrej Karpathy的帖文中也提到了這一點(diǎn)：“只需一條簡單的pip install litellm命令，就可能導(dǎo)致SSH密鑰、AWS/GCP/Azure憑證、Kubernetes配置、Git憑證、環(huán)境變量（包含你所有的API密鑰）、Shell歷史記錄、加密錢包、SSL私鑰、CI/CD密鑰、數(shù)據(jù)庫密碼等敏感信息被竊取?！?/p>

這不僅意味著數(shù)據(jù)可能在我們這種普通用戶毫無察覺的情況下，被第三方截取甚至被長期監(jiān)控，它更可能導(dǎo)致成千上萬基于LiteLLM構(gòu)建的企業(yè)級AI應(yīng)用、自動化工作流及其背后的云端基礎(chǔ)設(shè)施面臨集體破防風(fēng)險。

02

投毒是怎么發(fā)生的？

那么投毒是怎么發(fā)生的，又是怎么被發(fā)現(xiàn)的？

攻擊的起點(diǎn)并非LiteLLM的代碼漏洞，而是人的漏洞。黑客組織通過憑證竊取或社交工程手段，非法獲取了LiteLLM維護(hù)者的PyPI（Python官方包索引）賬號權(quán)限。

相當(dāng)于黑客獲得了通行證，可以直接在官方渠道發(fā)布任何他們想要的代碼。

之后陰險的地方在于，黑客并沒有修改LiteLLM原有的復(fù)雜邏輯代碼，因為大規(guī)模的代碼變動很容易在自動化掃描或人工審查中露出馬腳。

相反，他們利用了Python環(huán)境中一個極具隱蔽性的特性，即在軟件包中塞入了一個名為litellm_init.pth的文件。

這種以.pth結(jié)尾的文件原本是用來在解釋器啟動時自動配置路徑的，因此它在site-packages目錄中擁有極高的執(zhí)行優(yōu)先級。

這意味著，只要你的開發(fā)環(huán)境中安裝了這個惡意版本，哪怕你的代碼里完全沒有寫過import litellm，只要你啟動Python解釋器運(yùn)行任何程序，這段惡意代碼就會被立刻喚醒。

為了進(jìn)一步躲避安全軟件的實時監(jiān)測，黑客將攻擊指令隱藏在了看似亂碼的Base64編碼字符串中。一旦惡意腳本隨系統(tǒng)啟動，它就會瘋狂掃描宿主機(jī)中的環(huán)境變量和配置文件。

從最核心的OpenAI或Anthropic API密鑰，到AWS、Azure等云端服務(wù)憑證，甚至是SSH訪問密鑰和Kubernetes集群配置，所有能證明你數(shù)字身份的資產(chǎn)都在其洗劫范圍之內(nèi)。

整件事最有意思的部分在于，這場堪稱完美的投毒攻擊，社區(qū)只花一個小時內(nèi)就將其揭發(fā)，核心原因在于黑客的編程水平過低。

攻擊者編寫的惡意代碼存在嚴(yán)重的內(nèi)存泄漏問題，典型的“vibe coding”產(chǎn)生的Bug。

當(dāng)一位名為Callum McMahon的開發(fā)者在Cursor編輯器中使用相關(guān)插件時，惡意代碼直接把系統(tǒng)內(nèi)存吃滿導(dǎo)致宕機(jī)。這種動靜立刻引起了技術(shù)大牛們的警覺，順藤摸瓜抓住了這個剛上線不到一小時的毒包。

這也是為什么Andrej Karpathy會感到后怕：如果黑客的代碼寫得更優(yōu)雅一點(diǎn)、資源占用更低一點(diǎn)，這顆毒藥可能會在成千上萬臺服務(wù)器里靜默潛伏數(shù)月，直到把全球AI公司的API Key和云端資產(chǎn)搬空。

03

要是被投毒，我們的龍蝦還有救嗎？

根據(jù)最新的進(jìn)展，此次LiteLLM供應(yīng)鏈攻擊事件已進(jìn)入清理與止損階段。從官方團(tuán)隊發(fā)布的更新信息來看，PyPI倉庫中被黑客植入惡意代碼的污染版本v1.82.7和v1.82.8已被正式刪除。

這意味著，開發(fā)者現(xiàn)在通過pip install已經(jīng)無法直接下載到這兩個高危版本，從源頭上阻斷了惡意軟件的進(jìn)一步傳播。

然而，官方的刪除動作并不意味著受影響的開發(fā)者可以高枕無憂。如果你的本地環(huán)境或生產(chǎn)服務(wù)器在過去24小時內(nèi)執(zhí)行過更新，且目前仍停留在上述兩個版本，威脅依然存在。

由于惡意腳本利用.pth文件實現(xiàn)了“靜默啟動”和“自我復(fù)制”，單純的官方刪包無法清除已經(jīng)潛入你電腦里的毒素。

因此，當(dāng)前最緊要的操作是立即手動檢查本地環(huán)境版本，確保回滾至安全的v1.82.6。

那么此后這種投毒還可能再度發(fā)生嗎？要是OpenClaw的skill里也被人用類似的方法投毒呢？或者觸發(fā)條件更低一點(diǎn)：要是OpenClaw的skill里就調(diào)用了某個被投毒的庫呢？

會，而且很可能不止一次。

因為攻擊成本太低，而收益太高。一行惡意代碼，只要混進(jìn)一個高頻依賴，就可能影響成千上萬的項目；而防守方，卻要為每一層依賴付出審計成本。這本質(zhì)上是一場長期的不對稱博弈。

如果指望一個“一勞永逸”的根治方案，現(xiàn)實一點(diǎn)說：沒有。

這類像LiteLLM 這樣的供應(yīng)鏈投毒，本質(zhì)不是某個漏洞，而是一整套軟件生產(chǎn)方式帶來的系統(tǒng)性風(fēng)險。只要現(xiàn)代開發(fā)還依賴海量第三方庫、還在用pip install 這種“默認(rèn)信任”的分發(fā)機(jī)制，這個問題就不可能被徹底消滅。

而雖說它無法被根治，但可以被大幅壓縮到可控范圍內(nèi)。

從行業(yè)趨勢來看，已經(jīng)有幾個很明確的方向在形成。就比如在像 OpenClaw 這樣的新一代AI Agent框架上，已經(jīng)開始呈現(xiàn)多層防御的思路。

OpenClaw的3.22最新版本，已經(jīng)逐步引入沙箱隔離、權(quán)限收縮和運(yùn)行時審計等機(jī)制：高風(fēng)險操作被限制在獨(dú)立環(huán)境中執(zhí)行，敏感環(huán)境變量被主動屏蔽，子代理運(yùn)行在隔離沙箱內(nèi)，避免直接接觸主系統(tǒng)資源，同時還增加了檢測異常行為的審計能力。

同時，圍繞 OpenClaw的實踐也在快速演進(jìn)。越來越多開發(fā)者開始默認(rèn)開啟沙箱模式、用 Docker做運(yùn)行隔離、執(zhí)行最小權(quán)限原則，并對API Key做定期輪換，而不是像過去那樣，把高權(quán)限憑證直接暴露給整個Agent運(yùn)行環(huán)境。

總的來說，對開發(fā)者而言，需要把“默認(rèn)信任”切換為“默認(rèn)懷疑”；而對普通用戶來說，與其追逐功能的豐富和接入的速度，不如把選擇權(quán)交給那些真正愿意為安全付出成本的平臺。

因為在這個階段，決定體驗上限的，也許是功能，但決定風(fēng)險下限的，只能是安全。