Unauthenticated Ollama memory leaks expose prompts and secrets

At a glance

What this is: This analysis covers an unauthenticated memory leak in Ollama that can expose prompts, system prompts, and environment variables from process memory.

Why it matters: It matters because AI inference platforms can become unplanned secret stores, forcing IAM, NHI, and security teams to treat runtime memory as a governed exposure surface.

By the numbers:

• Cyera says the vulnerability is CVE-2026-7482 with a CVSS 9.1 score.
• Cyera says Ollama has over 100 million downloads on Docker Hub.

Context

Ollama is a local LLM runtime, but in practice it also becomes a sensitive data processing layer because prompts, system prompts, tool outputs, and environment variables can all pass through the same process memory. When unauthenticated access can leak that memory, the governance problem is no longer just application security. It becomes a control failure around what the AI runtime is allowed to retain and expose.

Cyera's research shows how a single unauthenticated flaw can transform a local inference platform into an unintended repository for secrets and conversational context. For identity teams, the important shift is that the exposure is not limited to model output. The runtime itself can surface credentials, internal content, and operational data that would normally be governed elsewhere.

The article's starting position is atypical in scale but typical in pattern: AI systems often inherit trust assumptions from service software while handling far more sensitive data than a standard application process.

Key questions

Q: What breaks when an AI inference service can be reached without authentication?

A: Unauthenticated exposure turns the inference runtime into a disclosure surface, not just a compute service. Attackers can submit crafted inputs, trigger internal processing paths, and potentially exfiltrate data from memory or exported artifacts. In practice, authentication is only one part of the boundary. You also need to control what the service stores, transforms, and can send back out.

Q: Why do local AI deployments still create secrets risk?

A: Local deployment moves the model closer to the operator, but it does not eliminate the sensitivity of the data passing through the runtime. Prompts, tool outputs, environment variables, and embedded credentials can still be exposed if the service leaks memory or exports processed data. Governance has to cover the runtime behaviour, not just the hosting location.

Q: What are the signs that an AI runtime is leaking sensitive data?

A: Warning signs include model import or conversion code that trusts user-controlled tensor shapes, export paths that can be redirected to arbitrary destinations, and services that accept unauthenticated requests on public interfaces. If prompts, system prompts, or environment variables appear in generated artifacts, the runtime is already crossing governance boundaries. That is a control failure, not a logging problem.

Q: How should teams decide whether to use self-hosted AI services for sensitive workloads?

A: Use self-hosted AI only when you can govern the full path from input to memory to output. That means authentication, strict file validation, constrained egress, and a clear rule for whether prompts and tool outputs may contain secrets. If those controls are not enforceable, self-hosting simply relocates the risk instead of reducing it.

Technical breakdown

How Ollama's create and push flow exposes process memory

Ollama's vulnerable path begins when a user submits a crafted GGUF file through model creation. The file's tensor metadata is trusted enough to drive conversion logic, and the code path uses unsafe memory handling during conversion to F32 before quantisation. If the tensor shape claims more elements than the buffer actually contains, the read extends past the buffer boundary and pulls adjacent heap contents into the conversion output. That output is then written into a new model file, preserving whatever was in memory at the time.

Practical implication: treat model import and conversion pipelines as data handling surfaces that need strict bounds checking, not just format validation.

Why the leak preserves prompts, system prompts, and environment variables

The key failure is that the leaked data is not destroyed during conversion. Ollama's quantisation path can convert the over-read bytes in a way that preserves their contents, especially when the attacker forces a lossless F16 to F32 path. That means the output file can contain user prompts, system prompts, and process environment variables alongside legitimate model data. The exploit works because the application copies memory it never should have read, then gives that memory a valid file wrapper.

Practical implication: validate that conversion code cannot read beyond the source buffer before any model re-encoding or export path is allowed.

How three API calls turn local inference into data exfiltration

The attacker does not need authenticated access or a complex chain. A crafted file triggers the memory read, /api/push provides the upload path, and a controlled model name lets the runtime send the resulting file to an attacker-controlled server. This is a classic example of how a local AI service can combine ingestion, processing, and exfiltration into one unintended control plane. The security boundary is not the model alone, but the whole runtime workflow around it.

Practical implication: restrict outbound model push destinations and isolate local inference services from arbitrary egress paths.

Threat narrative

Attacker objective: The attacker wants to exfiltrate sensitive conversational data and host-side secrets from Ollama process memory without needing credentials.

1. Entry occurs when an unauthenticated attacker submits a crafted GGUF file to the Ollama create endpoint.
2. Credential or secret exposure occurs when the malformed tensor metadata causes an out-of-bounds heap read that copies adjacent process memory.
3. Impact follows when the attacker pushes the generated model file to a controlled server and reverses the conversion to recover prompts, system prompts, and environment variables.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Process memory is now a governed secret store: When an AI runtime retains prompts, system prompts, and tool outputs in memory, the security model shifts from access to exposure. The problem is not just whether a user can call the API, but whether the runtime ever becomes an ambient container for sensitive content. Practitioners should treat inference memory as part of the governed secret surface, not as a passive implementation detail.

Unauthenticated AI runtime access collapses the normal boundary between application and identity control: The article shows that one exposed service can turn into a disclosure engine for both conversational data and machine-held secrets. That means local deployment does not equal lower governance demand. The same review and inventory discipline used for NHI and secrets management has to extend to AI runtimes that store or transform sensitive inputs.

Memory-safe languages do not remove identity risk when unsafe escape hatches exist: The vulnerability lives where low-level memory access bypasses higher-level safety guarantees. That matters because governance teams often assume language choice reduces operational exposure by default. The implication is that runtime trust must be validated at the process boundary, not inferred from the language ecosystem.

AI inference platforms can become unofficial secret distribution channels: Once prompts, environment variables, and tool outputs flow through the same execution path, an AI service can concentrate data that belongs to multiple control domains. That creates a cross-domain blast radius that IAM alone cannot see. Practitioners need to model these services as shared data processing nodes with identity, secrets, and network exposure all in scope.

Local deployment changes the location of risk, not the need for control: Teams often treat on-prem or self-hosted AI as safer because the model runs locally. This case shows that local systems can still leak data at internet scale when authentication, memory handling, and export paths are weak. The practical conclusion is that governance must cover the runtime, not just where the model is hosted.

What this signals

Memory exposure is the real control surface here: The important governance question is not whether the model is local, but whether the runtime can be forced to reveal sensitive content it was never meant to retain. That changes AI deployment reviews from infrastructure placement to data handling and export control.

Prompt data now belongs in the same risk conversation as secrets: Once an AI service can leak system prompts, user prompts, and environment variables, teams must treat conversational context as governed sensitive data. This is where IAM, secrets management, and AI runtime controls overlap in a way many programmes have not yet formalised.

For practitioners

• Inventory exposed AI runtimes Identify every internet-facing Ollama deployment, including test and developer instances, and record whether authentication, outbound push capability, and secrets-bearing prompts are in use.
• Disable unauthenticated model endpoints Require authentication in front of model creation, pull, and push paths, and block direct exposure of the Ollama service to the internet where possible.
• Restrict model export destinations Constrain any push workflow so models can only be uploaded to approved registries, never to arbitrary HTTP destinations supplied in the model name.
• Treat prompts as sensitive records Assume user prompts, system prompts, and tool outputs may contain secrets, then minimise what is sent into inference services and log only what is necessary.
• Test conversion paths for over-read conditions Review file parsing and quantisation code for bounds checking failures, especially where tensor dimensions determine read length from attacker-controlled metadata.

Key takeaways

• An unauthenticated AI runtime can expose far more than model output when its process memory is readable.
• This case shows that prompts, system prompts, and environment variables can all become recoverable from a single vulnerable service.
• Teams should govern AI inference services as sensitive data processors with strict authentication, validation, and egress controls.

Key terms

• AI Runtime Memory Exposure: A condition where prompts, tokens, system instructions, or other sensitive data become recoverable from process memory or exported artifacts. In AI systems, this often matters more than the model itself because the runtime can accumulate data from multiple users and workflows in one place.
• Prompt Leakage: The unintended exposure of user prompts, system prompts, or tool output from an AI runtime. In NHI terms, prompt leakage matters because those strings often carry sensitive instructions, credentials, or business context, and they may be stored in memory, logs, or exported artifacts.
• Unauthenticated Api Exposure: Unauthenticated API exposure is an interface that can be reached without proving identity first. It occurs when endpoints, methods, or data are accessible without valid authentication controls, allowing anonymous requests to read, modify, or trigger functions. This creates attack surface for data theft, abuse, enumeration, and unauthorized automation.
• Conversion Path Over-read: A memory safety failure where code reads beyond the end of an input buffer during format conversion or re-encoding. In AI and machine processing pipelines, the result can be disclosure of adjacent process memory, especially when attacker-controlled metadata determines how much data is read.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.