CVE-2024-12886: Ollama Server OOM DoS Vulnerability

CVE-2024-12886 Overview

CVE-2024-12886 is an Out-Of-Memory (OOM) vulnerability affecting ollama server version 0.3.14. A malicious API server can respond with a gzip bomb HTTP response that forces the ollama client to allocate excessive memory and crash. The flaw resides in the makeRequestWithRetry and getAuthorizationToken functions, which invoke io.ReadAll on untrusted response bodies without size limits. Exploitation results in a Denial of Service (DoS) condition against systems running the affected ollama version. The vulnerability is classified under CWE-409 (Improper Handling of Highly Compressed Data).

Critical Impact
A single malicious HTTP response containing a gzip bomb can exhaust host memory and crash the ollama server, disrupting AI model serving and downstream applications.

Affected Products

Ollama server version 0.3.14
Deployments that pull models or tokens from untrusted or attacker-controlled registries
Environments where the ollama client communicates with external API endpoints over the network

Discovery Timeline

2025-03-20 - CVE-2024-12886 published to the National Vulnerability Database (NVD)
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-12886

Vulnerability Analysis

The vulnerability originates in how ollama consumes HTTP response bodies from remote API servers. The makeRequestWithRetry and getAuthorizationToken functions call io.ReadAll to buffer the full response into memory before processing. When the remote server returns a highly compressed gzip payload, the client decompresses it in full without enforcing a maximum size boundary.

An attacker who controls or impersonates the upstream API server can send a payload that decompresses into gigabytes of data. The Go runtime allocates memory until the process is killed by the operating system or the host runs out of memory. The result is a reliable crash of the ollama server, taking down any hosted models and dependent services.

Because the request originates from ollama itself, this is a client-side parsing issue triggered by attacker-controlled response content. No authentication to the ollama host is required.

Root Cause

The root cause is unbounded response body consumption. io.ReadAll reads until EOF with no maximum length parameter. When combined with automatic gzip decompression in the HTTP transport layer, small compressed payloads expand into memory allocations far exceeding available RAM. The functions lack an io.LimitReader wrapper or a content-length sanity check before reading.

Attack Vector

Exploitation requires the ollama server to make an outbound HTTP request to an attacker-controlled or attacker-influenced endpoint. This can occur when pulling a model, refreshing an authorization token, or interacting with a registry mirror. The attacker returns a valid HTTP response with Content-Encoding: gzip and a small compressed body that expands into a very large decompressed stream. The io.ReadAll call inside makeRequestWithRetry or getAuthorizationToken allocates memory linearly with the decompressed size until the process terminates.

See the Huntr Bounty Overview for the original technical write-up and proof-of-concept details.

Detection Methods for CVE-2024-12886

Indicators of Compromise

Sudden termination of the ollama process with OOM killer entries in /var/log/syslog or dmesg referencing the ollama binary
Spikes in resident memory usage for the ollama process immediately before a crash
Outbound HTTPS requests from ollama hosts to unexpected registry or authorization endpoints
HTTP responses to the ollama client with Content-Encoding: gzip and abnormally high decompression ratios

Detection Strategies

Monitor process memory metrics for ollama and alert on rapid growth exceeding normal model-loading baselines
Inspect egress traffic from AI inference hosts and flag connections to registries not on an approved allowlist
Correlate ollama process crashes with preceding outbound HTTP activity to identify triggering endpoints
Enable behavioral endpoint telemetry to capture process termination events tied to kernel OOM decisions

Monitoring Recommendations

Ingest host metrics and container runtime logs into a centralized data lake for correlation with network activity
Track HTTP response sizes and compression ratios at the network gateway serving ollama egress traffic
Alert on repeated ollama service restarts, which may indicate exploitation attempts against the client

How to Mitigate CVE-2024-12886

Immediate Actions Required

Upgrade ollama to a version later than 0.3.14 that constrains response body reads
Restrict outbound network access from ollama hosts to a vetted allowlist of model registries
Place a reverse proxy or egress filter in front of ollama to enforce maximum response sizes and reject oversized compressed payloads
Run ollama under systemd or a container runtime with strict memory limits so a crash does not affect co-located services

Patch Information

The issue was reported through the Huntr bounty program. Review the Huntr Bounty Overview and the official Ollama release notes for the fixed version. The remediation replaces unbounded io.ReadAll calls with size-limited readers in makeRequestWithRetry and getAuthorizationToken.

Workarounds

Block or proxy outbound traffic from ollama through a gateway that inspects Content-Length and decompressed size before forwarding responses
Configure cgroup memory limits (MemoryMax in systemd or --memory in Docker) to contain OOM impact to the ollama process
Pin ollama clients to trusted internal mirrors and disable dynamic registry lookups where feasible

bash

# Example: run ollama under a systemd unit with a hard memory ceiling
# /etc/systemd/system/ollama.service.d/override.conf
[Service]
MemoryMax=8G
MemoryHigh=6G
Restart=on-failure
RestartSec=5s