What is CVE-2026-7482 (Bleeding Llama)?

Bleeding Llama is a heap out-of-bounds read vulnerability in Ollama's GGUF model loader. An unauthenticated attacker can send a crafted model file to the /api/create endpoint and cause the server to read and return memory contents beyond the intended buffer boundary. The result is arbitrary process memory exposure without any credentials required.

What data can an attacker extract from a vulnerable Ollama server?

Whatever happens to reside in the server's process memory at the time of the attack: user prompts, system prompts, environment variables, and any API keys or credentials held in memory by the Ollama process. In deployments where Ollama is configured with cloud provider credentials or LLM API keys in environment variables, these are directly at risk.

How do I fix this and is there a workaround?

Update Ollama to version 0.17.1 or later, which patches the GGUF model loader's bounds checking. The immediate workaround for internet-exposed instances that cannot patch immediately is to block public access to port 11434 using firewall rules or network controls. Ollama was not designed to run as a public-facing service and should only be accessible from trusted hosts.

CVE-2026-7482: Bleeding Llama Exposes 300,000 Ollama Deployments

Ollama, the most widely deployed tool for running large language models locally and self-hosted, has a critical unauthenticated memory disclosure vulnerability. CVE-2026-7482, nicknamed Bleeding Llama by the researchers who found it, scores a CVSS 9.1 and allows an attacker to dump arbitrary process memory using three API calls. No authentication required. Estimates put the number of internet-facing vulnerable instances at around 300,000.

The vulnerability is patched in Ollama 0.17.1. If you’re running Ollama and haven’t updated recently, this should move to the top of your patch list today.

What’s the Vulnerability

The bug lives in two places: Ollama’s GGUF model loader (fs/ggml/gguf.go) and the WriteTo() function in server/quantization.go. GGUF is the file format used by quantized LLMs in the local model ecosystem. When Ollama loads a model, it reads tensor metadata from the file to understand the model’s structure.

Here’s the problem. An attacker can submit a crafted GGUF file to Ollama’s /api/create endpoint with deliberately manipulated tensor offsets. The loader reads these offsets and uses them to calculate where to read data from during the quantization pass. With malicious offset values, the WriteTo() function reads past the actual heap buffer into adjacent memory regions. That adjacent memory goes back to the attacker as part of the API response.

The attack is repeatable. An attacker can make multiple requests with different offset manipulations to systematically extract memory contents from the running process. Researchers at Cyera described the read as yielding “arbitrary memory segments from the server process” across successive requests.

What Gets Exposed

Process memory in a running Ollama instance contains whatever was loaded or computed during operation. That typically includes:

User prompts and system prompts from recent or in-progress inference requests
Environment variables, including any API keys or credentials passed to the Ollama process at startup
Internal data structures from model inference

The environment variable exposure is the most immediately damaging angle. Many Ollama deployments are configured with OPENAI_API_KEY, ANTHROPIC_API_KEY, or cloud provider credentials so they can route to hosted models or access cloud storage. These land in the process’s environment and stay there. An attacker using CVE-2026-7482 against such a deployment can pull those keys directly from memory.

The prompt exposure is also significant for any deployment handling sensitive conversations. Legal, healthcare, financial advisory, and similar use cases where user queries contain confidential information are particularly exposed.

300,000 Exposed Instances

Ollama was built as a local-first tool. The server listens on port 11434 and the project’s documentation treats localhost access as the assumed deployment model. But real-world usage doesn’t match that design intent. Shodan scans and similar internet enumeration tools have consistently found substantial numbers of Ollama instances with port 11434 open to the internet.

The 300,000 figure comes from Cyera’s analysis of exposed instances. Some portion of those will be intentional (developers building demos, internal tools without proper network controls) and some will be accidental (cloud VM deployments where the default security group settings weren’t tightened). Either way, they’re reachable and vulnerable.

There’s a compounding factor here: Ollama instances are often tied to sensitive AI workflows. They’re not idle servers. They’re running models on real data, from real users, and they frequently have credentials in environment for cloud integrations. The exposure profile per compromised instance is higher than a generic web server.

The Broader Pattern

This is the second critical unauthenticated vulnerability in Ollama in 2026 (the previous one, an SSRF flaw, was documented earlier this year). The pattern isn’t unique to Ollama. The local and self-hosted AI deployment ecosystem grew extremely fast, with tools prioritising ease of setup over security hardening. Default configurations typically lack authentication, rate limiting, and network binding restrictions.

The NadMesh botnet, disclosed this week, explicitly lists Ollama port 11434 as a priority target in its scanning configuration alongside ComfyUI, Gradio, Langflow, and n8n. Opportunistic mass exploitation of exposed AI services is now industrialised.

Remediation

Update to Ollama 0.17.1. The patch adds proper bounds validation in the GGUF tensor offset processing, preventing the out-of-bounds read. Check your installed version with ollama --version.

Restrict network access. Ollama should not be internet-facing. Bind it to localhost (OLLAMA_HOST=127.0.0.1) or a private network interface. If you need remote access, put it behind a VPN or authenticated reverse proxy.

Rotate credentials. If your Ollama instance was internet-exposed and running with API keys in environment variables, rotate those keys now. Assume exposure.

Audit your deployment. Check whether port 11434 is exposed externally with a scan from outside your network, or verify your cloud provider’s security group/firewall rules include an explicit deny for this port from external sources.