CERT Polska disclosed CVE-2026-103663 on 8 October 2026. Ollama’s /api/pull endpoint does not validate layer digests, so an unauthenticated remote attacker can write a file outside the model store. If the server can write to /usr/lib/ollama, the file runs as root on the next restart. Version 0.35.0 fixes it.
Key takeaways
- Affected: Ollama 0.34.2 up to the 0.35.0 fix.
- No authentication is needed to reach /api/pull.
- Root code execution needs write access to /usr/lib/ollama.
- CERT Polska says that access is the default in most Docker images.
- Upgrade to 0.35.0 or later and keep port 11434 private.
What did CERT Polska disclose?
According to the CERT Polska advisory, the digestToPath function does not sufficiently validate layer digests sent to /api/pull. An attacker can supply a path traversal sequence as a digest. The server then writes a malicious binary outside the model store.
CERT Polska classifies the bug as relative path traversal (CWE-23). It lists vulnerable versions from 0.34.2 and says the issue was fixed in 0.35.0. The advisory credits Bartłomiej Dmitruk of striga.ai with the report.
How does a file write become root code execution?
According to the advisory, if the Ollama process can write to /usr/lib/ollama, the attacker can place the file there. On the next server restart, Ollama loads and runs it, which gives code execution as root.
CERT Polska states that this write access is the default in most Ollama Docker images. A container that restarts on a schedule, on a crash or on a host reboot completes the attack without further action from the attacker.
Who is exposed?
The Ollama FAQ says Ollama binds 127.0.0.1 port 11434 by default, and the OLLAMA_HOST variable changes the bind address. The same FAQ shows how to set OLLAMA_HOST to 0.0.0.0:11434 and how to publish the port from Docker.
CERT Polska describes the attacker as unauthenticated and remote. In practice, any client that can reach port 11434 on an affected server is in that position. That includes other workloads on the same network, not only the internet. A tunnel or proxy that forwards to Ollama without its own authentication carries the same exposure.
Which version fixes it?
The Ollama v0.35.0 release was published on GitHub on 28 September 2026, before the advisory. Its release notes do not mention the vulnerability, so a team reading changelogs alone would not have known to prioritise it. Check the running version, not the image tag you meant to deploy.
Sorami’s view
This section is opinion. It is our reading of the advisory, not a statement from CERT Polska or Ollama.
Treat a model server as an application server. Ollama serves an API that can download and write files, so it needs the same network and file-permission controls as any other internet-facing service.
Fix the second step as well as the first. Upgrading closes this path traversal. A model server that cannot write to its own library directory and does not run as root also limits the next file-write bug.
What to do now
- Run ollama --version on every host and container.
- Upgrade anything from 0.34.2 to 0.35.0 or later.
- Check OLLAMA_HOST and Docker port mappings for 11434.
- Put authentication in front of any shared Ollama endpoint.
- Remove write access to /usr/lib/ollama for the server process.
- Look for unexpected files in /usr/lib/ollama before the next restart.
If you run self-hosted models and want the serving layer tested, see our AI application penetration testing, or contact us to discuss scope.
Related guides
- Securing Ray and vLLM on Kubernetes
- vLLM 0.31.0 security advisories
- AI agent DNS exfiltration from a sandbox
- Every Sorami article is in the guides index.
Sources
- CERT Polska, Vulnerability in Ollama software, CVE-2026-103663 (8 October 2026)
- Ollama, v0.35.0 release on GitHub (28 September 2026)
- Ollama FAQ: exposing Ollama on the network
Facts on this page were checked against these sources on 16 October 2026. We update the page when the source changes.