al-ice.ai

The Digest Was a Path: CVE-2026-103663 Turns Ollama's /api/pull Into Unauthenticated Root RCE

AI Vulnerabilities & CVEs by al-ice.ai Editorial

CVE-2026-103663 entered the National Vulnerability Database on 8 October 2026, scoring CVSS 4.0 base 9.4 (Critical) with a NETWORK vector, no privileges, and no attack requirements beyond a passive user. The subject is Ollama from 0.34.2 up to (but not including) 0.35.0: a relative path traversal (CWE-23) in the /api/pull endpoint, where the digestToPath function fails to validate layer digests. An unauthenticated remote attacker supplies a digest containing a traversal sequence, and the server writes the attacker's binary outside the model store. In default Docker deployments — where the server process can write to /usr/lib/ollama — the planted file is loaded and executed as root on the next server restart. The model pull API is the delivery vehicle; a restart is the trigger.

A content address you can spend anywhere

The defect class is depressingly familiar: a layer digest is a content address, and content addresses are supposed to be inert hex. digestToPath evidently treated the attacker-controlled digest string as path material without constraining it to the model directory, so .. sequences in a pull request became directory escapes on the server. No authentication, no model to host, no interaction with a victim beyond the server itself — the CVSS flags (PR:N, AT:N, UI:P) describe a single malicious pull request against any reachable Ollama API. The Docker amplification is what converts a file-write primitive into root RCE: the official images' default layout puts executable-loading /usr/lib/ollama within the server's write reach, so traversal plus restart equals code execution with full subsequent-system compromise across confidentiality, integrity, and availability.

Credit belongs to Bartłomiej Dmitruk (striga.ai), who reported through CERT Polska's coordinated vulnerability disclosure programme; CERT Polska (CSIRT NASK) coordinated and published the advisory on 8 October. CISA's SSVC assessment filed alongside the record rates exploitation as none observed, automatable no, technical impact total — unexploited, but a complete-loss primitive if it lands.

Ten days from fix to number

The fix — Ollama 0.35.0, released 28 September 2026 — predates the CVE publication by ten days, the standard coordinated-disclosure lag done right: patch available before the write primitive is documented. Anyone who pulled 0.35.0 on release day has been safe for over a week without knowing why. Anyone running 0.34.x with an exposed API has been vulnerable the whole time, and the disclosure now hands every scanner the exact endpoint and function name. The NVD record still shows Awaiting Analysis, so treat the CERT Polska advisory — not the bare NVD entry — as the authoritative description until enrichment lands.

This is Ollama's second CVE briefing in five days on this site, and the pairing is instructive. CVE-2026-102697 (4 October) was an agent-mode approval flaw: the policy spoke strings while the executor spoke shell. CVE-2026-103663 is the server-side mirror: the API spoke content addresses while the filesystem spoke paths. Both are boundary-translation bugs — trusted-internal identifiers built by concatenating untrusted-external input — in the two halves of the same product. Local-first inference keeps the weights on your hardware; it does nothing for you when the serving layer treats the network as a friend.

What to do

  • Upgrade to Ollama 0.35.0 or later now. Every release from 0.34.2 up to 0.35.0 is in the affected range. Confirm with ollama --version on servers, CI runners, and developer machines — and rebuild container images rather than patching running ones, since a planted file may already be sitting outside the model store.
  • Do not expose /api/pull — or the Ollama API at all — to untrusted networks. This endpoint needs no credentials by design; network reachability was the only precondition. Bind to localhost, gate with authentication at the reverse proxy, and treat any internet-facing Ollama port as an incident until proven otherwise.
  • Hunt for traversal artefacts before restarting. If you ran an affected version with a reachable API, inspect for files written outside the model directory — particularly anything under /usr/lib/ollama you did not put there — before the restart that would execute them. A restart is the trigger; make it a clean one.
  • Constrain the server's write surface in your own deployments. Run the process with write access limited to the model store, mount executable directories read-only, and drop privileges so that even a successful traversal cannot reach a code-loading path as root.

Verification note: the CVE ID, 8 October NVD publication date, CVSS 4.0 9.4 vector and severity, affected range (0.34.2 to below 0.35.0), CWE-23 classification, digestToPath mechanism, unauthenticated-remote characterisation, /usr/lib/ollama Docker-default write path with root execution on restart, fixed-in-0.35.0 statement, reporter credit, CERT Polska CVD coordination role, and the SSVC exploitation/automatable/impact triple were read directly from CERT Polska's 8 October advisory and the NVD CVE record (status Awaiting Analysis); the 0.35.0 release date (28 September 2026) was read from the ollama/ollama GitHub release. We did not test the traversal against any live server.

Sources: