szybnev/cve-2026-7482Reproduces CVE-2026-7482 heap out-of-bounds read in Ollama GGUF loading and quantization, with differential analysis of quantized artifacts to demonstrate OOB influence.
This repository contains my local reproduction script for CVE-2026-7482, a heap out-of-bounds read in vulnerable Ollama GGUF loading and quantization paths.
The important result from this work is narrow: I was able to make the Heap OOB condition happen reliably and produce OOB-influenced quantized GGUF artifacts. I was not able to demonstrate a clear black-box impact such as reliable plaintext secret recovery or direct extraction of canary strings from the resulting artifact.
exp.py creates two GGUF files:
It uploads both files to a vulnerable Ollama instance through the local Ollama API, triggers quantization with /api/create, copies the generated GGUF blobs from the local Docker container, and compares the malicious output against the zero-control output.
The differential comparison is useful because it shows that the vulnerable quantization path used bytes that were not present in the original malicious GGUF file. In my tests, this behavior was stable on Ollama 0.17.0 and rejected by the fixed 0.17.1 path.
requests0.17.0 exposed on a local API portollama-old-testExample lab target:
docker run -d --name ollama-old-test -p 11435:11434 ollama/ollama:0.17.0
Install the only Python dependency:
python3 -m pip install requests
Run the default test against http://localhost:11435 and container ollama-old-test:
python3 exp.py
Explicit arguments:
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
The script writes local artifacts such as:
malicious_model.ggufcontrol_model.ggufquantized_model.ggufcontrol_quantized_model.ggufq8_dequantized_f32.binq8_pseudo_f16.binq8_pseudo_f16.txtIn my local tests, the vulnerable Ollama version created quantized outputs where the malicious tensor payload differed from a zero-control tensor despite the malicious GGUF file not containing those bytes.
That is enough to show an OOB-influenced artifact. It is not enough to claim practical black-box data disclosure.
I also tested canary-style data in concurrent model prompts and searched the generated artifacts, Q8_0 dequantized float32 bytes, and pseudo-F16 reconstruction output. I did not recover exact canaries or meaningful plaintext fragments.
The likely reason is that the bytes are not copied out as raw heap memory. They pass through the model conversion and quantization pipeline:
heap bytes -> interpreted as F16/F32 tensor values -> converted/quantized -> GGUF tensor output
This path is lossy, especially with quantized formats such as Q4_K_M. Q8_0 preserves more numeric information than Q4_K_M, but it still did not produce reliable plaintext recovery in my black-box-style tests.
This is a local lab reproduction and artifact analysis helper.
It does not provide a reliable remote secret exfiltration primitive. It also requires local Docker access to copy Ollama's generated blob from the test container, so the analysis step is not a pure remote black-box workflow.
The practical conclusion from my tests is:
There is also a separate PoC repository by 0x0OZ:
That implementation demonstrates a stronger white-box-style workflow by pushing the generated model artifact to a controlled registry. With the registry upload-flow fix from my PR, it completes cleanly in my local lab:
Even with that better end-to-end artifact collection path, the same data-quality caveat remains important: the output is quantized/model-transformed data, not a direct raw heap dump.
This repository is for authorized vulnerability research and defensive reproduction only. Test only against systems you own or have explicit permission to assess.