Ollama's HTTP API has no authentication of its own. The project's
answer has always been "bind it to localhost", and plenty of
deployments do not: Docker port mappings, a reverse proxy added for a
web UI, or OLLAMA_HOST=0.0.0.0 so a second machine can use the GPU.
That matters more than usual this autumn, because the endpoint that
downloads models, /api/pull, is where most of the new CVEs sit.
CVE-2026-103663: the one to patch today
Published by NVD on 8 October 2026 from a report coordinated by CERT Polska, with a CVSS 4.0 score of 9.4.
What the record says: digestToPath, the function that turns a model
layer digest into a file path, did not validate the digest. An
unauthenticated caller of /api/pull can supply a digest containing a
path traversal sequence and make Ollama write a file of their choosing
outside the model store. In most Ollama Docker images the server can
write to /usr/lib/ollama; a file dropped there is loaded on the next
restart, which gives code execution as root.
Fixed in 0.35.0, per the NVD description.
The attack needs nothing but network access to the API. If your port 11434 answers from outside the host, read the rest of this list as "has probably been tried".
The rest of the pull path
| CVE | Published | What it is | Fixed in |
|---|---|---|---|
| CVE-2026-108836 | 2026-10-12 | SSRF in the Pull API through model name validation (IsValid in types/model/name.go) | 0.34.2 |
| CVE-2026-85180 | 2026-09-03 | Blob downloads for tensor-layer models follow redirects to any host, so a malicious registry can make the server request internal addresses such as cloud metadata | VulnCheck lists 0.30.0 through 0.33.2 as affected |
| CVE-2026-65315 | 2026-07-21 | A crafted GGUF file under 1 KB, uploaded or pulled, makes the metadata parser allocate without bounds and crashes the whole server | no fixed version in NVD yet (issue #17042) |
| CVE-2026-86289 | 2026-09-07 | Integer overflow in the GGUF string reader | 0.31.2-rc1 |
| CVE-2026-15685 | 2026-07-13 | Out-of-bounds read in downloadBlob, unauthenticated denial of service (ZDI-26-403) | NVD lists 0.7.1 as affected |
Two things stand out. First, both SSRF bugs (108836 and 85180) turn a pull request into a request from your server to wherever the attacker points it. On a cloud VM that usually means the instance metadata service, and from there the instance credentials. Second, the GGUF parser bugs mean that a model file is untrusted input. Pulling from a registry you do not control is running a parser on attacker data.
A different one: the experimental agent mode
CVE-2026-102697, published 29 September,
affects Ollama 0.14.0 up to 0.31.2 when the experimental agent mode is
used. Its Bash tool approval checked commands by prefix and did not
parse shell syntax, so once a command was approved, output steered by
prompt injection could append ; or && and run more commands without
asking. Fixed in 0.31.2 according to the record and the
v0.31.2 release.
If you use agent mode, approve per command, never per session.
What to do
- Upgrade to 0.35.0 or later. It is the version the NVD record gives for CVE-2026-103663 and it is past every fixed version above. For the Docker image, pin the tag (
ollama/ollama:0.35.0or newer) instead oflatest, so you know what you run. - Close port 11434. Bind to
127.0.0.1, or to a private interface, and put any remote access behind a reverse proxy with authentication or behind a VPN. In Docker, publish the port as127.0.0.1:11434:11434, not11434:11434. - Make the library directory read-only for the server. The root code execution in CVE-2026-103663 depends on Ollama being able to write to
/usr/lib/ollama. Run the container with a read-only root filesystem and a dedicated writable volume for models only. - Pull only from registries you trust, and on cloud VMs block or require tokens for the metadata service (IMDSv2 on AWS), which takes most of the value out of the SSRF bugs.
- If an affected Ollama was reachable from the internet, look for unexpected files in
/usr/lib/ollamaand in the model store, and rebuild the container from a clean image.
Keep watching
The full, live list is at Ollama CVEs, refreshed from
NVD every six hours. Earlier Ollama memory-safety bugs are covered in
inference server memory CVEs.
To check the exact tag you run, paste your docker-compose.yml into the
stack scanner: it reads the image version and tells you
which of these CVEs apply to it.