Probllama: a path-traversal in Ollama's model puller became root RCE on exposed servers

What happened

Ollama is a popular open-source tool for running LLMs locally and in containers. In June 2024 Wiz Research disclosed CVE-2024-37032, nicknamed Probllama, a remote code execution vulnerability in Ollama's model-handling code.

The flaw was insufficient input validation in the /api/pull endpoint. When pulling a model from a registry, an attacker could inject a path-traversal payload into the digest field of a manifest file, causing Ollama to write attacker-controlled content to an arbitrary location on the server — arbitrary file write. Wiz chained this into full RCE: they used the /api/push endpoint for arbitrary file read, then overwrote a system file such as /etc/ld.so.preload to force a malicious shared library to load. In Docker deployments the Ollama server runs as root, so the payload executed with root privileges. Wiz reported the issue on May 5, 2024; Ollama committed a fix within hours and released the patched version 0.1.34 on May 8, with public disclosure on June 24, 2024. As of June 10, 2024, Wiz observed over 1,000 internet-exposed instances still running vulnerable versions.

Root cause

A registry-supplied field was used to build a filesystem path without validation (CWE-22 path traversal). Ollama trusted the manifest's digest value as a safe identifier when it was in fact attacker-controllable, and the default container deployment ran the process as root — turning an arbitrary write into a root compromise. It is an OWASP LLM03 Supply Chain failure: the tool that ships and runs models was itself the attack surface.

How it would have been caught

A test that pulls a model whose manifest digest contains ../ sequences and asserts no file is written outside the model store would have caught it. An external attack-surface scan (or a Shodan sweep for port 11434) reveals exposed instances. Running the container as a non-root user with a read-only root filesystem would have blocked the escalation even if the write succeeded.

How to prevent it

• Upgrade to Ollama 0.1.34 or later.
• Never expose an Ollama server directly to the internet; put authentication and a network boundary in front of it.
• Run the container as a non-root user with a read-only root filesystem and dropped capabilities, so an arbitrary write cannot reach ld.so.preload.
• Validate and canonicalize any registry-supplied field before using it in a filesystem path.

The Breachwire test (red → green)

Send a crafted manifest whose digest field encodes a path-traversal write target and confirm a file lands outside the model directory (RED — arbitrary write proven). Patch, drop to non-root with a read-only FS, then confirm the same payload is rejected and stays inside the store, while a legitimate ollama pull of a real model still succeeds.