AIDEFEND in Action AIA-0093 實證研究發布於 AIA: 2026年10月1日

Bleeding Llama：惡意 GGUF 模型讓 Ollama 越界讀取記憶體並外傳

Ollama 是一款可於本機與伺服器執行大型語言模型推論的軟體。Cyera 揭露並驗證：在 Ollama 0.17.1 之前的版本中，特製的 GGUF 張量大小宣告可在 /api/create 執行 F16 轉 F32 轉換時觸發堆積記憶體（heap）越界讀取（漏洞編號為 CVE-2026-7482）。越界讀取的記憶體位元組會被寫入新產生的模型檔案，隨後可透過 /api/push 推送至攻擊者控制的模型登錄庫（registry）。遠端發動攻擊的前提是管理 API 暴露於網路上；Ollama 原生執行檔預設僅綁定 127.0.0.1，官方容器映像檔則將 OLLAMA_HOST 設為 0.0.0.0，管理者亦可能自行調整監聽位址。

Privacy LeakageTool AuthorizationRuntime IsolationAI Infrastructure

8 項對應的 AIDEFEND 防禦手法

來源: Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama

作者: Dor Attias

原文發布: 2026年5月5日

威脅分析

GGUF 模型建立流程跨越了兩道關鍵邊界：在 F16 轉 F32 時直接採信張量宣告的長度，隨後又允許將生成的模型成品推送至外部。越界讀取屬於產品本身的記憶體安全漏洞，而未經身分驗證的管理 API，則在管理者不慎對外暴露 Ollama 時使遠端攻擊成為可能。

攻擊者必須透過非預設的網路暴露設定或已開放的連線路徑，連線至 /api/blobs、/api/create 與 /api/push；Ollama 上游原始碼預設僅監聽本機迴路位址（loopback）。
攻擊者將宣告元素數量遠大於實際資料緩衝區大小的特製 GGUF 模型檔案，透過 /api/blobs 介面上傳。
攻擊者利用上傳的 blob 建立模型並指定 F32 輸出；有漏洞的轉換程式碼讀取超出 heap 配置邊界的鄰近程序記憶體，並寫入新模型成品中。
模型名稱設定為攻擊者控制的外部 registry，隨後透過 /api/push 將內含提示詞或其他測試環境程序記憶體的模型成品外傳。

Ollama 上游原始碼預設僅綁定 127.0.0.1 而非 0.0.0.0。Cyera 是在受控環境中重現此攻擊鏈；單憑端點對外暴露或 CVE 編號本身，並不能直接推論已有真實使用者的機密資訊外洩。

適用的 8 項 AIDEFEND 防禦手法

AID-H-003.010

Deployed AI Software Vulnerability Remediation Lifecycle

極高

透過分階段部署將 Ollama 升級至 0.17.1 或更新版本，並獨立讀回每個執行個體的運行版本與容器映像檔摘要值（digest），徹底移除有漏洞的 GGUF 轉換程式碼路徑。

AID-H-038.001

Inference Runtime Listener & Protocol Conformance

極高

原生 Ollama 應綁定官方文件列出的 loopback 位址，並在啟動後獨立列出實際程序監聽端點。Docker 部署須查核容器監聽、主機連接埠對應、bridge 可達性與實際 NAT／防火牆規則；只看 ss 可能漏掉 NAT 對應。Kubernetes 另須涵蓋 Service、端點及 Pod／網路政策的可達性。拒絕未核准路徑，並從實際呼叫端實測允許與拒絕的連線。容器內監聽 0.0.0.0，不能單獨證明已公開或已隔離；loopback 限制直接遠端連線，不會修補解析器。

AID-H-038.002

Inference Runtime Privileged Operation Authorization

極高

列出每個確切 HTTP 方法與正規化路由，區分推論、健康檢查與高權限管理操作。通往 Ollama 的唯一閘道須驗證呼叫者身分、預設拒絕未知路由，並要求上傳、建立、推送、拉取、刪除與複製操作另具操作員授權。推論只能使用逐項審查的允許清單，不能整批放行 /v1/*。另須測試替代路由與後端直接連線，確認被拒絕的操作不會變更模型狀態。

AID-H-004.002

Service & API Authentication

高

在 Ollama 前端架設驗證短效金鑰或工作負載身分的 API 閘道，並確保後端僅允許該閘道連線。原生環境可採用 loopback；在 Docker 或 Kubernetes 部署中，應實測連接埠對應、Service 路由與網路政策，絕不可因容器內部監聽 0.0.0.0 即認定該服務完全私有。身分驗證僅能確認呼叫者身分，是否具備建立或推送模型的權限仍須由獨立的操作授權閘道把關。

AID-I-002.001

Internal AI Network Segmentation

高

當 Ollama 必須監聽非 loopback 介面時，應將其配置於安全群組或 NetworkPolicy 內，設定 11434 連接埠僅接收來自應用程式閘道或指定模型載入主機的連線，其餘來源一律阻絕。如此一來，攻擊者的三項 API 呼叫便無法從網際網路或其他工作負載抵達該程序，盤點發現的暴露執行個體數量亦可縮減至經核准的呼叫端。

AID-I-002.002

Secure External AI Service Connectivity

高

Ollama 所在的主機或 Pod 必須對外連線實施預設拒絕（default-deny），僅允許連線至受控且僅供下載的內部模型鏡像庫，或經明確核准的特定外部目的地。此舉可阻斷向未核准外部主機推送資料的路徑。若系統仍允許存取公開 Ollama 模型登錄庫，攻擊者在該登錄庫建立的命名空間（namespace）仍可能接收推送；單靠主機層級的目的地過濾無法完全防範該路徑，仍須由操作授權閘道嚴格阻斷未授權的 /api/push 請求。

AID-M-001.005

Public AI Endpoint & Agent-Service Exposure Discovery

中

從獲授權的外部位置，對完整登錄的主機與連接埠進行範圍受限的唯讀 GET /api/tags 與 /api/version 探測，涵蓋實際設定的非標準連接埠。以版本化的 Ollama 特徵比對回應結構，再將確認的端點核對至負責人與核准的暴露狀態。不能為了辨識服務而上傳 blob、執行推論或推送模型；一般 HTTP 回應也不能證明是 Ollama 端點，或整個服務都已要求身分驗證。

AID-M-001.006

Internal AI Endpoint & Agent-Service Discovery

中

結合 IPAM、雲端平台與 Kubernetes 匯出資料建立內部掃描清單，針對私有位址空間探測 11434 連接埠與 Ollama 未驗證路由，並將具回應的執行個體核對至負責人與授權狀態。開發人員以 -p 11434:11434 啟動的容器或未配置 NetworkPolicy 的 Pod 會在此處被發現；由外而內的外部掃描（AID-M-001.005）無法偵測此類資產，但 Docker 容器實際的暴露面多半為區域網路或 VPC 內部。

身為資安防禦者，我們應該這麼做

所有可能處理不可信 GGUF 檔案的 Ollama 執行個體，皆應立即升級至 0.17.1 或更新版本。
全面盤點實際的 OLLAMA_HOST、反向代理、Docker 連接埠對應、同網路容器、Kubernetes Service 與 NetworkPolicy 的可達性。容器內部監聽設定本身不能證明對外暴露或已獲隔離。管理 API 必須落實呼叫者驗證，並針對模型操作的 HTTP 方法與路徑進行細緻授權。
對外連線實施預設拒絕，優先採用受控且僅供下載的內部模型鏡像庫。若仍須連線至公開模型登錄庫，必須額外阻斷未經授權的 /api/push；僅過濾目標網域無法防止資料推送至攻擊者於公開平台建立的 namespace。

1 個額外的防禦考量

證據與部署界線

Cyera 是在受控環境中重現並驗證此攻擊鏈，引用的公開來源並未證實真實世界攻擊事件。GGUF 解析器漏洞本身必須透過軟體升級修補；所對應的身分驗證、監聽位址限制、網路隔離與輸出管制，則能有效約束誰能呼叫模型建立功能以及成品可推送之目標。

建議做法: 所有可能處理不可信 GGUF 檔案的 Ollama 執行個體，皆應立即升級至 0.17.1 或更新版本。

結論

AIDEFEND 指出此攻擊鏈涵蓋三道獨立控制防線：修補 GGUF 解析器安全漏洞、限縮模型管理路由的存取權限，以及阻絕未經授權的模型推送操作。針對 Docker 或 Kubernetes 部署的實際網路暴露面與對外傳輸路徑，必須進行獨立實測驗證。

最後更新: 2026年10月1日