可能是近期最可怕的開源 AI 服務遭注入惡意程式事件，每月超過 9,500 萬次下載量、被視為 AI 模型調用「瑞士刀」的熱門 Python 函式庫 ： LiteLLM 傳出遭到入侵。根據資安社群與 GitHub 上的緊急回報，攻擊者成功奪取了 LiteLLM 在 PyPI（Python Package Index）上的管理權限，並發布了惡意版本 v1.82.7 與 v1.82.8。這場攻擊背後的組織名為 TeamPCP，該組織近期已連續對 Trivy 與 KICS 等知名安全性掃描工具發動過類似攻擊。這一次，他們將目標對準了 AI 基礎架構，試圖透過滲透開發者的機器，竊取通往所有主流 AI 模型（如 OpenAI、Anthropic、AWS Bedrock）的 API 金鑰與敏感憑證。
每月超 9,500 萬次下載開源函數庫 LiteLLM 遭植入惡意程式
這起事件中最令資安專家感到震驚的技術細節，在於攻擊者利用了 Python 環境中一個相對冷門但極其危險的機制：.pth 檔案自動執行。在惡意的 LiteLLM v1.82.8 版本中，攻擊者注入了一個名為 litellm_init.pth 的檔案。在 Python 的運作邏輯中，只要 site-packages 目錄下存在 .pth 檔案，Python 解釋器在每次啟動時都會自動載入並執行其中的代碼。這意味著受害者甚至不需要在代碼中撰寫 import litellm，只要環境中安裝了該版本，任何 Python 程序（甚至是 python --version）的運行都會觸發惡意腳本。
這種「零觸發」的感染機制，讓惡意代碼能在開發者的機器上如幽靈般運作。據分析，該惡意腳本會掃描系統中的 SSH 密鑰、環境變數、AWS/GCP/Azure 憑證、甚至是加密貨幣錢包與 shell 歷史紀錄。這些資料被惡意程序以 AES-256-CBC 加密後，傳送到一個精心偽裝的網域 models.litellm.cloud（注意：LiteLLM 官方網域為 litellm.ai）。根據初步估計，全球受影響的機器可能超過 50 萬台，外洩資料量更高達 300GB，其中包含大量科技企業的核心研發秘密與雲端服務存取權。
這起攻擊事件迅速引發了 AI 界領袖的關注。前特斯拉 AI 負責人、OpenAI 創辦成員 Andrej Karpathy 在社群平台 X 上發出了嚴厲警告。他指出，目前的 AI 開發模式極度依賴於層層堆疊的開源套件，開發者往往在沒有審查的情況下就執行 pip install。Karpathy 認為，未來的網路攻擊將不再僅限於針對伺服器，而是直接針對開發者的「工作站」與「開發流程」。他呼籲開發者應該將開發環境視為「高風險區域」，並建議在隔離的容器或虛擬機器中進行實驗 。
Software horror: litellm PyPI supply chain attack.
Simple `pip install litellm` was enough to exfiltrate SSH keys, AWS/GCP/Azure creds, Kubernetes configs, git credentials, env vars (all your API keys), shell history, crypto wallets, SSL private keys, CI/CD secrets, database… https://t.co/aKjZJcECFq
— Andrej Karpathy (@karpathy) March 24, 2026
在 BerriAI（LiteLLM 的維護組織）試圖於 GitHub 發布警報時，TeamPCP 甚至利用大量機器人帳號在 Issue 下方洗版，試圖掩蓋資安通報。
反思與防禦：開發者該如何自保？
隨著 AI 工具的普及，許多非傳統資安背景的開發者進入了這個領域，卻忽略了基礎的供應鏈安全規範。在這次攻擊中，受害者可能面臨的高額損失難以估計。若以企業雲端資源被盜用的潛在成本計算，單一企業的修復與更換憑證成本可能高達數十萬美金，全球總損失推估已達數十億台幣級別。
給開發者的具體建議：
- 鎖定版本（Pinning Dependencies）： 永遠不要在生產環境或主要開發環境中使用
pip install package（不指定版本）。應使用requirements.txt或poetry.lock鎖定具體版本號與雜湊值（Hash） 。 - 檢查 site-packages： 開發者應立即檢查其 Python 環境目錄，確認是否存在
litellm_init.pth檔案。若存在，應視該機器為已遭滲透。 - 徹底輪換憑證： 若曾安裝過受影響版本，僅刪除檔案是不夠的。必須立即更換所有 API 金鑰（OpenAI, Anthropic 等）、雲端供應商（AWS/GCP）憑證與 SSH 密鑰 。
- 使用沙盒環境： 採用 Docker 或 DevContainers 進行開發，並限制容器的網路訪問權限，防止敏感資料外流。
