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

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

不要認為LiteLLM被投毒和OpenClaw沒有任何關系。

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

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

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

01

投毒破壞力從何而來？

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

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

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

它的核心價值在于將復雜的各家API統一為OpenAI標準格式，使得開發者只需寫一套代碼就能無縫切換模型。

另外，在很多企業架構里，LiteLLM不僅僅是一個庫，更是作為“AI網關”管理著全公司的模型調用權限與成本追蹤。

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

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

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

這不僅意味著數據可能在我們這種普通用戶毫無察覺的情況下，被第三方截取甚至被長期監控，它更可能導致成千上萬基于LiteLLM構建的企業級AI應用、自動化工作流及其背后的云端基礎設施面臨集體破防風險。

02

投毒是怎么發生的？

那么投毒是怎么發生的，又是怎么被發現的？

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

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

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

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

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

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

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

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

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

攻擊者編寫的惡意代碼存在嚴重的內存泄漏問題，典型的“vibe coding”產生的Bug。

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

03

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

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

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

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

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

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

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

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

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

如果指望一個“一勞永逸”的根治方案，現實一點說：沒有。

這類像LiteLLM 這樣的供應鏈投毒，本質不是某個漏洞，而是一整套軟件生產方式帶來的系統性風險。只要現代開發還依賴海量第三方庫、還在用pip install 這種“默認信任”的分發機制，這個問題就不可能被徹底消滅。

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

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

OpenClaw的3.22最新版本，已經逐步引入沙箱隔離、權限收縮和運行時審計等機制：高風險操作被限制在獨立環境中執行，敏感環境變量被主動屏蔽，子代理運行在隔離沙箱內，避免直接接觸主系統資源，同時還增加了檢測異常行為的審計能力。

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

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

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