criticalCVSS 9.8|ollama (github)|

CVE-2024-37032Path traversal in Ollama (\"Probllama\") allowing remote code execution via crafted model manifests.

Affected
<0.1.34
Patched in
0.1.34
Ecosystem
github
ollamapath-traversalrceaiself-hosted

What's the vulnerability?

Ollama is the most popular way to run open-weights LLMs (Llama 3, Mistral, Phi, Gemma, Qwen) on your own hardware. It exposes an HTTP API — by default on 127.0.0.1:11434 — that pulls models from a registry and serves chat completions.

CVE-2024-37032, nicknamed "Probllama" by the Wiz researchers who reported it, is a path-traversal-to-RCE in Ollama's model-pull endpoint. A crafted model manifest could include digest paths containing ../ segments. When Ollama wrote those files to disk, they escaped the model directory — and because one of the files Ollama processed during pull was loaded into the server process, an attacker who controlled the manifest could overwrite arbitrary files and ultimately get remote code execution as the user running Ollama. The CVSS 3.1 score is 9.8 (Critical), AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Realistic exploitation scenario

Two flavours, both real:

  1. Internet-exposed Ollama. Ollama binds to localhost by default, but a non-trivial number of users set OLLAMA_HOST=0.0.0.0 to share a workstation across the team or expose it to a homelab. Wiz reported finding thousands of internet-reachable instances when the CVE landed. An unauthenticated POST /api/pull against any of those, pointing at an attacker-controlled registry, was enough.
  2. Internal Ollama with SSRF or internal access. Even on 127.0.0.1, anything that can issue HTTP requests on the host — a chat plugin, a Jupyter kernel, a misconfigured reverse proxy, an SSRF in a sidecar — can hit the API. CVSS 9.8 stays 9.8 once an attacker is on the network segment.

The attacker doesn't need a real model. They need the Ollama process to do os.MkdirAll and os.Create against a path containing ...

Who's affected

Anyone running Ollama <0.1.34. That covers:

  • Self-hosted Ollama servers on Linux/macOS/Windows.
  • Containerised deployments (the official Docker images on Docker Hub were vulnerable until the bump).
  • Kubernetes deployments using Helm charts that pinned an older appVersion.
  • LangChain / LlamaIndex / Continue / Open WebUI stacks built on top of Ollama before they were updated.

How to detect it in your repo

# Running Ollama version (against the API)
curl -s http://127.0.0.1:11434/api/version

# Container images — check for old digests
docker images | grep ollama
grep -RniE 'ollama/ollama:(0\.1\.[0-9]|0\.1\.[12][0-9]|0\.1\.3[0-3])' . 2>/dev/null

# Helm / Kustomize / Compose pins
rg -n "ollama" -g "*.yaml" -g "*.yml" -g "*.tf" -g "Dockerfile*" -g "compose*" .

# Is the API reachable beyond localhost?
ss -tlnp | grep 11434

Anything <0.1.34 is vulnerable. If you see OLLAMA_HOST=0.0.0.0 or --host 0.0.0.0 anywhere in your infra, treat that host as untrusted until it's both upgraded and put behind authentication.

The fix

Upgrade to Ollama 0.1.34 or later. The current stable release stream is well past 0.3, so patching usually means a minor-version bump:

# Native install
curl -fsSL https://ollama.com/install.sh | sh

# Docker
docker pull ollama/ollama:latest

# Kubernetes / Helm
helm repo update && helm upgrade ollama ollama/ollama

Hardening that pairs well with the patch:

  • Bind to 127.0.0.1 and front with an authenticated reverse proxy (Caddy, Traefik, oauth2-proxy).
  • Don't run Ollama as root — drop privileges or use a dedicated ollama user.
  • Pin specific model digests (ollama pull <name>@sha256:...) and only pull from registries you trust.

Why this one matters more than the CVSS suggests

Self-hosted AI runtimes are the new attack surface. They're often run by individuals who think of them as desktop apps but who put them on cloud GPUs to save money — and "I'll just expose it to my team for a week" turns into a permanent 0.0.0.0 bind. CVE-2024-37032 is the canonical example: a serious bug in a piece of software that wasn't on most security teams' inventories until last week.

If your org has a gpu-tagged worker pool, an mlops team, or a Slack channel where someone shared an Ollama URL, you have an Ollama exposure surface. Audit it.

How RepoWarden handles this

RepoWarden tracks more than package.json. For repos that include Dockerfiles, Helm charts, Compose files, or Terraform manifests, RepoWarden:

  1. Detects pinned Ollama versions and image tags across all supported manifest formats.
  2. Maps those pins against the GitHub Advisory Database (which carries CVE-2024-37032 as GHSA-81rv-mff9-7r4w).
  3. Opens a PR that bumps the pin, updates the Helm appVersion or Compose tag, and links the advisory in the description.
  4. Flags 0.0.0.0 binds in scanned manifests as a separate hardening recommendation, so patching the CVE doesn't silently re-expose the service.

The same machinery that closes npm CVEs in a coffee-break closes container-image CVEs in self-hosted AI tooling.

References

RepoWarden patches CVEs like this automatically.

Continuous scanning for github dependencies, with PRs that ship the fix and pass your CI before you've finished reading the advisory.

Try it free →
← All CVEs