szybnev/CVE-2026-7482

# CVE-2026-7482：Ollama GGUF 堆越界读取复现 本仓库包含了我针对 CVE-2026-7482 的本地复现脚本，该漏洞是在存在缺陷的 Ollama GGUF 加载和量化路径中存在的堆越界读取问题。 这项工作的重要结论范围很窄：我能够使堆越界条件稳定复现，并生成受越界读取影响的量化 GGUF 文件。但我无法证明明确的黑盒影响，例如稳定地恢复明文秘密或从生成的文件中直接提取金丝雀字符串（canary strings）。 ## 此 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 重建输出。我未能恢复出确切的金丝雀字符串或有意义的明文片段。 可能的原因是这些字节并没有作为原始堆内存被复制出来。它们经过了模型转换和量化 pipeline： ``` heap bytes -> interpreted as F16/F32 tensor values -> converted/quantized -> GGUF tensor output ``` 这个路径是有损的，特别是在 `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 该实现通过将生成的模型文件推送到受控的 registry，演示了一个更强的白盒风格工作流。借助我 PR 中关于 registry 上传流程的修复，它在我的本地实验室环境中顺利运行： https://github.com/0x0OZ/CVE-2026-7482-PoC/pull/1 即使有了更好的端到端文件收集路径，同样的数据质量注意事项依然重要：输出是经过量化/模型转换的数据，而不是直接的原始堆转储。 ## 免责声明 本仓库仅供授权的漏洞研究和防御性复现使用。请仅针对您拥有所有权或获得明确授权进行测试的系统进行测试。

标签：AI安全, Chat Copilot, CISA项目, CVE-2026-7482, Docker, GGUF, Heap OOB read, LLM, LLM评估, Ollama, PoC, Python, requests, Torch, Unmanaged PE, XXE攻击, 二进制安全, 代码安全, 内存安全, 堆越界读取, 大模型安全, 安全防御评估, 差异对比, 无后门, 暴力破解, 本地API, 模型文件解析, 模型量化路径, 漏洞分析, 漏洞复现, 漏洞枚举, 请求拦截, 越界读取, 路径探测, 量化, 黑盒影响分析