AIDEFEND in Action AIA-0093 Validated Research Published: Oct 1, 2026

Bleeding Llama: Ollama GGUF Heap Read and Model Push

Cyera demonstrated that a crafted GGUF tensor size could make Ollama before 0.17.1 read beyond its heap buffer during F16-to-F32 conversion in /api/create; the flaw is tracked as CVE-2026-7482, a public vulnerability identifier. The leaked bytes were written into a model artifact and could be sent to an attacker registry through /api/push. Network exploitation requires an exposed API: the upstream Ollama binary defaults to 127.0.0.1, the official container image sets OLLAMA_HOST to 0.0.0.0, and operators can change the bind address themselves.

Privacy LeakageTool AuthorizationRuntime IsolationAI Infrastructure
8 applicable AIDEFEND defenses
Source: Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama 
Author: Dor Attias
Original article: May 5, 2026

Threat Analysis

The GGUF model-creation API crossed two boundaries: it trusted a tensor's declared size during F16-to-F32 conversion, then allowed the resulting artifact to be pushed outward. The read was a product memory-safety bug, while the unauthenticated management API made it remotely reachable where operators exposed Ollama.

  1. The attacker must reach /api/blobs, /api/create and /api/push through non-default network exposure or an allowed local route; upstream defaults to loopback.
  2. A GGUF tensor declares more elements than its actual data buffer contains and is uploaded to /api/blobs.
  3. The attacker creates a model from the blob and requests F32 output; the vulnerable conversion reads past the heap allocation and writes neighboring bytes into the new model.
  4. The model is named for an attacker-controlled registry and /api/push uploads the resulting artifact, which may contain prompts or other process memory from the test.

Ollama upstream defaults to 127.0.0.1, not 0.0.0.0. Cyera demonstrated the chain in a controlled environment; neither a generic exposed endpoint nor this CVE alone establishes a real victim's secrets were stolen.

Applicable AIDEFEND Defenses (8)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Rebuild and roll out Ollama 0.17.1 or later through staged deployment, then independently read back the running version and image digest on every applicable instance; this removes the vulnerable GGUF conversion path.
AID-H-038.001
Inference Runtime Listener & Protocol Conformance
Very High
For native Ollama, bind to the documented loopback address and independently enumerate actual process listeners after startup. For Docker, verify container listeners, Docker publish bindings, bridge reachability and effective NAT/firewall rules; ss alone can miss NAT publication. In Kubernetes include Services, endpoints and pod/network-policy reachability. Reject undeclared paths and reproduce allowed and denied connectivity from the actual caller populations. An internal container bind of 0.0.0.0 neither proves public exposure nor proves privacy; loopback restricts direct remote reachability but does not repair the parser.
AID-H-038.002
Inference Runtime Privileged Operation Authorization
Very High
Inventory every exact HTTP method and canonical route and classify inference, health and privileged management operations. The only gateway to Ollama authenticates callers, default-denies unknown routes and requires separate operator authority for upload, create, push, pull, delete and copy. Use an explicit reviewed inference allowlist rather than forwarding /v1/* wholesale. Independently test alternate routes and direct backend paths and verify no denied operation changes model state.
AID-H-004.002
Service & API Authentication
High
Put a short-lived-key or workload-identity authenticating gateway in front of Ollama, and make the backend reachable only from that gateway. A native host may use loopback; for Docker or Kubernetes, verify port publishing, service routing and network policy rather than assuming the official image's internal 0.0.0.0 listener is private. Authentication identifies callers; the separate operation gate decides whether they may create or push models.
AID-I-002.001
Internal AI Network Segmentation
High
When Ollama has to listen on a non-loopback interface, place it in a security group or NetworkPolicy that accepts port 11434 only from the application gateway or the specific hosts that load models, and denies every other source. The attacker's three API calls then never reach the process from the internet or from other workloads, and the exposed-instance population the inventory step finds shrinks to the approved caller set.
AID-I-002.002
Secure External AI Service Connectivity
High
Default-deny outbound connections from the Ollama host or pod, and permit only a controlled pull-only mirror or explicitly approved destinations. This blocks pushes to unapproved external hosts. If the public Ollama registry remains reachable, a push into an attacker-controlled namespace there may still succeed; host-level destination filtering alone does not prevent that path and a separate operation gate must deny unauthorized `/api/push` calls.
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
Medium
From an authorized external vantage point, attempt the complete declared host/port population, including configured nonstandard ports, with bounded read-only GET /api/tags and /api/version probes. Match response shape to the versioned Ollama profile and reconcile confirmed candidates to owners and approved exposure state. Do not upload blobs, generate output or push models to identify a service, and do not treat a generic HTTP response as proof of an Ollama endpoint or whole-service authentication.
AID-M-001.006
Internal AI Endpoint & Agent-Service Discovery
Medium
Derive the scan population from IPAM, cloud and Kubernetes exports, probe private address space for port 11434 and Ollama's unauthenticated routes, and reconcile every responder to an owner and an approved exposure state. A developer container started with `-p 11434:11434` or a pod without a NetworkPolicy shows up here even though the outside-in scan (AID-M-001.005) never sees it, because the realistic exposure for the Docker image is the LAN or the VPC, not the internet.

What Defenders Should Do Now

  • Upgrade Ollama to 0.17.1 or later on every instance that may process untrusted GGUF data.
  • Inventory actual OLLAMA_HOST, reverse-proxy, Docker port-publish, same-network container, Kubernetes Service and NetworkPolicy reachability. An internal container listener does not by itself establish external exposure or isolation. Authenticate the management API and authorize exact HTTP method/path pairs for model operations.
  • Default-deny outbound connections and prefer a controlled pull-only mirror. If the public registry remains reachable, separately deny unauthorized /api/push; destination filtering alone cannot stop a push to an attacker namespace there.

1 additional consideration

Evidence and deployment boundary

Cyera demonstrated the chain in a controlled environment, and the cited sources establish no in-the-wild exploitation. The GGUF parser itself is fixed only by upgrading; the mapped authentication, listener, segmentation and egress controls bound who can reach model creation and where an artifact can be sent.
Recommendation: Upgrade Ollama to 0.17.1 or later on every instance that may process untrusted GGUF data.

Conclusion

AIDEFEND  identifies separate controls for this chain: patch the GGUF parser, restrict who can reach model-management routes and deny unauthorized model pushes. Network exposure and outbound routing must be verified for the actual Docker or Kubernetes deployment.

Last updated: