Ollama, the widely deployed self-hosted large-language-model runtime, has two CVEs in our source data from 2026: a heap out-of-bounds read in its GGUF model loader (CVE-2026-7482, CVSS 9.1) that VulnCheck’s KEV catalog lists as under active exploitation, and a lower-severity null-pointer crash in multi-modal image handling (CVE-2025-15514). Only the first is confirmed exploited; the second has no exploitation evidence in our data.
CVE-2026-7482: heap out-of-bounds read in the GGUF model loader
Affects Ollama before 0.17.1. Per the NVD record, the /api/create endpoint accepts an attacker-supplied GGUF model file whose declared tensor offset and size can exceed the file’s actual length; during quantization (in fs/ggml/gguf.go and server/quantization.go‘s WriteTo()), the server reads past the allocated heap buffer. NVD’s own description states the leaked memory contents “may include environment variables, API keys, system prompts, and concurrent users’ conversation data.” CWE-125 (Out-of-Bounds Read). CVSS base 9.1 (critical; vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H). VulnCheck lists this CVE in its KEV catalog, exploitation added 2026-06-08, with exploit availability recorded as “active.” Fixed in 0.17.1. Confidence: high — NVD and VulnCheck KEV are two independent sources agreeing on both the vulnerability and its exploited status.
CVE-2025-15514: null pointer dereference in multi-modal image processing
Affects Ollama 0.11.5-rc0 through 0.13.5. Per the CVE.org record, the /api/chat endpoint accepts base64-encoded image data for multi-modal models but doesn’t validate that the decoded data represents valid media before passing it to the mtmd_helper_bitmap_init_from_buf function; that function can return NULL for malformed input, and the code dereferences the return value without a NULL check first, crashing the server. The record tags this CWE-395. FIRST EPSS scores this CVE at 0.78% (54th percentile) as of this writing — a real but low predicted-exploitation likelihood, not evidence of actual exploitation. No CVSS score is recorded in this ledger entry, and our data has no fixed-version field for this CVE. Not listed in any KEV catalog. Confidence: medium — CVE.org only; an EPSS score is a probability estimate layered on an already-identified CVE, not independent corroboration of the underlying flaw.
Confidence and evidence gaps
CVE-2026-7482 reaches high confidence because NVD and VulnCheck KEV are two distinct, independent sources in our ledger that agree on the vulnerability and its active-exploitation status — a genuine, not formal, high-confidence outcome. CVE-2025-15514 stays at medium: CVE.org is its only source for the underlying technical claim, and while FIRST EPSS supplies a real score for it, that’s a separate scoring layer, not a second source confirming the vulnerability itself. Worth naming directly: our ledger has no fixed-version data for CVE-2025-15514, so we can’t tell readers which release resolves it beyond pointing to the referenced huntr and VulnCheck advisories.
Why this matters
Ollama’s out-of-bounds read is a direct multi-tenant risk for anyone running a shared Ollama instance: leaking another session’s API keys, system prompt, or conversation history out of heap memory undermines the isolation a shared inference server is expected to provide, and VulnCheck’s active-exploitation listing means this isn’t a theoretical risk. The null-pointer crash is a more conventional availability issue — a malformed image can take the service down, which matters for uptime but doesn’t carry the same data-exposure risk.
Frequently Asked Questions
Is the Ollama vulnerability being actively exploited? CVE-2026-7482 is — VulnCheck’s KEV catalog lists it as under active exploitation. CVE-2025-15514 has no exploitation evidence in our data.
Which Ollama version fixes these issues? Ollama 0.17.1 fixes CVE-2026-7482. Our ledger has no fixed-version data for CVE-2025-15514; check the referenced huntr or VulnCheck advisory directly.
Does the out-of-bounds read only affect servers that load untrusted models?
The vulnerability triggers through the /api/create endpoint processing an attacker-supplied GGUF file, so a deployment that only ever loads models from a fully trusted source has a materially different exposure — but our source data doesn’t further scope the precondition beyond the endpoint and file-parsing path NVD names.
Can the leaked memory really include other users’ conversations? Per NVD’s own description, yes — the leaked heap memory “may include” API keys, system prompts, and concurrent users’ conversation data, on a shared or multi-tenant Ollama deployment.
Data sourced from National Vulnerability Database (NVD), VulnCheck KEV, CVE.org, and FIRST EPSS records, evaluated September 2026. This product uses the NVD API but is not endorsed or certified by the NVD. See more vulnerability intelligence.