Bleeding Llama:GGUF 解析漏洞向未认证攻击者泄露 Ollama 进程内存

这是什么?

2026 年 5 月,Cyera 的研究人员公开披露了 CVE-2026-7482(CVSS 9.1),这是流行的本地推理运行时 Ollama 中的一个未认证越界读取漏洞,他们将其命名为 Bleeding Llama。该漏洞允许能够访问 Ollama 服务器 HTTP API 的远程攻击者在完全无需认证的情况下,从服务器的堆内存中提取任意片段——环境变量、API 密钥、系统提示,以及其他用户对话的片段。

漏洞位于 Ollama 的 GGUF 解析器中。当服务器处理一个 GGUF 模型文件,其中声明的张量偏移量和大小超过文件实际长度时,fs/ggml/gguf.go 和 server/quantization.go 中的函数会在量化过程中读取超出分配堆缓冲区的内存,从而导致可控的内存泄漏。

修复程序于 2026 年 2 月 25 日随 Ollama v0.17.1 一同发布,但未被标识为安全发布。该 CVE 编号在 MITRE 长达近两个月未做回应后,直到 2026 年 4 月 28 日才由第三方 CNA Echo 分配,公开披露文章则在 2026 年 5 月发布。在大约十周的时间窗口内,补丁虽然存在,但运维人员没有任何信号提示其优先级。在此期间,据估计全球超过 300,000 台暴露在互联网上的 Ollama 实例都处于易受攻击状态。

工作原理

Bleeding Llama 是教科书式的信任边界失效案例:服务器解析不受信任的文件格式,却信任了描述如何读取载荷的元数据字段。

# 基于 Cyera 公开建议的概念性示意图。
# 未复现任何针对真实系统的可利用 payload。

[ 攻击者 ]
     │
     │ 1. POST /api/create   ─── 上传一个伪造的 GGUF,张量大小被人为放大
     ▼
[ Ollama 服务器 ]
     │
     │ 2. 解析 GGUF 元数据
     │    └── 张量偏移量 / 大小未经过文件长度的边界检查
     │
     │ 3. 量化步骤从堆中读取 N 个字节
     │    其中 N 来自攻击者控制的张量描述符
     │    └── 越过已分配缓冲区的越界读取
     │
     │ 4. POST /api/push     ─── 服务器将生成的"模型"推送出去
     ▼
[ 攻击者外传端点 ]
     │
     └── 堆字节:环境变量、API 密钥、系统提示、其他用户对话

理解影响范围需要把握两个背景。

第一,GGUF 是本地模型权重的标准打包格式——每个现代开源权重模型都以这种方式分发。GGUF 文件本质上是一个带元数据头的二进制 blob,头部告诉加载器每个张量的位置和大小。Bleeding Llama 正是这种设计可预见的漏洞类:解析器相信了头部。

第二,攻击链中使用的两个端点(/api/create 和 /api/push)在 Ollama 中默认未做认证。上游文档对此有所说明,默认绑定地址为 127.0.0.1,但许多真实部署会用 OLLAMA_HOST=0.0.0.0 覆盖默认值,以便机器为开发者网络或容器集群提供服务。仅这一个环境变量的修改,就能把 Bleeding Llama 从本地小麻烦变成暴露在互联网上的远程攻击原语。

被泄露的内存是 Ollama 进程的堆,其中通常包含:当前服务的系统提示、最近的用户提示和模型输出、环境变量(在云虚拟机上通常包括 AWS / GCP / Anthropic / OpenAI 密钥),以及栈中接触过的 TLS 材料。三次 API 调用就足以复现可控的信息泄露。

为何重要

对运营 LLM 基础设施的团队,有三点需要警示。

第一点最显而易见:“本地”LLM 运行时的攻击面比团队想象的要广得多。Ollama 常被以开发者工具的心智模型部署,但实际上它是一个网络可达的推理服务器,只要有用户与之对话,就处理着机密信息和 PII。2026 年 5 月外部研究人员的扫描发现,自托管 AI 基础设施中相当一部分在公网上无认证暴露。Bleeding Llama 是内存泄露侧的实例,但同样的部署姿态也是 CVE-2026-33626(LMDeploy SSRF)和 CVE-2026-42208(LiteLLM SQLi)在披露数小时内即被大规模利用的原因。

第二点是静默补丁问题。修复于 2 月 25 日随 v0.17.1 发布,发布说明并未标注为安全更新。CVE 直到 4 月 28 日才发布。在长达七十天的时间里,使用漏洞扫描器或补丁管理工具的运维人员既没有可匹配的 CVE,也没有提示他们升级的严重等级信号。这一模式并非 Ollama 独有——许多 AI 框架缺乏安全建议发布流程,MITRE 多个 CNA 在过去一年中存在积压滑点。如果您的 AI 资产清单依赖 CVE 源来触发打补丁,那您在 AI 基础设施上结构性地滞后。

第三点是 GGUF 供应链含义。模型文件如今相当于可执行制品——它们在服务端驱动复杂的解析逻辑。把它们当作惰性数据是错误的。任何从外部来源(Hugging Face 下载、镜像模型注册表、用户上传的微调权重)摄取 GGUF 文件的流水线,都暴露在消费方的解析漏洞之下。Bleeding Llama 是一个,几乎可以肯定不会是最后一个。

防御

**升级到 Ollama v0.17.1 或更高版本。**这是底层解析器缺陷的唯一修复。旧版本无法安全地原地打补丁,因为边界检查在整个 GGUF 和量化代码路径上都需要添加。

**审计您的绑定地址和认证。**如果您的 Ollama 运行在 OLLAMA_HOST=0.0.0.0 或公共负载均衡器之后,请将其视为暴露的服务。绑定到 127.0.0.1,通过 SSH 或 VPN 访问,或在前端放置一个对 /api/create 和 /api/push 强制认证和限速的反向代理。runZero 的建议文档列出了您可以用于发现自有暴露实例的查询。

**在网络层面将 LLM 运行时与机密信息隔离。**堆泄漏只能外传进程接触到的内容。不要通过暴露在公网的推理服务器的环境变量传递生产云凭证、第三方 API 密钥或 PII。使用具有严格 IAM 角色范围的 sidecar,或按需分发短期令牌的机密代理。这与限制同一 AI 框架家族中 SSRF 和 RCE 爆炸半径的原则相同。

**将 GGUF 视为不可信输入。**如果您的流水线从任何非端到端可控的来源拉取模型文件,请在进程外验证文件头——例如在沙箱二进制中解析元数据,并拒绝声明的张量范围与文件长度不匹配的文件。多个开源权重模型注册表开始发布签名的 GGUF 清单;优先使用它们。

**订阅 AI 运行时供应商的安全建议,而不仅依赖 CVE 源。**Bleeding Llama 正是说明为何仅靠 CVE 源不够的典型案例。直接订阅 Ollama、LiteLLM、LMDeploy、vLLM 以及您推理供应商的 GitHub Security Advisories。关注其发布说明以发现静默补丁,并默认任何解析器的非平凡变更都可能与安全相关。

**采用 OWASP LLM Top 10 的供应链缓解措施。**OWASP LLM03(供应链)和 LLM07(系统提示泄露)在此直接适用。2026 年修订版现在明确将模型文件解析纳入供应链攻击面范围。

状态

项目	参考	日期	说明
CVE	CVE-2026-7482, CVSS 9.1	2026-04-28 由 Echo CNA 分配	最初于 2026-03-02 提交 MITRE;在 MITRE 无回应后由 Echo 重新分配
发现方	Cyera Research(“Bleeding Llama”)	2026 年 5 月公开披露	责任披露时间线已记录于 Cyera 建议中
补丁	Ollama v0.17.1	2026-02-25	发布说明中未做安全标记
公开披露	Cyera / The Hacker News	2026-05	确认全球超过 300,000 台暴露服务器
受影响组件	fs/ggml/gguf.go、server/quantization.go	—	量化过程中堆上越界读取
受影响版本	Ollama < 0.17.1	—	包括所有早期次要分支
OWASP 映射	LLM03(供应链)、LLM07(系统提示泄露)	2026 修订版	模型文件解析现已纳入供应链范围
相关披露	LMDeploy CVE-2026-33626(SSRF)、LiteLLM CVE-2026-42208(SQLi)、Langflow CVE-2026-33873(RCE)	2026	同一模式:未经认证的 AI 框架端点

Bleeding Llama 不是某种新颖的奇异攻击——它是一个解析器中经典的内存安全缺陷,只是被包裹在了一个 AI 专属的文件格式之外。值得标记它的,是围绕它的运营现实:运行时比开发者预期的更多暴露在网络上,补丁是静默的,CVE 来得很迟,而泄漏的字节正是 LLM 部署所积累的秘密。请把您的推理服务器当成它们已经成为的生产数据平面服务来对待。