全球最普及的本地 AI 模型執行框架 Ollama，2026 年 5 月 5 日被安全研究公司 Cyera 公開披露一個代號「Bleeding Llama」的嚴重漏洞（CVE-2026-7482，CVSS 官方評分 9.1），波及全球逾 30 萬台暴露於公共互聯網的 Ollama 伺服器。攻擊者無需身份驗證，即可從伺服器運行記憶體中竊取 API 金鑰、系統提示詞、用戶對話紀錄及環境變數，並藉 Ollama 內建的模型推送功能將數據偷運至外部伺服器，整個過程不留任何錯誤日誌。本文涵蓋三個核心面向：漏洞技術原理及三步攻擊鏈、同步曝光的 Windows 持久化後門，以及企業應對 Ollama 安全風險的即時行動清單。
三個 API 呼叫洩漏整個伺服器記憶體，AI 金鑰機密任人取閱
Bleeding Llama 的根源在於 Ollama 處理 GGUF（GPT-Generated Unified Format）模型文件時，錯誤地引入了 Go 語言的 unsafe 套件。GGUF 是本地儲存大型語言模型的標準文件格式，儲存模型的權重、元數據與分詞器資訊。問題核心在 WriteTo() 函數：Ollama 在執行模型量化（quantization）過程中，未驗證 GGUF 文件所宣告的 tensor 大小與文件實際長度是否一致，令攻擊者可上傳一個偽造的 GGUF 文件，將 tensor 大小宣告為遠超文件實際長度的數值，強迫伺服器讀取超出已分配堆記憶體（heap buffer）邊界的數據，造成「越界讀取」（out-of-bounds read）。CVE.org 官方描述，受影響版本為 Ollama 0.17.1 以前所有版本。
整個攻擊鏈僅需三步完成，且全程無需任何身份驗證。攻擊者首先通過 HTTP POST 向目標 Ollama 伺服器上傳精心偽造的 GGUF 文件；繼而調用 /api/create 端點觸發模型創建，激活越界讀取漏洞，將堆記憶體數據烘焙進生成的模型文件；最後透過 /api/push 端點，把包含洩漏記憶體的模型推送至攻擊者控制的遠端倉庫，完成資料外洩。可洩漏的敏感資料涵蓋環境變數、API 金鑰、系統提示詞、同時用戶的對話紀錄，乃至通過 Ollama 路由的程式碼和業務數據。Cyera 安全研究員 Dor Attias 警告：「攻擊者幾乎可以從你的 AI 推理服務中獲取組織的一切——API 金鑰、專有代碼、客戶合約，以及更多。若工程師將 Ollama 連接至 Claude Code 等工具，衝擊更大，因為所有工具輸出均會流入 Ollama 伺服器的堆記憶體。」攻擊全程不在日誌留下任何錯誤，伺服器亦不會崩潰，使偵測極為困難。
Ollama 預設不提供任何身份驗證機制，而不少開發者和企業為方便遠端調用，將服務綁定到所有網絡介面（OLLAMA_HOST=0.0.0.0），直接暴露於公共互聯網。SecurityWeek 分析指出，受影響資料視乎企業的 Ollama 使用方式，可能包含員工互動紀錄、開發程式碼、含個人識別資料（PII）及受保護醫療資訊（PHI）的提示詞，以及路由至 Ollama 的工具輸出。Cyera 明確建議：若你的 Ollama 伺服器曾可從互聯網存取，應視記憶體中的環境變數和機密數據已遭入侵，立即更換所有 API 金鑰和存取憑證。
Windows 版本藏兩個未修補後門，攻擊者可每次登入靜默執行任意程式碼
就在 Bleeding Llama 披露的同期，安全研究公司 Striga 聯合創辦人 Bartłomiej Dmitruk 同步披露了 Ollama Windows 版本更新機制中兩個更具破壞力的漏洞。兩個漏洞於 2026 年 1 月 27 日向 Ollama 完成披露，在標準 90 天披露期屆滿後仍未收到有效回應，遂於 2026 年 5 月公開。
漏洞一（CVE-2026-42248，CVSS 7.7）：Ollama Windows 版本的更新簽名驗證函數雖存在且被調用，但執行時無條件回傳成功，不進行任何數碼簽名或完整性驗證，令任意可執行檔案均可被接受並運行。Striga 指出，macOS 版本正確執行代碼簽名驗證，Windows 版本則完全缺席。漏洞二（CVE-2026-42249，CVSS 7.7）：更新程序直接從 HTTP 回應標頭讀取數值來構建本地檔案路徑，未作任何清理過濾，令攻擊者可注入路徑穿越序列（../），將惡意可執行檔案寫入 Windows 啟動資料夾（Startup folder）或其他任意位置。
兩個漏洞組合的威力在於實現「持久化」靜默後門：即使下一次合法更新覆蓋了更新暫存檔案，透過路徑穿越寫入啟動資料夾的惡意檔案仍會在每次用戶登入時自動執行。Dmitruk 解釋，可能的攻擊載荷包括反向 Shell、竊取瀏覽器密鑰和 SSH 金鑰的資料竊取程序，以及建立進一步持久化的下載器。CERT Polska 在接管協調披露工作後確認，Ollama for Windows 版本 0.12.10 至 0.17.5 已驗證存在漏洞；Striga 自身的披露則指出，0.12.10 至 0.22.0 均受影響，但其他版本未逐一測試。暫行緩解方案是關閉自動更新，並檢查 Windows 啟動資料夾（%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup）是否存在不明可執行檔案。
從「Probllama」到「Bleeding Llama」：Ollama AI 安全漏洞的演進脈絡
Bleeding Llama 並非 Ollama 的首個嚴重漏洞，而是一系列安全事故中影響規模最大的一次，折射出整個本地 AI 推理生態系統的結構性安全缺陷。在時間軸上：2024 年中，Wiz 發現可達到遠程程式碼執行效果的路徑穿越漏洞 CVE-2024-37032（別稱「Probllama」），Ollama 在版本 0.1.34 迅速推出修補。同年秋季，Oligo Security 披露六個漏洞，其中涵蓋拒絕服務、模型投毒及模型竊取風險；Ollama 維護者對模型投毒和模型竊取兩個問題提出異議，認為屬使用者配置範疇而非平台漏洞，並建議用戶透過代理過濾端點存取，兩個問題至今無官方 CVE 編號。2026 年 1 月，SentinelOne 與 Censys 聯合調查發現全球已有 175,000 台 Ollama 主機跨越 130 個國家暴露於公共互聯網，香港亦在重點分布地區之列，其中近半配備工具調用功能，理論上可直接接入外部 API 和程式碼執行環境。
Bleeding Llama 的披露時間線同樣突顯 CVE 體系的效率困境。Dor Attias 於 2026 年 2 月 2 日向 Ollama 報告漏洞，Ollama 於 2 月 25 日確認，並提供修補方案，0.17.1 版本隨後上線——但更新日誌並未明確標明這是安全修補，令大量營運者渾然不知需緊急升級。研究員隨即向 MITRE 申請 CVE 編號，等候逾兩個月無果，最終於 4 月 26 日轉向第三方 CVE 編號機構 Echo，CVE-2026-7482 於 4 月 28 日方才獲派，5 月 1 日正式公開。這段空窗期，意味着 30 萬台伺服器在毫無警覺的狀態下持續暴露。
企業 Ollama 安全治理的結構性缺口，開源 AI 基建風險不容忽視
Ollama 在 GitHub 累積逾 171,000 個 Star，Docker Hub 下載量突破 1 億次，廣泛應用於企業自架 AI 推理環境。正是這種快速普及，令安全隱患加速積聚。CSO Online 分析指出，Ollama 因允許員工在企業管治框架外自行啟動本地 AI 伺服器，被企業 IT 團隊普遍歸類為嚴重的「陰影 AI」風險，製造大量安全盲點。Wiz 研究員亦直言：「Ollama 項目仍處於早期階段，不支持身份驗證等關鍵安全功能。即使運行最新版本，攻擊者仍可獲取 Ollama 伺服器上使用的 AI 模型，甚至利用受害者算力運行這些模型。」建議部署反向代理在 Ollama 前方加設認證層，或直接透過 Tailscale 等工具實現零信任存取控制。
宏觀數據更令人警惕。Black Duck 發布的《2026 年開源安全與風險分析》（OSSRA）報告顯示，企業應用程式中嵌入的開源漏洞平均數量按年激增 107%，達到每個程式碼庫 581 個。Black Duck 行政總裁 Jason Schmitt 總結：「軟件創建的速度已超過大多數組織能夠保護它的速度。」這一矛盾在 AI 基礎設施領域尤為突出：AI 工具的採用速度遠超安全治理的跟進能力，而 Ollama 等本地部署框架在「便捷性優先」的設計哲學下，天然缺乏企業級身份驗證和審計功能。
隨着歐盟《AI 法案》高風險 AI 義務將於 2026 年 8 月正式生效，監管壓力正在收緊。Ollama 用戶的即時行動清單如下：升級至 0.17.1 或以上版本；將服務綁定回 127.0.0.1，禁止公開互聯網直接存取；在所有 Ollama 實例前部署帶身份驗證的 API 閘道；Windows 用戶關閉自動更新並審查啟動資料夾；若伺服器曾暴露，即時更換所有 API 金鑰和存取憑證。Bleeding Llama 反映的核心問題，是企業何時才開始認真保護本地 AI 推理伺服器，將其視作生產基礎設施，而非着眼於 Ollama 有多少漏洞。
資料來源：Cyera Research | SecurityWeek | CERT Polska | Help Net Security | CSO Online
