Cyera Disclosed CVE-2026-7482 on May 5. Ollama, the Open-Source Platform With 170,000 GitHub Stars and 100 Million Docker Pulls That Most Enterprises Use to Run LLMs Locally, Has a Pre-Auth Heap Memory Leak. Three API Calls Extract the Entire Process Memory. Cyera Counted 300,000 Exposed Servers on the Public Internet. Ollama Listens on 0.0.0.0 With No Authentication by Default. The Memory Contains User Prompts, System Prompts, and Environment Variables Including API Keys. Patch in 0.17.1.

HOW THE BUG WORKS

Ollama is the open-source platform most enterprises use to run large language models locally. The project has approximately 170,000 GitHub stars and over 100 million Docker Hub downloads. Ollama lets you download Llama, Mistral, Qwen, Gemma, and other open-weight models, then expose them through a local HTTP API at TCP port 11434. The standard deployment pattern is to run Ollama as a service on a server inside a corporate network, then have applications connect to it for inference. Many development teams have moved to this pattern in the past year as a privacy-preserving and cost-effective alternative to commercial LLM APIs.

The vulnerability lives in Ollama's GGUF model loader. GGUF is the standard file format for storing LLM weights. The format includes a header describing the file structure, a list of tensor metadata declaring offset and size, and the tensor data itself. When a user creates a new model in Ollama through the /api/create endpoint, the server parses an uploaded GGUF file by reading the tensor metadata and then loading the actual tensor data from disk into memory.

The bug is in the bounds checking on tensor offset and size. An attacker uploads a malicious GGUF file with a declared tensor size that is larger than the actual file content. The Ollama parser reads the declared size, then attempts to read that many bytes from the file. The Go runtime would normally panic on this kind of out-of-bounds read, but Ollama uses Go's unsafe package to perform low-level memory operations during tensor loading. The unsafe access bypasses Go's normal memory safety guarantees and reads adjacent heap memory into the buffer that gets written back as the loaded tensor.

The attacker then uses Ollama's /api/push endpoint to push the resulting model file to a registry. The pushed model file contains the leaked heap memory in its tensor section. The attacker controls the destination registry. The leaked memory arrives at the attacker's server, complete with whatever sensitive data was in the Ollama process at the time of exploitation. Three API calls. No authentication. Pre-auth memory disclosure of arbitrary depth.

WHAT THE LEAKED MEMORY CONTAINS

The substance of the vulnerability is in what the heap actually holds at the time an attacker reads it. Ollama's process memory contains everything the inference engine has touched recently, plus everything in the host environment.

Recent user prompts and conversation context. Anyone who chatted with the local LLM in the seconds or minutes before exploitation has their prompts visible. Enterprise deployments where developers, analysts, or executives use a shared internal Ollama instance for daily work generate a continuous stream of prompts that Cyera's research demonstrates can be reconstructed from leaked heap pages.

System prompts. Any custom system prompts configured on the Ollama instance, including the kinds of role-shaping instructions enterprises layer over base models, are visible. The methodology piece Atarus published on April 29 argued that prompts cannot be treated as security boundaries. Bleeding Llama is the operational demonstration of that argument. Even prompts that were never intended to be exposed, configured locally and never transmitted, become readable through a memory leak.

Environment variables. The host machine's environment variables sit in the same process address space that Ollama is reading from. This includes API keys for upstream LLM providers (OpenAI, Anthropic, Google), AWS access keys for cloud services, GitHub tokens, npm publish tokens, database connection strings, and any other secret stored as an environment variable on the host. Cyera's research demonstrated extraction of all of these from sample deployments.

Tool integrations. Many development teams connect Ollama to agentic coding tools like Claude Code, LangChain orchestrators, or custom inference pipelines. The data flowing through those integrations also flows through the Ollama process. Tool outputs, file contents, code snippets, and command results all transit through the inference path and are present in the heap at exploitation time. The PocketOS incident on April 30 showed what happens when an AI coding agent has too much authority. Bleeding Llama shows what happens when the inference platform underneath that agent leaks the data the agent is processing.

WHY 300,000 INSTANCES ARE EXPOSED

Cyera's number is large because Ollama's default configuration is not safe by default. When a user installs Ollama on a server, the default behavior is to bind the API listener to all network interfaces (0.0.0.0) on TCP port 11434. There is no authentication. There is no token requirement. Anyone who can reach the host's public IP on that port can issue API calls.

The deployment pattern that creates internet exposure is common. A developer installs Ollama on a cloud VM to test models. The VM has a public IP. The developer never explicitly opens the firewall, but the cloud provider's default firewall rules permit outbound traffic and may permit inbound traffic on common ports depending on configuration. The Ollama listener is now reachable from the internet. Cyera's Shodan-equivalent scan found approximately 300,000 such instances exposed on public IPs at the time of disclosure.

The same pattern produced the LiteLLM SQL injection exposure Atarus covered on April 29 and the LMDeploy SSRF exposure on April 25. AI infrastructure is being deployed at a pace that outruns the security review of the deployments. The deployments are happening on cloud infrastructure where the network exposure model is permissive by default. The tooling itself ships with permissive default configurations because the developers prioritize ease of getting started over secure-by-default deployment. The result is the operational reality Bleeding Llama exposes: a non-trivial fraction of every enterprise's AI inference infrastructure is exposed on the public internet without authentication, exploitable through pre-auth memory leak today.

THE TENTH INCIDENT IN FOURTEEN DAYS

Bleeding Llama is the tenth AI infrastructure incident the Atarus blog has documented in fourteen days. The MCP architectural RCE on April 21. The Mythos vendor breach on April 24. The LMDeploy SSRF exploited in 13 hours on April 25. The GlassWorm sleeper extensions on April 26. The Itron utility breach on April 27. The Microsoft Entra Agent ID privilege escalation on April 28. The LiteLLM SQL injection exploited in 36 hours on April 29. The PocketOS database wipe by an AI coding agent on April 30. The PyTorch Lightning Shai-Hulud cross-ecosystem propagation on May 1. Bleeding Llama today.

The pattern across all ten is consistent. AI infrastructure is being built and deployed at a pace that outruns the security maturity of the people building it, the platforms hosting it, and the buyers adopting it. Each incident hits a different layer of the stack. AI tooling protocols. Inference servers. Vendor access governance. Marketplaces and gateways. Identity primitives. Operational autonomy. ML training framework supply chain. Now self-hosted LLM platforms. Each layer is producing its own catalog of failures faster than defenders can absorb them.

The yesterday's Canvas thesis argued that vendor compromise produces customer exposure customers cannot directly remediate. Bleeding Llama is the same pattern at a different layer. Most enterprises did not choose Ollama directly. Their developers installed it because it was the fastest path to local model inference. The security team did not do a deployment review because the deployment looked like a developer tool, not infrastructure. The compromise affects the entire organization regardless of how the deployment originated.

INDICATORS AND TIMELINE

WHAT TO DO TODAY