人工智慧
AI 堆疊根金鑰外洩警訊：LiteLLM PyPI 供應鏈事件深度解析
LiteLLM PyPI 資料外洩事件說明：惡意版本如何竊取雲端登入憑證、SSH 金鑰以及 Kubernetes 機密，了解衝擊與緊急防範步驟。
Save to Folio
PyPI 上的熱門 LiteLLM Python 套件遭駭客入侵，1.82.7 和 1.82.8 兩個版本當中含有惡意程式碼會竊取您的雲端登入憑證、SSH 金鑰以及 Kubernetes 機密。假使您在 2026 年 3 月 24 日當天或之後曾經更新您的環境，那麼您最好假設自己的金鑰已經被人偷走。請立即放下手邊的工作，將該套件刪除，並要求您的團隊馬上更換登入憑證。
一名粗心的駭客給世界一個晨間驚喜
想像一下，您的工程師才剛端著一杯咖啡坐下來準備開始工作，但是一啟動電腦就發現機器瞬間當掉，業界正是這時候驚覺遭到了 LiteLLM PyPI 供應鏈攻擊。由於惡意程式當中出現了一個錯誤，讓子處理程序陷入無盡迴圈：一個意外的分岔炸彈 (fork bomb) 導致整台主機停止運作。當初駭客的程式設計功力若是再好一點的話，我們大概就不會看到這個錯誤，而他們可能現在都還在暗中竊取您的營運機密。所以，算我們幸運。
根據 FutureSearch 的資安分析，駭客盜用了 LiteLLM 專案維護者的帳號。他們規避了 GitHub 標準的版本發行程序，直接將遭到駭入的版本推送至 PyPI。由於 LiteLLM 是開發人員與幾乎所有主要 LLM 端點連接的橋樑，因此，從基礎的腳本到進階的程式撰寫 AI 代理，一切都得仰賴它來運作。
也因此，這次事件的衝擊半徑相當驚人，該套件光是昨天就被下載了 3,408,615 次，上個月更是累積了 9,500 萬次下載。如果您的工程團隊正在進行 AI 相關的開發，那麼幾乎可以肯定他們會在您環境內安裝這個套件。
AI 防護終究還是軟體防護
每個人都在談論進階 AI 漏洞，例如：提示注入、資料下毒、模型逆向工程 (model inversion)。然而，駭客卻正在利用我們十多年來一直在對抗的基礎架構漏洞。
AI 技術堆疊是建立在標準、脆弱的開放原始碼基礎之上，駭客總是瞄準中央最脆弱的環節。如果光是在一個 Python 相依元件下毒就能讓 AI 雙手奉上您的 Kubernetes 叢集，那駭客又何必成天想著 LLM 越獄？ 我們一直將 AI 視為一個全新的領域，但駭客卻只是使用舊的供應鏈攻擊技巧就能駭入您的企業。
此外，這起事件也暴露出，盲目更新到最新的套件版本有多麼愚蠢。執著於在最新修補更新推出時就立即套用，本身就是一個巨大漏洞。如果您的 CI/CD 流程會自動拉取最新的版本而沒有先將它隔離觀察一段時間的話，那您等於幫自己自動製造資安事件。所以，請務必緊盯著相依元件的加密雜湊碼 (而非版本)。而且，先讓別人的基礎架構測試最新的版本看看是否有專門攻擊供應鏈的惡意程式。
雲端原生搶劫
駭客利用已知的 Python 漏洞攻擊手法，在 Python 直譯器啟動時自動執行隱藏的腳本。您的團隊甚至不需匯入被駭的函式庫，只要執行一個毫不相干的腳本，就會觸發惡意程式。
惡意程式一旦啟動，就會變成一個高度精密且瞄準雲端的資訊竊取程式。它會廣泛竊取 AWS、GCP 和 Azure 的組態設定，並且主動查詢您內部雲端的 metadata 來挾持執行個體的角色。
但真正的噩夢來自 Kubernetes 內部，如果惡意程式偵測到服務帳號權杖 (token)，攻擊就會升高到接管整個叢集。它會使用權仗來竊取每一個命名空間的機密。更糟的是，它會設法逃出容器之外，跳出隔離的 Pod 環境，直接在您的底層主機節點上安裝常態性後門。想像一下，您可能只提供識別證給廠商進出您的大廳，結果卻發現他們複製了主金鑰，然後在您的伺服器機房內建立據點。
最後，它會將您的資料加密並傳送至駭客掌控的伺服器，並建立第二個連線到 checkmarx.zone，刻意利用一個受信任的品牌來避開您的 DNS 允許清單。
我們不斷對機密使用習慣提出警告
這起事件暴露出業界目前打造軟體的方式存在著一個嚴重的架構缺陷，盲目信任開放原始碼登錄，但更重要的是，這讓駭客的工作在突破邊界之後變得無比輕鬆。趨勢科技一直在持續發表有關這類攻擊途徑的研究，因為我們每一天都會看到有駭客在利用這些攻擊途徑。
惡意程式特別喜歡傾印環境變數，並且尋找隱藏在您目錄深處的 .env 檔案。如果您的企業還在將長期的登入憑證儲存在環境變數中，或者在營運環境硬碟上遺留了未加密的機密，那麼您等於親手將您的基礎架構交到駭客手中。我們在關於 DevOps 雷區的報告中就曾經介紹過這些漏洞以及環境變數的隱藏危險。
這正是 TrendAI Cloud Risk and Exposure Management (CREM) 存在的原因，只要您主動發掘並管理您的雲端曝險，就算駭客偷了您的服務帳號權杖也只會走到死巷，不會引發整個叢集的災難，不過您得在惡意檔案引爆之前控制其衝擊半徑。
該讓您的資安工具上場了
追求完美的架構是一種迷思，當零時差供應鏈攻擊繞過您的代理登錄時，您需要的是一套多層式防禦來阻止它。
TrendAI Code Security 可在組建階段掃描容器映像，標記已遭駭入的函式庫，這樣就能在惡意程式引爆之前預先攔截。但如果零時差漏洞攻擊已經穿透您的流程，那麼靜態掃描工具就無用武之地，您需要的是一個執行時期行為防護網。這就是 Container Security 和 Vision One 接手的時候，我們會監控實際的執行狀況：如果您的容器內一個看似無害的 Python 腳本突然傾印了 Azure 登入憑證、讀取了 Kubernetes 服務帳號的權杖，並且試圖安裝背景程式 (daemon)，那麼我們的 XDR 代理程式就會標記該行為異常，並終止該處理程序，不讓駭客有機會將資料外傳。
我們為您的基礎架構提供了關鍵的防火警報，但請記住：我們只能提供警報，您還是必須用防火材料來建造房子。
現在您該要求團隊做些什麼
若您已在您的堆疊中導入了 LiteLLM，那麼請立即根據已知的入侵指標 (IoC) 對您的工程與資安團隊下達以下指令：
- 清除環境：請他們搜尋 litellm_init.pth 並清除所有套件管理員快取。
- 搜尋常駐的植入檔案：請您的 SOC 搜尋是否有未經授權的 sysmon.service 背景程式和可疑的暫存檔案，如：/tmp/pglog 或 /tmp/.pg_state。
- 稽核您的 Kubernetes 叢集：在 kube-system 命名空間內尋找符合「node-setup-*」這個搜尋條件的異常特權 Pod。
- 攔截外送流量：確保您的網路丟掉所有試圖對外連上 checkmarx.zone 和 models.litellm.cloud 的封包。
- 假設已經遭到入侵：立即強制更換 SSH 金鑰、雲端供應商登入憑證，以及資料庫密碼。
切勿等到廠商發出重大警訊才動作，駭客已經拿到他們想要的了。
該付的絕對逃不掉
我們將整個生態系建立在一個脆弱的信任基礎上，LiteLLM 駭客事件只是駭客利用我們對開放原始碼登錄的依賴以及機密使用習慣不佳的最新案例。資安不能事後才來亡羊補牢，也不能完全依賴漏洞掃描工具。若您允許開發人員在營運環境隨意安裝未經驗證的套件，並且以明碼方式隨意儲存機密，那您乾脆直接將根金鑰寄給駭客算了，這樣還可以幫他們節省一些心力。
資料來源
- FutureSearch：LiteLLM PyPI 供應鏈攻擊
- 趨勢科技：研究報告 - 製造混亂：隱藏在 DevOps 雷區的真實威脅
- 趨勢科技：分析將機密儲存在環境變數的隱藏危險