Ollama bug can leak memory from exposed AI servers

A critical Ollama out-of-bounds read can leak process memory from network-exposed servers, including keys, prompts, and user data. The same report also des

2026-05-15 GIGATAP Team #security
#ollama#llm security#vulnerability

Ollama flaw can leak process memory from exposed servers

What was disclosed#

Security researchers say Ollama contains a critical out-of-bounds read vulnerability in its GGUF model loader. The issue is tracked as CVE with a CVSS score of 9.1.

The report says the flaw can let a remote, unauthenticated attacker leak data from Ollama process memory if the service is exposed to the network. The source material says the issue may affect more than 300,000 servers globally.

Ollama is a popular open-source framework for running large language models locally. That is part of the problem here. Systems like this often sit close to sensitive data, not far from it.

The bug is described as a heap out-of-bounds read in the GGUF handling path. In the reported attack path, the /api/create endpoint accepts an attacker-supplied GGUF file where declared tensor offset and size exceed the file’s actual length. During quantization, the server reads past the allocated heap buffer.

How the leak works#

The report lays out a simple three-step chain:

  • Upload a crafted GGUF file with inflated tensor values to a network-reachable Ollama server.
  • Trigger model creation through /api/create.
  • Use /api/push to exfiltrate data from memory to an attacker-controlled registry.

If that works, the leaked memory may include environment variables, API keys, system prompts, and conversation data from concurrent users. The report also notes that engineers often connect Ollama to tools such as Claude Code. In that setup, the data stored in memory may be even more sensitive, because tool outputs can flow through the Ollama server as part of normal operation.

That is the real risk here. This is not just a crash bug. It is a path to secrets.

A memory leak in an LLM serving layer can expose information that operators assume stays isolated: keys, prompts, internal instructions, and user content. In practice, those are often the exact things an attacker wants first.

Why this matters in practice#

The obvious lesson is not “LLMs are dangerous.” It is more specific than that. Exposed model-serving infrastructure should be treated like any other internet-facing service that handles privileged data.

The report says the REST API does not provide authentication out of the box. That matters. If an instance is reachable from the internet, the attack surface is not theoretical. It is the API.

Cyera security researcher Dor Attias is quoted in the source saying an attacker can learn “basically anything” about an organization from AI inference, including API keys, proprietary code, and customer contracts. That is blunt, but the point is fair. The memory of an inference service can become a data concentration point.

What operators should not do is treat this as a narrow model-file parsing bug with a neat boundary. The impact depends on deployment reality:

  • whether Ollama is exposed to the network
  • whether it sits behind a firewall or authentication proxy
  • whether it handles secrets in environment variables
  • whether other tools feed sensitive outputs into the same process

If the answer to any of those is yes, the risk goes up.

The Windows updater issue adds another layer#

The same source also reports two unpatched flaws in Ollama’s Windows update mechanism. These are separate from the memory leak, but they matter because they show a second class of exposure: update trust.

According to the report, the Windows desktop client auto-starts on login, listens on 127.0.0.1:11434, and polls for updates in the background through /api/update. Researchers say one flaw is a missing signature check on the update binary. The other is a path traversal issue in how the updater builds a local staging path from HTTP response headers.

The practical result, if an attacker can influence update responses, is arbitrary code execution during the update flow. The report says the attack may be possible if the attacker can control an update server reachable by the victim’s client. It also says attackers may be able to point OLLAMA_UPDATE_URL at a local plain-HTTP server. AutoUpdateEnabled is described as the default setting.

The source distinguishes two outcomes here:

  • missing signature verification alone can lead to code execution, but not persistent code execution
  • adding path traversal can let the attacker write outside the usual staging path and keep the malicious code in place

This is worth separating from the memory leak. One is a disclosure bug. The other is an execution chain. Both are operationally serious.

What operators should do now#

The source recommends a short list of defensive steps:

  • apply the latest fixes
  • limit network access to Ollama instances
  • audit deployments for internet exposure
  • place exposed instances behind a firewall
  • add an authentication proxy or API gateway in front of the REST API

That list is sensible because it addresses the real failure mode: an unauthenticated service that is assumed to be internal.

For teams running Ollama or similar local LLM infrastructure, a few checks are worth doing now:

  • confirm whether any instance is reachable from outside the expected network
  • review whether secrets are present in the runtime environment
  • check whether prompts, tool outputs, or user sessions pass through the same process
  • verify update settings on Windows clients and whether AutoUpdateEnabled is on

Do not overread the report into a claim that every Ollama deployment is compromised. That would be lazy. But do not underread it either. A critical memory disclosure in an exposed AI server is enough to justify a quick inventory.

The basic rule has not changed. If a service can see sensitive data, assume a bug in that service can reveal it.