Bleeding Llama: An Unauthenticated Heap Over-Read in the Ollama GGUF Quantization Path

Scope and intent. This paper analyzes a vulnerability that has been publicly disclosed by its discoverer and patched by the vendor. It describes the root cause, the exploitation chain at a conceptual level, detection logic, and remediation, so that defenders can assess and harden their deployments. It intentionally does not include a working exploit, a malicious-file generator, or a turnkey exfiltration script. All affected operators should upgrade to Ollama 0.17.1 or later before reading further.

Abstract

Ollama is the most widely deployed runtime for running large language models (LLMs) on local hardware, with on the order of 170,000 GitHub stars and 100M+ Docker Hub pulls. In early 2026, Cyera Research disclosed Bleeding Llama (CVE-2026-7482), a critical, unauthenticated out-of-bounds heap read in Ollama's GGUF model-loading and quantization pipeline.

An attacker who can reach the HTTP API can supply a crafted GGUF file whose declared tensor element count far exceeds the data actually present. During quantization, the conversion routine reads the declared number of elements from a heap buffer. It walks past the end of the real data and copies adjacent heap memory into the output model. That output is then written to disk as a new model, and it can be exfiltrated through Ollama's own model-push mechanism to an attacker-controlled registry. The leaked memory has been shown to contain user prompts, other users' system prompts, host environment variables, and secrets such as cloud credentials and API keys.

The vulnerability affects all versions prior to 0.17.1 and was fixed by adding a size-validation check to the GGUF loader. Between 175,000 and 300,000 Ollama instances are estimated to be reachable from the public internet, a direct consequence of a common OLLAMA_HOST=0.0.0.0 configuration combined with the API's lack of built-in authentication. The disclosure also matters for its timing: roughly three months separated the silent patch from CVE publication, and during that window no scanner or feed had any signal to prioritize the update.

1. Vulnerability at a glance

2. Background

2.1 Ollama and its API surface

Ollama exposes a small HTTP REST API, by default on TCP port 11434. Out of the box the listener binds to 127.0.0.1, restricting access to the local host. In practice, a common deployment pattern overrides this with OLLAMA_HOST=0.0.0.0:11434 so that IDE plugins, coworkers, other servers, or containers can share a single GPU host. The upstream REST API ships with no authentication. Once the listener is bound to a routable interface, every endpoint, including the ones implicated here, is reachable by anyone who can route to the port. This is the architectural precondition that turns a memory-safety bug into a mass-exploitable, unauthenticated data-disclosure primitive.

Two endpoints matter for this vulnerability:

• /api/create builds a model instance from previously uploaded files (or from a base pulled from a registry). File contents are first uploaded via /api/blobs/sha256:<digest>, then referenced by /api/create. The request may include a quantize parameter requesting a target numeric format.
• /api/push uploads ("pushes") a local model to a registry. As detailed below, the destination is derived from the model name, which the attacker controls.

2.2 GGUF and tensors

GGUF (GPT-Generated Unified Format) is the binary container Ollama uses to store model weights, tokenizer data, and metadata. Structurally it consists of a header (format version, tensor count, and key/value metadata such as general.file_type), followed by a list of tensor descriptors, followed by the raw tensor data. Each tensor descriptor carries the tensor's name, its number of dimensions, and its data type (precision). It also carries an offset pointing to where that tensor's data begins later in the file.

The essential property for this analysis: a tensor's shape (its per-dimension sizes) is declared in metadata, and the number of elements is simply the product of those dimensions. GGUF is a plain binary format, so anyone can author one by hand and set these fields to arbitrary values. Nothing in the format compels the declared shape to agree with the amount of data actually present.

2.3 Quantization

Quantization reduces the numeric precision of tensor values to shrink a model and speed up inference. Ollama can convert between formats such as F32 (4 bytes per value) and F16 (2 bytes per value). F32→F16 is lossy; F16→F32 is lossless (a 2-byte value widened to 4 bytes loses nothing). This asymmetry becomes the mechanism an attacker uses to keep leaked memory intact (see §4.3).

3. Why a memory-safe language did not save Ollama

Ollama's model-loading core is written in Go, which is memory-safe by default: an out-of-bounds slice access panics rather than silently reading adjacent memory. The over-read is possible because the hot path uses Go's unsafe package, the deliberate escape hatch that removes bounds guarantees for low-level performance work. The conversion routines operate on raw pointers and element counts rather than length-checked slices, so an oversized element count is honored literally instead of being rejected.

Subsequent root-cause analysis (reference 10) draws a useful contrast. The reference C++ ggml loader maintains an nbytes_remain invariant seeded from the true file length, checks every read against it, and fails cleanly at end-of-file. Ollama's Go re-implementation reads through an io.SectionReader, which silently clamps at EOF rather than erroring. When a destination buffer is pre-allocated from attacker-declared metadata and then filled by an unbounded conversion loop, the portion that could not be satisfied from the file is left holding whatever was previously resident in that heap region. The regression is therefore broader than "reads too far": the loader pre-sizes a buffer from untrusted metadata and never reconciles that size against the bytes actually available.

4. Root-cause analysis

4.1 The request path

A request to /api/create is handled by server.CreateHandler. It parses the JSON body into a known structure; the fields relevant here are the model name (model), the uploaded source files (files), and the target format (quantize). After basic sanity checks (valid name, no path traversal, files exist on disk), it dispatches to convertModelFromFiles, which recognizes the GGUF format (by extension or magic bytes) and parses the raw file into an internal Layer structure holding metadata and tensors. createModel then orchestrates the build.

Quantization runs only when three conditions hold: the caller requested a target format via quantize, the source is a GGUF, and the source format differs from the requested one. When it runs, Ollama prepares a new Layer by copying each tensor's metadata (shape, type) but not its data. It then converts each tensor by calling WriteTo() (in server/quantization.go).

4.2 The over-read

WriteTo() normalizes every tensor to F32 as an intermediate step before producing the requested output format, which keeps the number of conversion routines linear rather than quadratic. If the source is not already F32, it calls ggml.ConvertToF32(dataBuffer, sourceType, elementCount).

The third argument is the crux. It is derived from q.from.Elements(), which multiplies the tensor's declared dimensions together. That value flows straight from attacker-controlled shape metadata. ConvertToF32 dispatches to a per-type routine. For an F16 source that routine is ggml_fp16_to_fp32_row(src, dst, elementCount), which loops exactly elementCount times, reading each source element and writing the widened result into the destination buffer.

There is no validation that elementCount corresponds to the amount of tensor data actually present in the file. Declare a shape whose product is, say, one million elements while providing only a few real values, and the loop reads roughly a million elements' worth of bytes: the small slab of legitimate data, followed by whatever adjacent heap contents happen to sit beyond it. Those bytes are copied into the output buffer. This is the out-of-bounds heap read (CWE-125); the tail of the output that was never backed by file data is, from the attacker's view, uninitialized heap memory (CWE-908).

The proximate root cause, expressed as a single sentence: a length used to drive a raw memory read is taken from untrusted file metadata and never bounded against the real size of the data.

4.3 Keeping the loot readable

Raw leaked bytes are only useful if they survive the pipeline. Because most quantization targets are lossy, a naive choice would mangle the stolen memory. The discoverer's technique sidesteps this: declare the source tensor type as F16 and request F32 as the target. F16→F32 is lossless, so the widened bytes remain faithfully recoverable, and the model is already F32 after that step, which makes the "final" F32→F32 conversion a no-op. The stolen heap region therefore lands on disk byte-for-byte, and the original bytes can be reconstructed by reversing the trivial widening.

4.4 Exfiltration via the model's own name

An over-read that leaves data sitting on the victim's disk is not yet a breach. Ollama supplies the exit path itself. /api/push is handled by PushHandler → PushModel, which parses the model name; if the name is shaped like an HTTP URI, Ollama pushes the entire model artifact to that URI. Nothing validates that a model built from local files must have a registry-shaped name. An attacker can therefore create the poisoned model under a name like http://attacker.example/ns/model:tag, then call /api/push and have Ollama upload the leaked-memory-bearing artifact to their own server over Ollama's native push protocol.

The full primitive is thus a three-call, unauthenticated chain: upload the crafted blob → create/quantize to trigger the over-read → push the resulting artifact to an attacker registry. The chain requires no credentials and no user interaction, and, for defenders, it produces no crash and no error in the logs.

5. Impact

5.1 What lives in that heap

Because the over-read captures whatever is adjacent to the tensor buffer in the Ollama process heap, the disclosed content is a function of everything that process has recently touched. Demonstrated and reported categories include:

• User prompts and conversation data, including those of other, concurrent users of the same server.
• System prompts configured for models on the host, which are often proprietary and treated as confidential IP.
• Host environment variables, which in real deployments frequently include cloud credentials (e.g., AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY), provider API keys, and configuration secrets.
• Routed tool output, when Ollama sits behind agentic tooling or coding assistants. Any content that transited the process can be adjacent in the heap.

5.2 Amplification through agentic and shared deployments

Two deployment patterns sharply increase blast radius. The first is multi-tenant chat: a single shared Ollama backend serving many employees means one attacker read can surface many users' data at once. The second is agentic bridges: when Ollama is wired to coding assistants, MCP bridges, or RAG pipelines, tool results, retrieved documents, and credentials all pass through the process, which enlarges the pool of sensitive material at risk of adjacency. In both cases the vulnerability converts a "local convenience runtime" into an unauthenticated, network-reachable data-exposure surface.

5.3 Exposure at internet scale

Public-scan estimates place internet-reachable Ollama instances between roughly 175,000 and 300,000, spread across 130+ countries. The dominant contributing factor is the OLLAMA_HOST=0.0.0.0 binding paired with an unauthenticated API. Treat every such instance as a candidate target and, because the read is stealthy and log-silent, as potentially already exercised.

6. Detection and threat hunting

Because a successful attack produces neither a crash nor a logged error, detection leans on input inspection and behavioral correlation rather than crash telemetry.

6.1 Static / structural GGUF validation (the defensive invariant)

The single most reliable file-level check is the same one the patch enforces: for every tensor, confirm that its declared data footprint fits inside the file. Concretely, flag any GGUF where, for a tensor at a given offset:

tensor_offset + declared_element_count * bytes_per_element  >  actual_file_length

Equivalently, reject any tensor whose declared shape product implies more bytes than remain in the file from its offset. A single, wildly oversized tensor against an otherwise tiny payload (for example, one tensor claiming ~10^6 elements in a kilobyte-scale file) indicates a crafted exploitation attempt rather than a legitimate model. Public detection tooling that implements exactly this class of GGUF structural check exists and can be run against uploaded artifacts before they reach a vulnerable loader.

6.2 Network and request-level indicators

• /api/create requests carrying quantize=f32 on a supplied F16 source (the lossless-preservation signature), especially from untrusted or external clients.
• A /api/create followed by /api/push in close succession, particularly where the push target resolves to an external or unknown registry / raw HTTP URI rather than a legitimate registry.
• Model names shaped as HTTP(S) URIs, which have no legitimate reason to originate from an anonymous caller.
• Malformed or oversized GGUF uploads to /api/create or /api/blobs.

A reverse proxy or WAF in front of Ollama can be configured to inspect and block malformed or oversized GGUF uploads and to flag pushes toward unrecognized registries, disrupting either the trigger or the exfiltration leg of the chain.

6.3 Assume-breach posture

For any instance that was internet-reachable while unpatched, treat the environment variables and data that passed through the process as potentially disclosed. This means rotating credentials that were present in the process environment (cloud keys, provider API keys), reviewing any confidential system prompts for exposure, and considering downstream accounts reachable via those secrets as at risk.

7. Remediation

1. Upgrade to Ollama 0.17.1 or later immediately. Verify with ollama --version; for containers, pull the current image and confirm base images in build pipelines are not pinned to a vulnerable tag. Auto-scaled and Kubernetes environments should audit for stale images that reintroduce the flaw.
2. Remove public exposure. Bind to 127.0.0.1, or firewall port 11434 to trusted internal CIDRs only. There is no legitimate reason for an Ollama API to be reachable from the open internet.
3. Put authentication in front. The REST API has no built-in auth, so place a reverse proxy that enforces authentication (mTLS, an OAuth2 proxy, Cloudflare Access, Tailscale, and similar) ahead of any network-accessible instance. Treat an unauthenticated Ollama endpoint as an unauthenticated admin panel.
4. Segment. Isolate inference hosts on their own network segment; do not let a single compromised workstation pivot into the AI VLAN.
5. Rotate exposed secrets. For any instance that was reachable while unpatched, rotate credentials that lived in the process environment and audit for misuse.
6. Instrument. Forward Ollama, proxy, and firewall logs to a SIEM, and run recurring external exposure scans (for example, a periodic Shodan or self-scan for port 11434) to catch configuration drift.

8. The fix

The patch shipped in 0.17.1 as PR #14406, titled "ggml: ensure tensor size is valid." The change adds a file-size bounds check to the GGUF loader (fs/ggml/gguf.go): during model creation, a tensor whose offset plus size exceeds the underlying file length is now rejected with an error instead of being processed. The previously missing reconciliation between declared tensor size and actual available bytes is now enforced up front, closing the over-read at its source. The 0.17.1 release notes did not flag the change as a security fix, which materially delayed operator awareness (see §9).

9. Disclosure timeline and the visibility gap

The operational lesson is as important as the bug. For roughly three months, a critical unauthenticated vulnerability had a public fix but no CVE identifier. Vulnerability scanners, SBOM tooling, and patch-management feeds therefore had nothing to key on, and a release note that did not mention security gave operators no reason to prioritize the upgrade. A patch that is invisible to the tooling ecosystem is, for most defenders, not a patch at all. This case argues for treating "ship the fix" and "make the fix legible to scanners" as one indivisible step, and for vendors to use GitHub Security Advisories (which can issue a CVE directly) when a Numbering Authority stalls.

10. Broader lessons

1. "Local" is a network property, not a security property. The moment port 11434 is reachable beyond loopback (a shared LAN, a Docker network, a corporate subnet), a local model server carries the attack surface of an unauthenticated public service. Marketing a self-hosted stack as a data-sovereignty story is empty without an operations layer that patches, segments, authenticates, and audits it.
2. Memory safety has escape hatches, and they cluster in performance-critical code. Go's unsafe, and analogous constructs in other "safe" languages, reintroduce exactly the C-style bounds hazards those languages otherwise eliminate, and they tend to live in hot loops like tensor conversion. Any use of such constructs on a path that consumes untrusted input deserves the same scrutiny as legacy C.
3. Model files are untrusted input. GGUF, safetensors, and similar formats are attacker-controllable binary containers. Parsers must validate that declared metadata (shapes, offsets, sizes) is internally consistent with the bytes actually present before using those values to drive allocation or memory access. Re-implementations of reference loaders should preserve the reference's bounds invariants rather than silently drop them; the io.SectionReader EOF-clamp regression is the object lesson here.
4. Runtime AI infrastructure inherits classic bug classes. The novelty of "AI" does not exempt an inference runtime from CWE-125. If anything, the concentration of prompts, system prompts, tool outputs, and credentials in a single long-lived process makes a memory-disclosure primitive unusually valuable. Apply zero-trust principles to model servers as to any other sensitive service: authenticate, log, rate-limit, and segment every inference call.

11. EU regulatory relevance: AI Act, GDPR, and NIS2

11.1 Why a runtime memory leak is a regulatory event

Bleeding Llama discloses personal data (user prompts, other users' conversations, and any PII/PHI that transited the model) alongside credentials and secrets. The moment an EU-established or EU-market-facing organization's self-hosted LLM processes personal data and can leak it to an unauthenticated attacker, the incident engages EU data-protection law, and for many organizations cybersecurity and AI-specific law as well. The EU footprint is not hypothetical: public scans placed a substantial share of vulnerable instances in Europe, with Germany reported as the third-largest population of exposed servers (~8.9% of the total).

Three regimes are in play, at different levels of maturity and enforceability. The most directly "AI-specific" obligation (AI Act Article 15) is deferred; the sharpest currently-enforceable hook is GDPR.

11.2 GDPR: in force today, the primary exposure

A successful over-read against a server processing personal data is a personal-data breach (a loss of confidentiality) under the GDPR. The relevant obligations are all currently enforceable:

• Art. 5(1)(f) and Art. 32 (security of processing). Controllers and processors must implement technical and organizational measures appropriate to the risk. An internet-reachable, unauthenticated inference endpoint that can leak process memory is hard to defend as "appropriate." The technical remediation in §7 (patch, loopback or firewall binding, authentication proxy, segmentation) is the Art. 32 control set and should be documented as such, before and after.
• Art. 25 (data protection by design and by default). The default 0.0.0.0 bind with no authentication is the antithesis of "by default." A compliant baseline binds to loopback and fronts the API with authentication.
• Art. 33 (breach notification). Where personal data was likely accessed, the competent supervisory authority must be notified without undue delay and, where feasible, within 72 hours of the controller becoming aware, unless the breach is unlikely to result in a risk to individuals. Because the attack is stealthy and leaves no crash or log error, "we found no evidence of access" is a weak basis for declining to notify; the risk assessment should be documented either way.
• Art. 34 (communication to data subjects). Where the breach is likely to result in a high risk to individuals' rights and freedoms (e.g., leaked health data, or credentials enabling onward compromise), the affected individuals must also be informed.
• Art. 35 (DPIA). A self-hosted LLM processing sensitive prompts at scale is a strong candidate for a data protection impact assessment; an existing DPIA should be refreshed to reflect this runtime risk and its mitigations.

11.3 EU AI Act: the direct obligation exists, but is deferred

The AI Act provision most on point is Article 15 (accuracy, robustness, and cybersecurity), which requires high-risk AI systems to be resilient against third parties attempting to exploit system vulnerabilities. A memory-disclosure flaw in the serving stack is squarely within its intent, and the Act's recitals expressly contemplate protecting the AI system's assets against attack.

Timing is the critical nuance. The Digital Omnibus on AI (Regulation (EU) 2026/1744), published in the Official Journal on 24 July 2026 and in force from 27 July 2026, deferred the high-risk obligations. Standalone Annex III high-risk systems now apply from 2 December 2027, and high-risk AI embedded in regulated products (Annex I) from 2 August 2028, replacing the original 2 August 2026 date. Article 15 is therefore not yet enforceable for most deployers.

Two caveats keep this from being an excuse to wait:

1. The deferral is narrow. It did not touch the Article 5 prohibited practices (in force since Feb 2025), the general-purpose AI (GPAI) provider obligations in Articles 51–55 (in force since Aug 2025, which include cybersecurity and model-protection duties that apply if your organization is itself a GPAI provider), or Article 50 transparency (from Aug 2026, with the Art. 50(2) watermarking duty for legacy generative systems from 2 Dec 2026).
2. Deferral is runway, not repeal. Article 15 cybersecurity and robustness conformity is the design target now, and the same harm is already fully actionable today under GDPR and sectoral law regardless of the AI Act timeline.

11.4 NIS2, DORA, and sectoral law: in force for in-scope entities

• NIS2 Directive. Essential and important entities must adopt risk-management measures for their network and information systems and report significant incidents on a staged clock (early warning within 24 hours, notification within 72 hours, final report within one month). An exposed, exploited AI runtime can be a reportable incident and can evidence a risk-management gap.
• DORA. For financial entities, this falls under ICT risk-management and incident-reporting obligations.
• Sectoral law. Healthcare deployments leaking PHI can implicate the Medical Device Regulation (where the AI forms part of a medical device) and national health-data rules; that harm is regulated today irrespective of AI Act timing.

11.5 Compliance remediation checklist

Beyond the technical steps in §7, map the incident to obligations:

1. Assess, then notify if warranted. Determine whether personal data was likely accessed. If so, and if the risk is not "unlikely," file the Art. 33 notification within 72 hours, evaluate Art. 34 data-subject communication for high-risk cases, and, for in-scope entities, run the parallel NIS2/DORA reporting clocks.
2. Document your Art. 32 measures. Record the patch, network restriction, authentication proxy, segmentation, and secret rotation as the technical and organizational measures taken.
3. Rotate and contain. Treat any credentials or secrets that were present in the process environment as compromised; rotate them and review downstream access they unlock.
4. Update records and DPIA. Reflect the self-hosted LLM in the Art. 30 records of processing and refresh the DPIA with the runtime risk and controls.
5. Design for by-default (Art. 25). Standardize loopback binding plus an authenticated proxy as the baseline, and forbid 0.0.0.0 exposure by policy.
6. Minimize what's in reach (Art. 5(1)(c)). Keep secrets out of the process environment (use a secrets manager and short-lived tokens) and minimize retention of prompt and conversation data. This directly shrinks the pool of memory an over-read can disclose.
7. Inventory and classify for the AI Act. Add the Ollama-based system to your AI inventory, classify the use case (is it Annex III high-risk?), and, if so, build toward Article 15 cybersecurity and robustness conformity ahead of 2 December 2027 rather than at the deadline. Treat model files as untrusted input within your supply-chain controls.

The through-line: GDPR makes this incident actionable now; the AI Act sets the direction the required controls are heading. Treating the remediation in §7 as documented, by-default security measures satisfies today's obligations and pre-positions the deployment for Article 15 when it applies.

12. References

1. Cyera Research (Dor Attias), Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama. https://www.cyera.com/research/bleeding-llama-critical-unauthenticated-memory-leak-in-ollama
2. MITRE CVE record, CVE-2026-7482. https://cveawg.mitre.org/api/cve/CVE-2026-7482
3. GitHub Security Advisory, GHSA-x8qc-fggm-mpqg. https://github.com/advisories/GHSA-x8qc-fggm-mpqg
4. Ollama fix, PR #14406, "ggml: ensure tensor size is valid." https://github.com/ollama/ollama/pull/14406
5. runZero, Ollama vulnerability CVE-2026-7482: find impacted assets (names fs/ggml/gguf.go, server/quantization.go WriteTo()). https://www.runzero.com/blog/ollama/
6. CSO Online, Ollama vulnerability highlights danger of AI frameworks with unrestricted access. https://www.csoonline.com/article/4168584/
7. The Hacker News, Ollama Out-of-Bounds Read Vulnerability Allows Remote Process Memory Leak. https://thehackernews.com/2026/05/ollama-out-of-bounds-read-vulnerability.html
8. SecurityWeek, Critical Bug Could Expose 300,000 Ollama Deployments to Information Theft. https://www.securityweek.com/critical-bug-could-expose-300000-ollama-deployments-to-information-theft/
9. Mondoo, Three Ollama CVEs in One Week: Bleeding Llama Plus Two Windows Updater Flaws (context on CVE-2026-42248 / -42249). https://mondoo.com/blog/three-ollama-cves-bleeding-llama-and-windows-updater-flaws
10. Public GGUF structural-check detection tooling for CVE-2026-7482 (root-cause discussion of the C++ nbytes_remain invariant vs. the Go io.SectionReader EOF-clamp). https://github.com/msuiche/gguf_cve2026_7482
11. Regulation (EU) 2024/1689, the EU Artificial Intelligence Act (see Art. 15 on accuracy, robustness, and cybersecurity). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
12. Regulation (EU) 2016/679, General Data Protection Regulation (Arts. 5, 25, 32, 33, 34, 35). https://eur-lex.europa.eu/eli/reg/2016/679/oj
13. Council of the EU, Final green light to simplify and streamline AI rules (Digital Omnibus on AI / Regulation (EU) 2026/1744; high-risk deferral to 2 Dec 2027 / 2 Aug 2028), 29 June 2026. https://www.consilium.europa.eu/en/press/press-releases/2026/06/29/artificial-intelligence-council-gives-final-green-light-to-simplify-and-streamline-rules/
14. Cloud Security Alliance, research note confirming the Digital Omnibus on AI as enacted law (OJ publication 24 July 2026, in force 27 July 2026). https://labs.cloudsecurityalliance.org/research/csa-research-note-eu-ai-act-high-risk-deadline-omnibus-20260/
15. wz-it, Bleeding Llama: Why Self-Hosted AI Isn't Automatically Secure AI (notes GDPR Art. 33 notifiability and EU exposure share). https://wz-it.com/en/blog/bleeding-llama-ollama-cve-2026-7482-self-hosted-ai-hardening/

Prepared as a defensive security research write-up. It documents a disclosed, patched vulnerability to help operators assess exposure and remediate; it deliberately omits exploit code and file-crafting details. Verify current advisory status against the CVE record and vendor release notes before acting.