# Probllama: What the Ollama RCE Teaches About Self-Hosted AI > CVE-2024-37032, Probllama, was a path-traversal flaw in Ollama's model-pull endpoint that let an attacker overwrite files and reach remote code execution, made worse because the default Docker image runs as root on all interfaces with no authentication. It was fixed in version 0.1.34. The lesson: self-hosted AI runtimes inherit no authentication by default. Source: https://hackerlogs.com/blog/probllama-ollama-rce Published: 2026-09-05 ## Key takeaways - Probllama (CVE-2024-37032) turned insufficient digest validation in Ollama's /api/pull endpoint into arbitrary file write and remote code execution. - The default Docker deployment runs as root and binds 0.0.0.0 with no authentication, which is what turned a bug into remote, unauthenticated RCE. - Ollama committed a fix within hours and shipped it in 0.1.34; weeks later a large number of exposed instances were still unpatched. - The class is not specific to Ollama: model runners, vector stores, and notebook servers routinely ship with no auth and assume a trusted network. - Treat any self-hosted AI runtime as unauthenticated by default and put it behind a reverse proxy that is not. 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. 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. 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. > The vulnerability is the input-validation flaw. The exposure is the deployment: root, all interfaces, no authentication. Patching fixes the first. Only your architecture fixes the second, and the second is what made this remotely exploitable. ## 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](/topics/model-supply-chain) keeps demonstrating, that combination is only ever one input-validation bug away from an incident. ## Sources - [Probllama: Ollama Remote Code Execution Vulnerability (CVE-2024-37032)](https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032) (2024-06-24) - [CVE-2024-37032: GitHub Advisory GHSA-8hqg-whrw-pv92](https://github.com/advisories/ghsa-8hqg-whrw-pv92) (2024-05-31) - [NVD: CVE-2024-37032](https://nvd.nist.gov/vuln/detail/CVE-2024-37032)