CVE-2026-65315: Ollama crafted GGUF file crashes

CISO Take

A memory allocation flaw in Ollama's GGUF metadata parser lets an unauthenticated remote attacker crash the entire inference server by uploading a crafted file smaller than 1KB — the parser trusts attacker-controlled length and count fields as allocation sizes without validating them against the remaining file size. This matters because Ollama is one of the most widely deployed local/self-hosted LLM inference engines, and its blob upload and model create/pull endpoints are frequently exposed without authentication in dev, CI, and even some production setups; a single malformed upload triggers a Go runtime out-of-memory fatal error or makeslice panic that bypasses recovery middleware, taking down inference for every tenant on that instance, not just the requester. There is no EPSS score and no CISA KEV listing yet, and no public exploit or Nuclei template has surfaced, so this is not being actively exploited at scale — but the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) and the trivial file-crafting requirement mean a working PoC could appear quickly. Patch to the fixed Ollama build referenced in the upstream GitHub issue, and in the meantime bind the Ollama API to localhost or place it behind authenticated network access rather than exposing blob upload/model create endpoints directly to the internet. Monitor for repeated unexpected Ollama process restarts or OOM kills as a detection signal of exploitation attempts.

Sources: NVD GitHub Advisory CISA KEV ATLAS github.com/ollama/ollama vulncheck.com

What is the risk?

High-severity, low-complexity, unauthenticated remote denial of service. Exploitability is trivial from a mechanics standpoint (a sub-1KB crafted file, no auth, no user interaction) but requires knowledge of the GGUF binary format to craft the malicious length/count fields, which places crafting effort at a moderate technical bar even though execution is simple. Impact is confined to availability (C:N/I:N/A:H) — no data exposure or integrity loss — but because the crash escapes Go's panic-recovery middleware, it kills the entire server process rather than just the offending request, producing a full outage for all users/models served by that instance. Exposure is highly deployment-dependent: instances that expose the Ollama API (default port 11434) to untrusted networks, multi-tenant model-serving setups, and any pipeline that allows third parties to trigger model pull/create are most exposed. No active exploitation or public tooling observed at time of publication, but no authentication is required, which keeps the practical risk elevated for internet-facing deployments.

How does the attack unfold?

Initial Access

Attacker with network access uploads a crafted sub-1KB GGUF file via Ollama's unauthenticated blob upload API endpoint.

AML.T0049

Trigger Parsing

Attacker issues a model create or pull request referencing the malicious blob, invoking Ollama's GGUF metadata parser on the crafted fields.

AML.T0049

Uncontrolled Allocation

The parser uses attacker-controlled string length, tensor dimension count, and metadata array count fields directly as memory allocation sizes without bounds checking.

Impact

The Go runtime hits an out-of-memory fatal error or makeslice panic that bypasses recovery middleware, crashing the entire Ollama server process and denying inference to all users.

AML.T0029

Initial Access

Attacker with network access uploads a crafted sub-1KB GGUF file via Ollama's unauthenticated blob upload API endpoint.

AML.T0049

Trigger Parsing

Attacker issues a model create or pull request referencing the malicious blob, invoking Ollama's GGUF metadata parser on the crafted fields.

AML.T0049

Uncontrolled Allocation

The parser uses attacker-controlled string length, tensor dimension count, and metadata array count fields directly as memory allocation sizes without bounds checking.

Impact

The Go runtime hits an out-of-memory fatal error or makeslice panic that bypasses recovery middleware, crashing the entire Ollama server process and denying inference to all users.

AML.T0029

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Ollama	pip	—	No patch
181.3K 1.8K dependents Pushed 2d ago 15% patched ~36d to patch Full package profile →

Do you use Ollama? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.8%

chance of exploitation in 30 days

Higher than 55% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C None

I None

A High

What should I do?

1 step

1) Upgrade Ollama to the patched release referenced in github.com/ollama/ollama/issues/17042 as soon as it is available/verified. 2) Do not expose the Ollama API (blob upload, model create, model pull endpoints) directly to untrusted networks — bind to localhost or place behind an authenticated reverse proxy / VPN. 3) If public exposure is required, add a reverse-proxy layer that enforces sane file-size and structural limits on uploaded GGUF files before they reach Ollama. 4) Restrict or disable the model create/blob upload endpoints for users who don't need self-service model management. 5) Detection: alert on unexpected Ollama process restarts, OOM-killed containers, or Go fatal error / panic log entries correlated with recent blob upload or model create/pull activity.

What does CISA's SSVC say?

Decision Track

Exploitation none

Automatable Yes

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

DoS Inference Model AML.T0029 - Denial of AI Service AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

Clause 8.2 - Operational planning and control of AI system

NIST AI RMF

MEASURE-2.7 - AI system security and resilience are evaluated and documented

OWASP LLM Top 10

LLM10:2025 - Unbounded Consumption

Frequently Asked Questions

What is CVE-2026-65315?

A memory allocation flaw in Ollama's GGUF metadata parser lets an unauthenticated remote attacker crash the entire inference server by uploading a crafted file smaller than 1KB — the parser trusts attacker-controlled length and count fields as allocation sizes without validating them against the remaining file size. This matters because Ollama is one of the most widely deployed local/self-hosted LLM inference engines, and its blob upload and model create/pull endpoints are frequently exposed without authentication in dev, CI, and even some production setups; a single malformed upload triggers a Go runtime out-of-memory fatal error or makeslice panic that bypasses recovery middleware, taking down inference for every tenant on that instance, not just the requester. There is no EPSS score and no CISA KEV listing yet, and no public exploit or Nuclei template has surfaced, so this is not being actively exploited at scale — but the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) and the trivial file-crafting requirement mean a working PoC could appear quickly. Patch to the fixed Ollama build referenced in the upstream GitHub issue, and in the meantime bind the Ollama API to localhost or place it behind authenticated network access rather than exposing blob upload/model create endpoints directly to the internet. Monitor for repeated unexpected Ollama process restarts or OOM kills as a detection signal of exploitation attempts.

Is CVE-2026-65315 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-65315, increasing the risk of exploitation.

How to fix CVE-2026-65315?

1) Upgrade Ollama to the patched release referenced in github.com/ollama/ollama/issues/17042 as soon as it is available/verified. 2) Do not expose the Ollama API (blob upload, model create, model pull endpoints) directly to untrusted networks — bind to localhost or place behind an authenticated reverse proxy / VPN. 3) If public exposure is required, add a reverse-proxy layer that enforces sane file-size and structural limits on uploaded GGUF files before they reach Ollama. 4) Restrict or disable the model create/blob upload endpoints for users who don't need self-service model management. 5) Detection: alert on unexpected Ollama process restarts, OOM-killed containers, or Go fatal error / panic log entries correlated with recent blob upload or model create/pull activity.

What systems are affected by CVE-2026-65315?

This vulnerability affects the following AI/ML architecture patterns: model serving, local LLM inference, agent frameworks, RAG pipelines.

What is the CVSS score for CVE-2026-65315?

CVE-2026-65315 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.81%.

What is the AI security impact?

Affected AI Architectures

model servinglocal LLM inferenceagent frameworksRAG pipelines

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: Clause 8.2

NIST AI RMF: MEASURE-2.7

OWASP LLM Top 10: LLM10:2025

What are the technical details?

Original Advisory

Ollama (HEAD f0078ae) contains an uncontrolled memory allocation vulnerability in the GGUF metadata parser that allows remote attackers to crash the server by supplying a crafted GGUF file with attacker-controlled length and count fields in string lengths, tensor dimension counts, and metadata array counts that are used as allocation sizes without validation against remaining file size. Attackers can upload a sub-1KB crafted GGUF file via the blob upload and model create or pull API endpoints to trigger unrecoverable Go runtime out-of-memory fatal errors or makeslice panics that bypass recovery middleware and crash the entire server process.

Exploitation Scenario

An attacker with network access to an Ollama instance's API (often reachable without authentication in dev environments, internal tooling, or misconfigured production deployments) crafts a GGUF file under 1KB where string length fields, tensor dimension counts, and metadata array counts are set to attacker-chosen large values. The attacker uploads this file via the blob upload endpoint and then issues a model create or pull request referencing that blob. Ollama's GGUF metadata parser reads the attacker-controlled fields and uses them directly as memory allocation sizes without checking them against the actual remaining bytes in the file. This forces the Go runtime to attempt an oversized allocation, resulting in an out-of-memory fatal error or a makeslice panic that is not caught by the server's recovery middleware — crashing the entire Ollama process and disrupting inference for every user and application relying on that instance, repeatable at will with no authentication required.

Weaknesses (CWE)

CWE-789 Memory Allocation with Excessive Size Value Primary CWE-789 Memory Allocation with Excessive Size Value

CWE-789 — Memory Allocation with Excessive Size Value: The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

[Implementation, Architecture and Design] Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
[Operation] Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

Source: MITRE CWE corpus.