Threat · curated 17 Jul 2026
Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak
First reported · updated · 2 reports cyera.com
Coverage timeline
Why it matters
Ollama is a widely deployed open-source framework for running LLMs locally, and this unauthenticated memory-leak flaw exposes hundreds of thousands of AI model servers to remote data theft until they are patched.
Cyera researchers disclosed CVE-2026-7482 ("Bleeding Llama", CVSS 9.1), a heap out-of-bounds read in Ollama's GGUF model loader that lets a remote, unauthenticated attacker leak the entire process memory of an Ollama server. The flaw is fixed in Ollama 0.17.1 and is estimated to affect over 300,000 exposed servers globally.
Summary
Cybersecurity researchers at Cyera disclosed CVE-2026-7482 ("Bleeding Llama"), a critical (CVSS 9.1) heap out-of-bounds read in Ollama's GGUF model loader that lets a remote, unauthenticated attacker leak the framework's entire process memory. The flaw is fixed in Ollama 0.17.1, and Ollama's REST API provides no authentication out of the box, exposing an estimated 300,000+ internet-reachable servers.[0][13]
Separately, researchers at Striga detailed two unpatched vulnerabilities (CVE-2026-42248 and CVE-2026-42249, both CVSS 7.7) in Ollama's Windows auto-update mechanism that can be chained with the on-login startup routine to achieve persistent, silent code execution at the current user's privilege level. CERT Polska is coordinating disclosure; the flaws remained unpatched at publication after a 90-day disclosure window.[0][22]
Attack chain
- Delivery: For CVE-2026-7482, the attacker uploads a crafted GGUF file with an inflated tensor shape to a network-accessible Ollama server via an HTTP POST request.[0]
- Exploitation: The attacker calls the /api/create endpoint to activate model creation, triggering the out-of-bounds heap read during quantization (WriteTo()) as the server reads past the allocated buffer.[0]
- Exfiltration: The attacker uses the /api/push endpoint to upload the resulting model artifact — containing leaked heap memory such as API keys, system prompts, and conversation data — to an attacker-controlled registry.[0]
Disclosure timeline
| Date | Event |
|---|---|
| 2026-01-27 | Striga disclosed the two Ollama Windows auto-update vulnerabilities.[0] |
| 2026-04 | CERT Polska published coordination details for CVE-2026-42248, having taken over the coordinated disclosure process.[0][22] |
| 2026-05-10 | The Hacker News published coverage of CVE-2026-7482 (Bleeding Llama) and the Striga Windows flaws, following elapse of the 90-day disclosure period for the unpatched Windows vulnerabilities.[0] |
How it works
CVE-2026-7482 stems from Ollama's use of Go's unsafe package in the WriteTo() function when creating a model from a GGUF file, which bypasses the language's memory-safety guarantees. When a GGUF file declares a tensor offset and size that exceed the file's actual length — for example a tensor shape set to a very large number — the server reads past the allocated heap buffer during quantization in fs/ggml/gguf.go and server/quantization.go, leaking adjacent process memory.[0][13]
The Windows auto-update chain combines CVE-2026-42248 (the Windows updater does not verify the update binary's signature before installation, unlike the macOS version) with CVE-2026-42249 (the updater builds the installer's staging directory path directly from HTTP response headers without sanitization). An attacker who controls the update response — for example by overriding OLLAMA_UPDATE_URL to a local plain-HTTP server with AutoUpdateEnabled on (the default) — can write an attacker-chosen executable into the Windows Startup folder that runs at every login. The missing signature check keeps the file in place because the post-write cleanup that would remove unsigned files is a no-op on Windows.[0]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| Ollama (GGUF model loader, CVE-2026-7482) | Versions before 0.17.1 | Fixed in 0.17.1[0][12] |
| Ollama for Windows (auto-update flaws CVE-2026-42248 / CVE-2026-42249) | CERT Polska: versions 0.12.10 through 0.17.5; Striga's Dmitruk: versions 0.12.10 through 0.22.0 | Unpatched at time of publication[0][22] |
Key takeaways
- Model file formats like GGUF are an untrusted input surface: a malformed tensor offset/size in an attacker-supplied file can turn a memory-unsafe (unsafe package) parsing path into a remote, unauthenticated memory-disclosure primitive.[0][13]
- Locally-run AI infrastructure inherits classic security debt — Ollama's REST API ships without authentication and its Windows updater lacks signature verification and path sanitization, so exposed instances can leak secrets or be driven to persistent code execution.[0]
- The Windows auto-update flaws (CVE-2026-42248/42249) remained unpatched after a 90-day disclosure period, so defenders must apply the interim mitigations rather than waiting for a fix.[0]
Defensive actions
- Upgrade Ollama to version 0.17.1 or later to remediate the Bleeding Llama out-of-bounds read.: CVE-2026-7482 is fixed in 0.17.1; earlier versions are vulnerable to unauthenticated remote memory leaks.[0][12]
- Restrict network access to Ollama instances, audit for internet exposure, and place them behind a firewall.: An estimated 300,000+ Ollama servers are exposed and the /api/create and /api/push endpoints are reachable by remote attackers.[0]
- Deploy an authentication proxy or API gateway in front of all Ollama instances.: Ollama's REST API provides no authentication out of the box, leaving endpoints open to unauthenticated exploitation.[0]
- On Windows, turn off automatic updates and remove any Ollama shortcut from the Startup folder (%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup).: The Windows flaws remain unpatched; disabling the silent on-login execution pathway blocks the persistent code-execution chain until the underlying flaws are fixed.[0]