CVE-2026-7482 "Bleeding Llama"：Ollama严重内存泄露漏洞，30万台AI服务器裸奔在公网
Ollama曝出CVSS 9.1严重漏洞，攻击者仅需3次API调用即可泄露服务器全部进程内存，包括API密钥、用户对话和云凭据。全球约30万台暴露在公网的Ollama实例面临即刻威胁。
漏洞概述：AI推理引擎的致命内存泄露
2026年6月，安全研究机构Cyera披露了一个影响Ollama的严重漏洞，编号CVE-2026-7482，被命名为"Bleeding Llama"（流血的羊驼）。该漏洞的CVSS基础评分为9.1，属于"严重"级别，漏洞类型为堆内存越界读取（Heap Out-of-Bounds Read），存在于Ollama的GGUF模型文件加载器中。
这个漏洞的可怕之处在于它的攻击成本极低。攻击者不需要任何认证，只需要3次API调用就能完成整个攻击链：上传恶意构造的GGUF模型文件、触发越界读取、通过未认证的/api/push端点导出包含泄露内存数据的模型文件。整个过程可以在几秒内自动化完成。
Ollama是目前最流行的本地大语言模型推理框架之一，广泛用于开发者和企业的AI应用部署。研究人员通过Shodan等互联网扫描工具发现，约有30万台Ollama服务器将监听地址配置为0.0.0.0（即绑定所有网络接口），使其直接暴露在公网上。虽然Ollama默认绑定127.0.0.1（仅本地访问），但大量生产环境为了方便远程访问而更改了这一默认设置。
技术原理：GGUF解析器的堆越界读取
CVE-2026-7482的技术根源在于Ollama对GGUF（GGML Universal File Format）模型文件的解析逻辑。GGUF是llama.cpp生态系统使用的模型存储格式，包含模型权重张量和元数据。每个张量在文件中通过偏移量（offset）和大小（size）来定位。
攻击者构造一个恶意的GGUF文件，其中张量的声明偏移量和大小超出了实际文件边界。Ollama的加载器在解析时没有验证这些边界值，导致读取操作越过了分配的堆缓冲区，进入了相邻的堆内存区域。这些被意外读取的内存可能包含极其敏感的信息。
攻击链如下：首先，攻击者通过Ollama的模型创建API上传恶意GGUF文件；其次，Ollama在加载模型时触发越界读取，将堆内存中的敏感数据混入模型的张量数据中；最后，攻击者通过未认证的/api/push端点请求导出该模型，获得的文件中包含了泄露的内存内容。Cyera的研究报告强调，整个攻击过程"完全自动化，无需人工交互"。
| 属性 | 详情 |
|---|---|
| CVE编号 | CVE-2026-7482 |
| CVSS评分 | 9.1（严重） |
| 漏洞类型 | 堆内存越界读取（Heap OOB Read） |
| 攻击向量 | 网络远程，无需认证 |
| 受影响版本 | Ollama所有 < 0.17.1版本 |
| 修复版本 | Ollama 0.17.1（PR #14406） |
| 影响范围 | 全球约30万台公网暴露的Ollama实例 |
| PoC状态 | 已公开（GitHub多个仓库） |
泄露内容：你最不想被看到的数据
通过Bleeding Llama漏洞泄露的堆内存可能包含以下敏感数据类型：
用户对话历史：Ollama进程内存中保存着最近的推理请求和响应，包括用户的提示词（prompt）和模型的输出。这些对话可能包含商业机密、个人隐私或敏感的技术问答。
API密钥和云凭据：许多部署场景中，Ollama与其他服务集成，相关API密钥、云平台访问令牌（AWS Access Key、Azure SAS Token等）可能驻留在进程内存中。泄露这些凭据可能导致更大范围的云环境入侵。
环境变量：通过/proc/self/environ或类似机制加载的环境变量通常包含配置密钥、数据库连接字符串等敏感信息。堆内存中可能残留这些数据的副本。
工具输出和系统信息：如果Ollama配置了工具调用（Tool Calling）功能，工具的执行结果和系统信息也可能被泄露。
这意味着一次成功的Bleeding Llama攻击不仅是一个单独的漏洞利用，更可能成为更大规模数据泄露的起点。攻击者获取API密钥后可以横向扩展到云环境，获取对话历史可以进行商业间谍或勒索。
影响范围：30万暴露服务器的真实威胁
Cyera研究人员通过互联网扫描发现，约30万台Ollama服务器配置了OLLAMA_HOST=0.0.0.0，使其监听在所有网络接口上，可从公网直接访问。这个数字令人震惊——这意味着全球有数十万台AI推理服务器在没有任何认证保护的情况下暴露在互联网上。
这些暴露的服务器主要分布在以下场景：云服务器上的开发者个人部署（占比较高）、企业用于内部AI服务但错误配置了网络绑定、Docker容器部署时未正确设置网络隔离、以及部分AI服务提供商的测试环境。从地理分布来看，美国、中国、德国和日本是暴露数量最多的国家。
# 检查本地Ollama是否暴露在公网
ss -tlnp | grep 11434
# 如果显示 0.0.0.0:11434 则存在风险
# 如果显示 127.0.0.1:11434 则仅本地访问
# 检查Ollama版本（需要 >= 0.17.1）
ollama --version
# 快速检测本地是否存在漏洞
curl -s http://localhost:11434/api/push -X POST \
-d '{"name":"test:latest"}' | head -c 200
# 如果返回非404/403响应，说明端点未受保护
# 检查Ollama进程的内存使用
ps aux | grep ollama | grep -v grep
cat /proc/$(pgrep ollama)/smaps_rollup 2>/dev/null | head -10
PoC已公开：攻击门槛降至脚本小子级别
目前GitHub上已出现多个CVE-2026-7482的PoC（概念验证）代码仓库，包括szybnev/CVE-2026-7482、0x0OZ/CVE-2026-7482-PoC和msuiche/gguf_cve2026_7482。这些PoC的公开意味着攻击门槛已经从"高级攻击者"降至"脚本小子"水平。
安全社区普遍认为，鉴于PoC的公开和漏洞利用的简易性，应该假设该漏洞正在被积极利用。对于暴露在公网的30万台Ollama服务器，大规模自动化扫描和利用只是时间问题。部分安全研究人员已经报告观察到针对Ollama端口（11434）的异常扫描活动增加。
# 安全团队可使用的检测脚本（仅用于自查）
# 检查Ollama是否在公网暴露且未认证
import requests
import sys
def check_exposure(host, port=11434):
"""检测Ollama实例是否暴露在公网且未认证"""
try:
# 尝试访问版本信息（不应需要认证）
r = requests.get(f"http://{host}:{port}/api/version", timeout=5)
if r.status_code == 200:
version = r.json().get("version", "unknown")
print(f"[!] 暴露的Ollama实例: {host}:{port}")
print(f" 版本: {version}")
# 检查push端点是否可访问
r2 = requests.post(f"http://{host}:{port}/api/push",
json={"name":"test"}, timeout=5)
if r2.status_code != 403:
print(f" [CRITICAL] /api/push 端点未认证!")
return True
except:
pass
return False
if __name__ == "__main__":
target = sys.argv[1] if len(sys.argv) > 1 else "127.0.0.1"
check_exposure(target)
修复方案：从紧急补丁到长期防护
Cyera在报告中提供了明确的修复方案，Ollama团队已通过PR #14406在v0.17.1版本中修复了该漏洞：
# 方案1：升级到修复版本（推荐）
# 停止当前Ollama服务
sudo systemctl stop ollama
# 下载并安装最新版本
curl -fsSL https://ollama.com/install.sh | sh
# 验证版本
ollama --version
# 应显示 0.17.1 或更高
# 重启服务
sudo systemctl start ollama
# 方案2：临时缓解 - 绑定到本地地址
# 编辑Ollama服务配置
sudo systemctl edit ollama
# 添加以下内容：
# [Service]
# Environment="OLLAMA_HOST=127.0.0.1"
sudo systemctl daemon-reload
sudo systemctl restart ollama
# 方案3：使用nginx反向代理添加认证
# /etc/nginx/conf.d/ollama-proxy.conf
cat > /etc/nginx/conf.d/ollama-proxy.conf << 'EOF'
server {
listen 8080;
server_name ollama.internal;
location / {
# 基本认证
auth_basic "Ollama Access";
auth_basic_user_file /etc/nginx/.htpasswd;
# 仅允许本地代理
proxy_pass http://127.0.0.1:11434;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
# 阻止模型创建和推送端点
location /api/push {
return 403;
}
location /api/create {
return 403;
}
}
EOF
sudo nginx -t && sudo systemctl reload nginx
| 修复方案 | 优先级 | 安全性 | 兼容性影响 |
|---|---|---|---|
| 升级到v0.17.1 | P0-最高 | 修复根因 | 无 |
| 绑定127.0.0.1 | P0-紧急 | 阻断远程访问 | 远程客户端无法连接 |
| Nginx反向代理+认证 | P1-高 | 增加认证层 | 需要配置客户端 |
| 防火墙限制端口 | P1-高 | 网络层防护 | 无 |
AI安全的新战场：推理框架成为攻击目标
CVE-2026-7482标志着AI安全威胁的一个新阶段。过去安全社区主要关注模型本身的对抗攻击（如提示注入、越狱），而Bleeding Llama证明AI推理基础设施同样面临传统的内存安全威胁。
Ollama使用Go语言编写，但其底层依赖的llama.cpp是C/C++代码，GGUF解析器中的内存操作天然存在缓冲区溢出、越界读写等风险。这与传统软件中的内存安全漏洞无异，只是攻击面从Web服务器、数据库转移到了AI推理引擎。
对于企业而言，这意味着AI基础设施的安全审计需要纳入传统的漏洞扫描和渗透测试范畴。仅仅关注模型安全（Model Security）是不够的，推理框架、模型服务API、GPU驱动等底层组件同样需要系统性的安全评估。
数据来源
- Cyera安全研究报告：cyera.com/research/bleeding-llama
- Ollama修复PR #14406：github.com/ollama/ollama/pull/14406
- NVD漏洞详情：nvd.nist.gov/vuln/detail/CVE-2026-7482
- PoC代码仓库：GitHub - szybnev/CVE-2026-7482, 0x0OZ/CVE-2026-7482-PoC
- Google TAG零日利用年度报告：blog.google
评论