Bleeding Llama: Unauthenticated Memory Leak in Ollama

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 or compromised

• 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," a heap out-of-bounds read in Ollama, the popular local LLM runner. It is tracked as 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 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 ("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, 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 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. 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.

Vulnerability records

• CVE-2026-7482 · Ollama before 0.17.1 contains a heap out-of-bounds read vulnerability in the GGUF model loader.

Sources

Original sources first: vendor and project advisories, CVE and government records, the discoverers’ write-ups. Every claim above links to one of these. See how the Security Desk works.

Original and primary sources

1. CVE.org — CVE-2026-7482 record cve.org
2. Ollama (GitHub) — PR #14406: ggml: ensure tensor size is valid github.com
3. Ollama (GitHub) — Release v0.17.1 github.com
4. Cyera Research — Bleeding Llama: critical unauthenticated memory leak in Ollama cyera.com
5. Ollama docs — FAQ: how do I configure Ollama server / bind address docs.ollama.com
6. CISA — Known Exploited Vulnerabilities catalog (JSON feed, checked 2026-10-21) cisa.gov

Coverage and analysis

1. CSO Online — Ollama vulnerability highlights danger of AI frameworks with unrestricted access csoonline.com