PoeLLM 暴露自架 AI 服務風險：LiteLLM、Ollama 管理員要先做四項檢查

圖片：TechLab 自製資訊圖

TechLab 編輯部（譯）·2026-10-09

iThome 報道指出，Lumen 旗下 Black Lotus Labs 發現名為 PoeLLM 的惡意程式攻擊行動，至少自 2026 年 4 月起針對直接暴露於互聯網的 AI 及開源服務，累計入侵超過 3,400 台伺服器。受害主機會被用作加密貨幣挖礦，亦可能掃描及攻擊其他系統，令原本只為團隊提供模型代理、推理或開發支援的服務，變成擴散攻擊的跳板。

目前公開資料顯示，受害主機主要位於美國及西歐，當中包括運行 LiteLLM、Ollama 的環境，也涉及 Gotenberg PDF 轉換工具及 Gitea 開發平台。報道沒有提供香港受害個案，也沒有證實所有同類部署均受影響；但對以雲端自架開源 AI 工具的公司及開發團隊而言，事件的實際警號很清楚：為求方便而把服務直接開放至互聯網，往往會同時暴露管理介面、未修補漏洞及日誌監察不足等問題。

攻擊面不只在模型，也在服務的公開方式

LiteLLM 和 Ollama 常被用來把不同模型、API 或本地推理能力接入同一工作流程。不過，部署者若把相關端點、管理功能或周邊工具直接放到公網，風險便不再局限於模型輸入內容，而是延伸至身份驗證、存取權限、軟件版本與基礎設施配置。iThome 所述攻擊流程是，攻擊者先掃描互聯網上的服務，再利用漏洞要求目標下載惡意程式；部分失守主機之後再協助搜尋及入侵其他伺服器。

即使服務只供內部測試，只要可從互聯網存取，仍須按公開服務的風險處理。從防守角度分析，服務的用途未必決定其風險，能否被外部發現、能否被未授權者操作，以及失陷後可否橫向或向外發動連線，反而更直接影響事件規模。尤其當 AI 服務與程式碼平台、文件轉換工具或雲端權限放在相近環境，一個被公開的薄弱環節有機會帶來超出單一應用程式的營運影響。

英文詩如何成為控制通道

PoeLLM 的特別之處，是以 GitHub 儲存庫內的一首英文詩取得指揮及控制（C2）伺服器位址。iThome 報道指，該詩被藏在名為 dash.css 的檔案；惡意程式讀取詩中四個指定位置的字詞，再按內建對照表轉換為四組數字，拼合成 C2 的 IP 位址。這代表攻擊者可透過修改詩中關鍵字更換控制位置，受感染主機毋須重新下載另一個惡意程式樣本。

該英文詩自 4 月 13 日首次上傳後已修改 11 次。這個設計的意義在於，防守方若只封鎖某一個固定 IP，未必足以長期切斷控制通訊；同時，表面像普通程式資源檔或公開內容的項目，可能被濫作更新式的指令來源。這不代表所有 GitHub 資源或 CSS 檔案均可疑，而是日誌分析應把「哪些工作負載為何會連向哪些外部來源」列為核心問題，避免只按檔案名稱或網域表面判斷風險。

CVE-2026-42271 仍須按已知事實處理

針對 LiteLLM，Black Lotus Labs 在惡意程式樣本中發現與命令注入漏洞 CVE-2026-42271 有關的測試端點，並推測這可能是攻擊者使用的入侵途徑。這一點必須審慎理解：iThome 報道所載是研究團隊的推測，並非已確認每一宗 PoeLLM 入侵皆由該漏洞造成，也不足以推論所有 LiteLLM 實例已被攻破。

因此，管理員不宜把排查範圍窄化為單一 CVE，亦不應因未發現該端點就認定環境安全。較穩妥的做法是核對正在使用的版本、供應商或專案發布的修補資訊，以及服務實際暴露的路徑和權限設定；若已有公開管理端點或不必要的遠端存取，即使最終入口與 CVE-2026-42271 無關，仍然屬於應優先處理的風險。這是事件帶來的配置層面教訓。

可立即執行的四項防護工作

Black Lotus Labs 已封鎖 Lumen 網絡與已知 PoeLLM C2 伺服器的通訊，並公布攻擊指標供企業檢查；截至報告發布時，研究團隊辨識到 12 個 C2 位址，其中 3 個仍在活動。個別企業未必能只依賴外部封鎖，因此應把公開資產、修補與監察連結成一個持續流程，而非事件發生後才逐部伺服器搜尋。

盤點公開服務：列出所有可從互聯網到達的 LiteLLM、Ollama、Gitea、Gotenberg 及相關管理介面，確認是否真的需要公開；同時核對測試、舊版與臨時部署，這些環境往往最容易被遺漏。
限制外部存取：把毋須對外的服務移回私有網絡或經 VPN、存取控制及適當驗證後才可使用，並收緊管理端點的來源範圍。這可直接減少被大規模掃描發現的機會。
更新及修補：定期更新 AI 與開源服務，按官方修補資訊評估 CVE-2026-42271 及其他適用漏洞，並保留可追溯的版本與變更紀錄，避免修補狀態只靠口頭確認。
檢查網絡和系統日誌：覆核伺服器的異常外連、可疑下載、陌生程序及掃描行為，並以 Black Lotus Labs 公開的攻擊指標作補充比對。若發現疑似受影響主機，應優先隔離及按既有事故處理程序調查。

接下來值得觀察的是，研究團隊會否確認 PoeLLM 對 LiteLLM 的確切利用鏈，以及其公開指標能否揭示更多受影響服務類型。對採用自架 AI 的團隊來說，最務實的下一步並非等待完整歸因，而是先確認每項服務是否必須對外可見、是否已修補，以及日誌能否讓管理員及早看見異常連線。