Ollama Path Traversal Lets Remote Attackers Plant Files, and Reach Root in Docker Deployments (CVE-2026-103663)

A path traversal flaw in Ollama's /api/pull endpoint, tracked as CVE-2026-103663, lets an unauthenticated remote attacker write a binary outside the model store. Where the server process can write to /usr/lib/ollama, which the CVE record says is the default in most Ollama Docker images, the planted file is loaded and executed on the next server restart, giving remote code execution as root. Ollama fixed the issue in version 0.35.0. CERT Polska, acting as CNA, published the record on 8 October 2026.

Who is affected

The CVE record lists Ollama versions from 0.34.2 up to, but not including, 0.35.0. CERT Polska's advisory page says "From 0.34.2 to 0.35.0" under vulnerable versions, and also says the issue is fixed in 0.35.0. That "to" is ambiguous next to the CVE record's "less than 0.35.0", so we treat 0.35.0 as the fixed release and the range as unclear at its upper end.

Only three releases fall inside the range: 0.34.2 (15 September), 0.34.3 (19 September) and 0.34.4 (23 September). The window ran about two weeks, until 0.35.0 on 28 September. Newer releases exist: 0.35.1 (29 September) and 0.40.1 (7 October), the current stable. Upgrade to 0.35.0 or later.

Exposure depends on reachability. Ollama binds to 127.0.0.1 port 11434 by default, per its FAQ, so a stock desktop or systemd install is not reachable from the network. The official Docker image differs: its Dockerfile sets OLLAMA_HOST=0.0.0.0:11434 and exposes the port, and it has no USER directive, so the process runs as root. The CNA itself describes the result as remote code execution as root; our check of the Dockerfile at the v0.35.0 tag supports that. Any deployment where an operator has set OLLAMA_HOST to a non-loopback address, or published the container port, is reachable by whoever can reach that port. The CVE record describes the attacker as unauthenticated, so reachability of the port is the only gate. Ollama's earlier agent-mode approval bypass, CVE-2026-102697, was a different flaw in the same product.

Technical detail

The attack chain: one unauthenticated pull request becomes root code execution on the next restart, if /usr/lib/ollama is writable.

The CNA description says the digestToPath function does not sufficiently validate layer digests supplied during a pull. An attacker can supply a path traversal sequence as a layer digest, so the server writes a malicious binary to a location outside the model store. The weakness is classed as CWE-23 (Relative Path Traversal), with CWE-913 (Improper Control of Dynamically-Managed Code Resources) added for the load-and-execute step.

The impact splits into two cases, and the CNA scored both:

The 9.4 headline figure applies only to the second case. The "passive" user interaction in that vector reflects the need for a restart before the planted file runs. The file write itself needs no credentials. Restarts are routine: container redeploys, host reboots, upgrades and crash recovery all trigger one, so an attacker does not need to cause it.

Exploitation status

We found no evidence of exploitation. CISA's ADP entry on the record, dated 8 October, lists SSVC exploitation as "none", automatable as "no" and technical impact as "total". The CVE is not in CISA's Known Exploited Vulnerabilities feed as of 9 October 2026. We did not find a public proof of concept. NVD lists the record as "Awaiting Analysis". Its only score is CERT Polska's 9.4 vector, shown as secondary; NVD has no score of its own and does not list the 6.9 scenario. The v0.35.0 release notes, published 28 September, describe decision-model support and minor fixes and do not mention this vulnerability, and we did not locate the fixing commit. Treat the lack of a public exploit as temporary: the flaw needs one unauthenticated request to plant a file, much as with the LightLLM visual-node pickle flaw and the LMCache multiprocess pickle RCE.

What defenders should do

• Upgrade to Ollama 0.35.0 or later, including Docker images and any pinned tags in compose files or Kubernetes manifests.
• Find instances reachable beyond localhost: check OLLAMA_HOST, published container ports and reverse proxies. Put authentication or a network allowlist in front of port 11434.
• Where an upgrade must wait, restrict the process's write access to /usr/lib/ollama (for example a read-only root filesystem or a non-root user), which the CNA scores as the lower 6.9 case. This is a mitigation to reduce impact, not a fix, and the file-write primitive remains.
• For instances that were exposed on an affected version, look for unexpected files under /usr/lib/ollama and check logs for unexpected /api/pull requests from unknown clients, before the next restart. Restarting first would run anything planted.
• Credit: the finder is Bartlomiej Dmitruk of striga.ai.

Sources

• CVE record (CERT Polska CNA JSON)
• CERT Polska advisory
• Ollama v0.35.0 release
• Ollama Dockerfile at v0.35.0
• NVD record
• Ollama releases
• Ollama FAQ
• CISA KEV feed