Unauthenticated memory leaks in local AI platforms expose NHI data

At a glance

What this is: Cyera's advisory describes a critical unauthenticated memory leak in Ollama that can expose sensitive heap data, including prompts, system messages and environment variables, through a three-call attack path.

Why it matters: IAM and security teams need to treat local AI inference endpoints as identity-bearing exposure points because unauthenticated access can leak credentials, internal prompts and regulated data without any valid user session.

By the numbers:

• CVE-2026-7482 is rated CVSS 9.1 - CRITICAL.

Context

Local AI platforms can behave like shared internal services, but they often inherit weak default trust assumptions from development tooling rather than production identity controls. In this case, an unauthenticated memory leak in Ollama turns the inference layer into an exposure point for both model inputs and host-side secrets, which is an NHI governance problem as much as a software vulnerability.

The issue matters because AI assistants and agentic tooling routinely process prompts, system instructions and environment variables in the same execution path. When the platform is network-accessible without authentication, the boundary between model interaction and secret exposure disappears, so the control question shifts from who can use the service to what data the service can leak.

Key questions

Q: What breaks when a local AI server accepts unauthenticated model uploads?

A: The trust boundary breaks because untrusted file metadata can drive memory reads beyond the intended buffer and expose heap-resident prompts, secrets and other sensitive data. When upload, creation and export share one path, the attacker can convert a parsing flaw into a disclosure channel without ever authenticating to the service.

Q: Why do AI inference servers increase the risk of cloud credential exposure?

A: Inference servers often run inside trusted cloud networks and can reach metadata endpoints, internal APIs, and other services that users cannot access directly. If the server is tricked into making outbound requests, its own workload identity becomes the entry point to credentials or internal data. Treat these services as privileged workloads with tightly scoped egress.

Q: How do security teams know if an AI workflow is too exposed?

A: Security teams should look for three signals: the assistant can read untrusted free text, it can call tools that touch sensitive systems, and its permissions exceed the narrow task it needs to complete. If those conditions overlap, the workflow is already exposed. The risk rises further when logs, tags, or comments feed back into model context.

Q: What should organisations do when an AI runtime may have exposed secrets?

A: Treat the event as potential credential compromise, rotate API keys and tokens, and review any agentic integrations or developer tooling that routed through the server. The goal is to contain both data exposure and downstream reuse of the leaked secrets before they spread to other systems.

Technical breakdown

How the Ollama memory leak exposes heap data

The flaw is an out-of-bounds heap read in the model quantization pipeline. Ollama accepts an uploaded GGUF file, then reads tensor data based on metadata supplied by that file. If the declared tensor size is larger than the actual buffer, the process reads past the intended boundary and copies adjacent heap contents into the generated model file. That makes the vulnerability an information disclosure issue, not code execution: the attacker manipulates parser assumptions to extract memory that should never have been readable through the API. The important architectural point is that file parsing, model creation and export are all part of the same trust boundary.

Practical implication: Validate external file metadata against actual buffer sizes before any inference or conversion path can touch heap memory.

Why unauthenticated inference endpoints become NHI exposure points

A local AI server is still an identity surface when it accepts unauthenticated requests, because it processes prompts, system messages and environment variables on behalf of multiple users and integrations. In this case, Ollama listens on all interfaces by default, which means the platform is reachable as a shared service unless teams deliberately front it with authentication and segmentation. The NHI dimension matters because the service can hold API keys, tokens and other secrets in its runtime environment while also serving as a conduit for developer tooling. Once the endpoint is public, an attacker does not need to steal a login to reach those assets.

Practical implication: Treat network-reachable AI runtimes as privileged non-human identities and require authentication before any request can reach model or export functions.

How the three-call exfiltration path works

The attack chain is simple because the platform combines upload, creation and push into a single workflow. First, the attacker uploads a crafted GGUF file with an inflated tensor shape. Next, model creation triggers the out-of-bounds read and pulls heap data into the resulting model artifact. Finally, the push feature sends that artifact to an attacker-controlled server, carrying the leaked memory with it. This is a classic data-exfiltration design failure: once a server can both process untrusted input and export the result, the export path becomes the exfiltration path unless it is tightly governed.

Practical implication: Restrict model push and outbound egress so untrusted content cannot be converted into a convenient exfiltration channel.

Threat narrative

Attacker objective: The attacker wants to extract sensitive heap-resident data from exposed local AI servers and exfiltrate it without needing valid credentials.

1. Entry occurs through a crafted GGUF upload sent to an unauthenticated Ollama endpoint.
2. Credential or secret exposure follows when the out-of-bounds heap read pulls prompts, environment variables and other memory into the model artifact.
3. Escalation happens when the attacker uses the built-in push function to move the tainted artifact off the host to an attacker-controlled server.
4. Impact is the disclosure of sensitive AI conversation content, host secrets and potentially regulated data from exposed instances.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.

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

Unauthenticated local AI runtimes are now NHI exposure points, not just application endpoints. The platform in this article stores prompts, system messages and environment variables in the same operational path that serves multiple users and tools. That means the service is acting as a privileged non-human identity with no effective access boundary, so the real control question is what the runtime can reveal once reached. Practitioners should treat public exposure of local AI infrastructure as a governance failure, not a mere configuration slip.

Secret hygiene collapses when AI runtimes mix inference with host context. Environment variables, tokens and proprietary code are not abstract assets once they are present in the heap of a network-reachable model server. A memory-safety flaw becomes an identity problem because the platform is allowed to touch secrets that should never be available to unauthenticated requesters. The practical implication is that AI deployment design must separate inference from sensitive runtime context instead of assuming the application layer will contain the damage.

Model push features can turn disclosure into self-service exfiltration. Export paths are often treated as operational convenience, but in this case the same path that packages model output also packages leaked memory. That creates an identity blast radius problem: one unauthenticated request chain can move sensitive data from host memory to attacker infrastructure without a separate download primitive. Practitioners should assume that any AI platform with upload, create and push functions has an exfiltration surface unless the flow is explicitly constrained.

Local AI security needs a governance model that matches production privilege, not developer convenience. Shared internal AI assistants, agentic toolchains and self-hosted inference engines all carry the same governance burden when they handle prompts and secrets. The naming of a critical CVE here should not distract from the structural issue: access, segmentation and secret handling are being treated as secondary controls around an endpoint that already holds sensitive identity data. Security teams should reclassify these platforms as managed NHI services with explicit trust boundaries.

Bleeding Llama is a good name for a broader category problem: memory leakage through trusted AI infrastructure. The concept is not limited to Ollama because any local AI platform that accepts untrusted model artifacts and can export generated output may create the same leakage pattern. The lesson for the field is that AI runtime governance must include parser safety, network reachability and egress control as a single control plane. Practitioners should expect more incidents where the model is only the delivery vehicle for the real asset at risk.

What this signals

Identity blast radius is the real control issue here. A local AI server that can read prompts, system messages and environment variables on behalf of multiple users is already operating like a privileged NHI. Once the service is unauthenticated, the question is no longer whether the model is accurate, but how far sensitive data can move before the runtime is contained.

The governance pattern that fails here is assumption-based trust in developer-facing AI infrastructure. Teams often treat self-hosted inference as less sensitive than production services, yet the moment that endpoint handles secrets and user data it needs the same network segmentation, authentication and egress restrictions as any other privileged workload.

For practitioners

• Patch exposed Ollama instances immediately Apply the vendor fix to versions prior to the patch and verify that tensor element counts are checked before any quantization loop runs.
• Remove internet exposure from local AI runtimes Place a firewall or authentication proxy in front of every Ollama deployment and block direct access to the default 11434 port.
• Inventory network-reachable AI servers Search public IP ranges and internal asset records for exposed Ollama instances so you can identify every reachable inference endpoint.
• Rotate secrets after possible runtime exposure Assume any environment variables, API keys or tokens present on an internet-accessible server may already be compromised and rotate them.
• Constrain model push and egress paths Isolate AI servers on segmented networks and limit outbound destinations so uploaded artifacts cannot be pushed to arbitrary external hosts.

Key takeaways

• Unauthenticated local AI platforms can leak far more than model output, because the runtime may hold prompts, system messages and secrets in heap memory.
• This advisory ties the risk to a critical, remotely exploitable memory flaw with broad exposure potential on internet-facing instances.
• The decisive control is to stop treating inference endpoints as convenience services and govern them as privileged NHI workloads with authentication, segmentation and secret rotation.

Key terms

• Unauthenticated Memory Leak: A vulnerability that allows a remote caller to retrieve data from memory without first proving identity. In AI platforms, this can expose prompts, system instructions, environment variables, and other runtime secrets that were never meant to leave the process boundary.
• Out-of-bounds Heap Read: A memory safety flaw where code reads past the end of an allocated heap object. In a client library, this can crash the process or expose adjacent memory if the read is later returned to the attacker, depending on the execution path and application design.
• AI Runtime Exposure Surface: The set of network paths, file inputs, and export functions through which an AI platform can reveal data. For local inference systems, this surface includes authentication status, parsing logic, model import workflows, and any outbound transfer capability.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.