---
title: "Bleeding Llama: Unauthenticated Memory Leak in Ollama"
url: https://erroneo.us/security/briefs/bleeding-llama-ollama-memory-leak-cve-2026-7482/
description: "Ollama before 0.17.1 leaks process memory (prompts, env secrets) to anyone who can reach its API (CVE-2026-7482). Exposed servers: update and rotate."
type: security-brief
section: "Security Digest"
date_published: 2026-05-02
date_modified: 2026-10-21
publisher: erroneo.us
author: erroneo.us Security Desk
verdict: "Check exposure"
cves: ["CVE-2026-7482"]
severity: "critical"
exploited: "none-known"
kev: false
license: All rights reserved. Quote with attribution and a link.
---

# Bleeding Llama: Unauthenticated Memory Leak in Ollama

**Verdict: Check exposure.** A laptop running Ollama on its default localhost binding is not reachable; a server you exposed with OLLAMA_HOST=0.0.0.0 or a published Docker port is, and it should be updated and its secrets rotated.

- **Who must act:** Anyone running Ollama older than 0.17.1 with port 11434 reachable from the internet, a shared LAN, or other tenants.
- **Who can relax:** Desktop users on the default 127.0.0.1 binding who auto-update, and anyone already on 0.17.1 or later.
- **Affected:** Ollama before 0.17.1
- **Fixed:** Ollama 0.17.1
- **CVEs:** CVE-2026-7482
- **CISA KEV:** no · **Exploitation:** No known exploitation

## What to do

1. Check the version with ollama --version (or GET /api/version) and update to 0.17.1 or later
2. Find exposed instances: confirm port 11434 is not reachable from outside (ss -ltnp | grep 11434; external scan)
3. Bind to 127.0.0.1 or put an authenticating reverse proxy or API gateway in front; Ollama has no built-in auth
4. If an instance was reachable while vulnerable, rotate API keys and tokens in its environment and treat recent prompts as disclosed
5. Block outbound pushes to arbitrary registries from inference hosts where possible

### How to check if you are affected

- Review access logs for sequences of POST /api/blobs, /api/create and /api/push from unfamiliar clients
- List models (ollama list) for unexpected models, especially names that point at external registry hosts
- Check egress logs for uploads from the Ollama host to unknown registry domains

## What happened

On May 2, 2026, Cyera published ["Bleeding Llama,"](https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama) a heap out-of-bounds read in Ollama, the popular local LLM runner. It is tracked as [CVE-2026-7482](https://www.cve.org/CVERecord?id=CVE-2026-7482) (CVSS 3.1 score 9.1 from the CNA, Echo).

According to the CVE record, the `/api/create` endpoint accepts an attacker-supplied GGUF model file whose declared tensor offset and size exceed the file's real length. During quantization, the server reads past the heap buffer. The leaked memory lands in the resulting model file, and the attacker can push that model to a server they control through `/api/push`. The CVE record says the leak may include:

- environment variables and API keys
- system prompts
- other users' concurrent conversation data

[CSO Online](https://www.csoonline.com/article/4168584/ollama-vulnerability-highlights-danger-of-ai-frameworks-with-unrestricted-access.html) reports that the exploit needs only three API requests and no authentication.

## Who is affected

All Ollama versions before 0.17.1 are affected. The fix is [PR #14406](https://github.com/ollama/ollama/pull/14406) ("ggml: ensure tensor size is valid"), merged February 25, 2026, which checks that quantized tensor sizes match their declared shape. It shipped in [v0.17.1](https://github.com/ollama/ollama/releases/tag/v0.17.1), whose release notes do not mention a security fix. Nothing in the changelog would have prompted an urgent upgrade.

The patch shipped more than two months before public disclosure. Cyera's timeline: reported February 2, fix PR shared February 25, CVE requested from MITRE March 2, then assigned April 28 by the third-party CNA Echo. Cyera gives the CVE publication date as May 1; the CVE.org record shows May 4.

## Do you really need to act?

It depends entirely on reachability. The headline number, which Cyera and CSO put at roughly 300,000 internet-exposed Ollama servers, is real exposure. But Ollama has no built-in authentication, so those servers were already open to anyone who could use, delete or pull models on them. Bleeding Llama adds the ability to read secrets and other users' prompts out of process memory.

Cyera's write-up says Ollama "listens on all interfaces (0.0.0.0) by default." Ollama's own [FAQ](https://docs.ollama.com/faq) says it "binds 127.0.0.1 port 11434 by default" and that you change this with `OLLAMA_HOST`. In practice, a default desktop install is not reachable from the network. Exposure comes from:

- setting `OLLAMA_HOST=0.0.0.0`
- publishing the Docker port
- running it on a shared GPU box for a team

Those are exactly the setups that hold shared API keys and multiple users' conversations.

As of October 21, 2026, none of the sources we reviewed report confirmed in-the-wild exploitation, and the CVE is not in [CISA KEV](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json). Still, the bug takes three unauthenticated requests, and the exposed hosts are easy to find, so do not count on that staying true.

## What to do now

1. Run `ollama --version` or `curl -s localhost:11434/api/version` and update to 0.17.1 or later. Pull a fresh `ollama/ollama` image for containers.
2. Check reachability: run `ss -ltnp | grep 11434` on the host and scan it from outside your network.
3. Bind to `127.0.0.1`, or put an authenticating reverse proxy or API gateway with IP allow-lists in front of it. Never expose 11434 directly.
4. If a server was reachable while vulnerable, rotate every key in its environment and in the environment of anything sharing its process. Assume recent prompts and system prompts were disclosed.
5. Where practical, restrict egress from inference hosts so `/api/push` cannot reach arbitrary registries.

## How to tell if you were hit

The exploit leaves a distinctive sequence: an upload to `/api/blobs`, then `/api/create` with a model name that points at an external host, then `/api/push`. Look for that pattern from unfamiliar IPs in proxy or server logs. Also check `ollama list` for models you did not create, and look at egress logs for uploads to unknown registry domains. Ollama's default logging is thin, so missing evidence is not proof of safety on an exposed host.

## Timeline

- Feb 2, 2026: Cyera reports the flaw to Ollama.
- Feb 25, 2026: Fix PR #14406 merged; v0.17.1 released around this date.
- Apr 28, 2026: Echo assigns CVE-2026-7482.
- May 2, 2026: Cyera publishes "Bleeding Llama."
- May 7, 2026: Wider press coverage of about 300,000 exposed servers.

## Sources

1. [CVE.org — CVE-2026-7482 record](https://www.cve.org/CVERecord?id=CVE-2026-7482)
2. [Ollama (GitHub) — PR #14406: ggml: ensure tensor size is valid](https://github.com/ollama/ollama/pull/14406)
3. [Ollama (GitHub) — Release v0.17.1](https://github.com/ollama/ollama/releases/tag/v0.17.1)
4. [Cyera Research — Bleeding Llama: critical unauthenticated memory leak in Ollama](https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama)
5. [Ollama docs — FAQ: how do I configure Ollama server / bind address](https://docs.ollama.com/faq)
6. [CISA — Known Exploited Vulnerabilities catalog (JSON feed, checked 2026-10-21)](https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json)
7. [CSO Online — Ollama vulnerability highlights danger of AI frameworks with unrestricted access](https://www.csoonline.com/article/4168584/ollama-vulnerability-highlights-danger-of-ai-frameworks-with-unrestricted-access.html)

---
Source page: https://erroneo.us/security/briefs/bleeding-llama-ollama-memory-leak-cve-2026-7482/ · Security Digest: https://erroneo.us/security/ · More: https://erroneo.us/llms.txt