CVE-2026-7482：Ollama GGUF 堆越界读取复现

本仓库包含我对 CVE-2026-7482 的本地复现脚本，该漏洞是易受攻击的 Ollama GGUF 加载和量化路径中的堆越界读取。

这项工作的关键结果范围很窄：我能够可靠地触发堆越界（Heap OOB）条件，并生成受越界影响的量化 GGUF 产物。我未能展示出明确的黑盒影响，例如可靠的明文密钥恢复或从产物中直接提取金丝雀（canary）字符串。

此 PoC 的功能

exp.py 创建两个 GGUF 文件：

• 一个恶意的截断 GGUF，其中包含一个张量，其声明的字节数超过文件实际包含的字节数；
• 一个具有相同声明张量形状的全零填充对照 GGUF。

它通过本地 Ollama API 将两个文件上传到易受攻击的 Ollama 实例，使用 /api/create 触发量化，从本地 Docker 容器中复制生成的 GGUF blob，并将恶意输出与零对照输出进行比较。

这种差分比较很有用，因为它表明易受攻击的量化路径使用了原始恶意 GGUF 文件中不存在的字节。在我的测试中，此行为在 Ollama 0.17.0 上稳定复现，并被修复后的 0.17.1 路径拒绝。

要求

• 安装了 requests 的 Python 3
• 对易受攻击的 Ollama 容器的 Docker 访问权限
• 在本地 API 端口上暴露的 Ollama 0.17.0
• 一个易受攻击的测试容器名称，例如 ollama-old-test

示例实验目标：

docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0

使用方法

安装唯一的 Python 依赖：

python3 -m pip install requests

针对 http://localhost:11435 和容器 ollama-old-test 运行默认测试：

python3 exp.py

显式参数：

python3 exp.py http://localhost:11435 ollama-old-test Q4_K_M F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F16
python3 exp.py http://localhost:11435 ollama-old-test Q8_0 F32

该脚本会写入本地产物，例如：

• malicious_model.gguf
• control_model.gguf
• quantized_model.gguf
• control_quantized_model.gguf
• q8_dequantized_f32.bin
• q8_pseudo_f16.bin
• q8_pseudo_f16.txt

发现

在我的本地测试中，易受攻击的 Ollama 版本创建的量化输出中，恶意张量载荷与零对照张量不同，尽管恶意 GGUF 文件并不包含这些字节。

这足以证明存在受越界影响的产物，但不足以声称实现了实际的黑盒数据泄露。

我还测试了并发模型提示中的金丝雀式数据，并搜索了生成的产物、Q8_0 反量化的 float32 字节以及伪 F16 重建输出。我未能恢复精确的金丝雀字符串或有意义的明文片段。

可能的原因是这些字节并非作为原始堆内存被直接复制出来。它们会经过模型转换和量化流水线：

堆字节 -> 被解释为 F16/F32 张量值 -> 转换/量化 -> GGUF 张量输出

这条路径是有损的，尤其是对于 Q4_K_M 等量化格式。Q8_0 比 Q4_K_M 保留了更多的数值信息，但在我的黑盒式测试中，它仍然未能产生可靠的明文恢复。

范围与限制

这是一个本地实验复现和产物分析辅助工具。

它不提供可靠的远程机密外泄原语。它还需要本地 Docker 访问权限来从测试容器中复制 Ollama 生成的 blob，因此分析步骤并非纯粹的远程黑盒工作流。

我的测试得出的实际结论是：

• 堆越界行为可复现。
• 受越界影响的量化产物可观察。
• 未证明明确的黑盒明文影响。

参考

• NVD 条目：https://nvd.nist.gov/vuln/detail/CVE-2026-7482
• Ollama 修复提交：https://github.com/ollama/ollama/commit/88d57d0483cca907e0b23a968c83627a20b21047

相关工作

还有一个由 0x0OZ 提供的独立 PoC 仓库：

https://github.com/0x0OZ/CVE-2026-7482-PoC

该实现通过将生成的模型产物推送到受控注册表，展示了更强的白盒式工作流。借助我 PR 中的注册表上传流程修复，它可以在我的本地实验中干净地完成：

https://github.com/0x0OZ/CVE-2026-7482-PoC/pull/1

即使有了更好的端到端产物收集路径，同样的数据质量警告仍然重要：输出是量化/模型转换后的数据，而非直接的原始堆转储。

免责声明

本仓库仅用于授权的漏洞研究和防御性复现。仅对您拥有或获得明确评估许可的系统进行测试。