Bleeding Llama

This repository is a small standalone Python proof-of-concept/reproduction kit for CVE-2026-7482 affecting Ollama GGUF handling. It contains only two files: a README describing the lab workflow and limitations, and a single executable script, exp.py, which implements the full exploit/reproduction chain. The exploit is not a generic remote RCE; it is a local-lab artifact-generation exploit for demonstrating a heap out-of-bounds read during GGUF loading and quantization in vulnerable Ollama versions before 0.17.1. The script programmatically builds a malformed GGUF file whose tensor metadata declares more data than the file actually contains, alongside a zero-filled control GGUF with the same declared tensor shape. It then submits these models to a target Ollama instance over HTTP, invokes model creation/quantization through the Ollama API, retrieves the resulting quantized blobs from the local Docker container, and compares malicious versus control outputs to show that the vulnerable path consumed bytes not present in the original malicious file. Repository structure and purpose: - README.md: documents the vulnerability, prerequisites, example Docker lab setup, usage examples, expected artifacts, findings, and limitations. It explicitly states that the author reproduced OOB-influenced artifacts but did not demonstrate reliable plaintext secret recovery. - exp.py: main exploit/reproduction script. Based on the visible code and README, it includes GGUF serialization/parsing helpers, tensor sizing/alignment logic, malicious/control model generation, HTTP interactions with Ollama, local Docker-assisted blob extraction, differential comparison of quantized tensor payloads, printable-string extraction, and optional Q8_0 reconstruction/dequantization analysis. Main capabilities observed: - Crafts malformed GGUF files with inconsistent declared tensor sizes. - Crafts matching control GGUF files for differential analysis. - Talks to a vulnerable Ollama API endpoint, including /api/create and cleanup via delete operations. - Triggers quantization in formats such as Q4_K_M and Q8_0. - Copies generated model blobs from a local Docker container for offline inspection. - Compares malicious and control tensor payloads to identify OOB influence. - Searches output artifacts for printable strings/canary fragments and performs limited reconstruction analysis. Operationally, this is best classified as an operational PoC rather than a weaponized exploit: it automates the full reproduction workflow and artifact analysis, but its payload is fixed to demonstrating OOB-read influence rather than delivering a customizable post-exploitation capability. The README also makes clear that the practical impact shown is artifact corruption/data influence, not reliable black-box secret exfiltration.

This repository is a small Python exploit chain for CVE-2026-7482 targeting Ollama versions prior to 0.17.1. It is not part of a larger exploit framework. The repository contains three code files: forge.py generates a malicious truncated GGUF model file, exploit.py delivers and triggers the exploit against a target Ollama instance, and registry.py implements a minimal rogue Docker-registry-like HTTP listener to receive exfiltrated artifacts. README.md documents the attack flow and prerequisites. The exploit capability is end-to-end heap data exfiltration. First, forge.py creates malicious.gguf using the gguf and numpy libraries. It marks the file as F16 to satisfy frontend validation, creates a tensor named token_embd.weight with an inner dimension of 256 to align with Q4_K_M quantization requirements, writes the GGUF structure, then truncates the file to leave only a small amount of tensor data. This malformed file is intended to cause the target to read beyond the allocated heap buffer during quantization. Next, exploit.py uploads the crafted blob to the target Ollama API using /api/blobs/sha256:<hash>, then calls /api/create with a Modelfile referencing malicious.gguf and requests quantization mode Q4_K_M. If successful, it calls /api/push with insecure=true so the target pushes the resulting model artifact to an attacker-controlled registry URL. The model name is constructed as <EXFIL_REGISTRY>/attacker/leak_model_<n>, making the exfiltration destination attacker-selected. Default values are TARGET_URL=http://localhost:11434 and EXFIL_REGISTRY=http://localhost, both overridable via environment variables. Finally, registry.py is a custom socket server bound to 0.0.0.0:80 that imitates enough Docker Registry behavior to receive pushed layers. It handles HEAD checks, POST upload initiation, and PATCH/PUT upload bodies, then saves received data into exfils/exfiltrated_heap_<timestamp>.gguf. It also supports Expect: 100-continue and returns Docker-Distribution-Api-Version headers to satisfy client behavior. Overall, this is an operational PoC exploit rather than a detector. It combines a malicious file payload, web/API interaction with the target, and a network listener for exfiltration. The main fingerprintable targets are the Ollama API endpoints /api/blobs/sha256:<hash>, /api/create, and /api/push, plus the rogue registry listener on TCP/80 and local artifact paths such as malicious.gguf and exfils/.