Probllama: What the Ollama RCE Teaches About Self-Hosted AI

In May 2024, Wiz Research reported a remote code execution vulnerability in Ollama, one of the most widely used tools for running language models locally. It was fixed fast. What makes it worth a brief two years on is not the bug: it is the deployment defaults that turned an input-validation slip into unauthenticated remote code execution, because those defaults are still the norm across self-hosted AI.

High Path traversal to arbitrary file write, escalating to RCE. Remote and unauthenticated in the default Docker configuration.

What happened#

Ollama's /api/pull endpoint downloads models from a registry using a manifest that references content by digest. The server did not validate that the digest was what it claimed to be: a SHA-256, sixty-four hex characters. A manifest supplying a digest containing a ../ sequence was treated as a path, letting an attacker direct a write outside the intended blobs directory.

Arbitrary file write on a server is rarely the end state. By overwriting a file the process later executes or loads, an attacker turns the write into code execution.

1. 2024-05-05
   Wiz Research reports the vulnerability to Ollama; Ollama acknowledges and commits a fix the same day.
2. 2024-05-08
   Ollama releases version 0.1.34 with the fix.
3. 2024-05-31
   CVE-2024-37032 published to the NVD and GitHub Advisory Database.
4. 2024-06-24
   Wiz publishes its write-up; a large number of exposed instances remain unpatched.

The vendor response was genuinely fast: a fix committed within about four hours and shipped in three days. The gap that remained was on the operator side: weeks later, many internet-facing instances were still running vulnerable versions.

Why it was severe#

The bug alone is a path traversal. What raised it to critical was the environment it usually ran in.

Ollama's Docker image runs the server as root and binds to 0.0.0.0 (every interface) with no authentication. Ollama has no built-in authentication at all; it assumes something in front of it provides that. A great many deployments put nothing in front of it. The result was a root-privileged, internet-exposed service with an arbitrary-write primitive and no login.

What to do#

If you run Ollama:

• Upgrade to 0.1.34 or later. The parsing flaw is fixed there; do not attempt to mitigate it in place.
• Confirm what the service binds to. If it listens on 0.0.0.0, either bind it to localhost or put it behind a reverse proxy that requires authentication.
• Do not run it as root where you can avoid it, and treat network exposure as the exception that must be justified, not the default.

The broader move is to stop treating "self-hosted AI runtime" as if it implies "internally trusted service". These tools optimise for a fast local start, and a fast local start means no authentication and a permissive bind. That is a reasonable default for a laptop and a dangerous one for a server.

The pattern to watch#

Probllama is one clean, well-documented instance of a recurring shape: AI infrastructure that ships to move fast, assumes a trusted network, and ends up on the open internet anyway. The same assumption sits under model servers, vector databases, inference gateways, and notebook environments across the ecosystem.

When you bring any such component into your stack, ask the boring questions first. What does it bind to out of the box? What authentication does it enforce by default? What privileges does its container run with? For a surprising share of AI tooling the answers are all interfaces, none, and root. As the model supply chain keeps demonstrating, that combination is only ever one input-validation bug away from an incident.