本篇文章更新時間：2026/03/27
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
LiteLLM 1.82.8 惡意套件事件全解析：一場開發者親身經歷的快速應變
編輯前言：這篇文章源自未來搜尋團隊在 2026 年 3 月 24 日遭遇的 litellm 1.82.8 供應鏈攻擊。本篇不是單純的安全通報，而是一段「從系統異常，到發現惡意程式，再到公開揭露」的完整實戰紀錄。原文可見於 My minute-by-minute response to the LiteLLM malware attack。
核心觀點 (Key Takeaways)
- 這次攻擊不是本地端感染，而是 PyPI 官方套件遭惡意版本替換（litellm 1.82.8）。
- 惡意程式透過
.pth機制在 所有 Python 啟動時自動執行，具備憑證竊取、K8s 橫向移動與後門安裝能力。 - AI 工具（此例為 Claude Code）能在短時間內協助完成惡意分析、證據比對與公開揭露，形成一種全新的「加速式事件反應模式」。
深入解析
在事件發生當天，原本只是一台筆電因為 11,000 個 Python 子程序突然爆量而卡死。當時的初步猜測是某段程式自動生成 loop，但深入鑑識後，情況開始急轉直下。原文中首次提到關鍵異常是：
litellm_init.pth found — credential theft, K8s lateral movement, exfil
也就是說，在 litellm 1.82.8 的 wheel 檔內，藏了一個名為 litellm_init.pth 的檔案，會在 Python 啟動時自動執行。這檔案會呼叫一段經 Base64 編碼的第二階段 payload，內容包括：
- 竊取 SSH keys、GCP/AWS/K8s 憑證、.env 檔、資料庫密碼
- 加密後傳送到
https://models.litellm.cloud/ - 嘗試在
~/.config/sysmon/sysmon.py建立後門 - 在 Kubernetes 叢集佈署惡意 pod，進行橫向移動
此外，由於惡意程式會在 Python 啟動時再次觸發自己，並透過 subprocess.Popen([sys.executable, ...]) 連續再生新子程序，最終導致「遞迴式爆炸」，形成筆電當時遭遇的 11k process fork bomb。
更驚人的是，PyPI 上的 1.82.8 版本並沒有對應的 GitHub tag，且發佈時間恰好在事件發生前 6 分鐘，幾乎可以確定是 套件發佈權限遭到入侵。
- 快速反應如何可能？：原文強調，如同這次事件所示，AI 工具能協助開發者跨域完成鑑識流程，不再依賴手動查 log、比對 wheel、撰寫報告，而是讓人類將精力用在判斷與決策上。
筆者心得與啟發
這篇紀錄給我的最大啟發，是「供應鏈攻擊已不再是大型企業的專屬風險，而是每一位開發者都可能在日常環境中遇到的問題」。從筆電卡死，到發現 PyPI 惡意套件，再到公開揭露，全程只花了 72 分鐘，而這速度的背後，是 AI 工具漸漸成為事件處理流程的一部分。
換句話說，在 AI 加速開發的時代，我們也必須同時面對「AI 也加速攻擊與偵測」的現實。如果包管理系統一天內發佈的版本你沒有注意，下一次 pip install，可能就成為攻擊入口。
對於開發者來說，最值得記住的可能是原文這句話：
You no longer need to know the specifics… you just need to be calmly walked through the human aspects of the process.
安全事件的複雜度不會降低，但 AI 讓我們能以更快的速度做出反應。未來面對供應鏈風險，我相信這將是所有工程團隊都必須具備的新肌肉記憶。