CVE-2024-37032

What it actually does

Ollama versions before 0.1.34 fail to strictly validate model blob digests before converting them into filesystem paths. A valid digest should be a sha256 value with exactly 64 hexadecimal characters, but vulnerable code accepts malformed values, including values with path traversal sequences such as ../. When an exposed Ollama API processes such a digest, the attacker-controlled value can influence the resolved blob path outside the intended model blob directory. Depending on the endpoint and operation reached, this can enable unauthorized filesystem access patterns such as probing for file existence, reading or writing model-related blob paths, or manipulating files outside the expected model storage area under the privileges of the Ollama process.

Why it matters to the business

Organizations running exposed or internally reachable vulnerable Ollama services risk compromise of systems used for local AI model hosting. Because Ollama is often deployed on developer workstations, GPU servers, research systems, and internal automation hosts, exploitation could expose sensitive model artifacts, configuration files, tokens stored near the service account, or allow filesystem tampering that disrupts model availability. The issue has weaponized exploit maturity and a very high EPSS score, so vulnerable internet-facing instances should be treated as high-priority even though it is not currently listed in CISA KEV and has not been flagged as ransomware-associated.

How an attack unfolds

An attacker first identifies an Ollama service reachable over the network, commonly by finding the default API port or recognizable Ollama HTTP responses. The attacker then sends crafted requests to API functionality that references model blobs by digest. Instead of supplying a canonical sha256 digest with 64 hexadecimal characters, the attacker supplies a malformed digest containing traversal syntax such as ../ or encoded traversal variants. On vulnerable versions, the server fails to reject the malformed digest and resolves a filesystem path derived from the attacker-controlled value. The attacker can then use differences in HTTP responses, status codes, errors, or side effects to determine whether files exist or to interact with paths outside the intended blob directory, depending on the exposed API method and permissions of the Ollama process. Successful exploitation is most damaging when the Ollama API is exposed without network controls, runs with broad filesystem permissions, or shares a host with sensitive developer, model, credential, or automation assets.

How to fix it

Upgrade Ollama to version 0.1.34 or later. For source-based deployments, ensure the code includes the upstream fix commit adeb40eaf29039b8964425f69a9315f9f1694ba8 or a later commit containing the same digest validation behavior. After upgrading, restart the Ollama service so the patched binary is active. As defense in depth, do not expose the Ollama API directly to the internet; restrict access with host firewalls, private networking, VPN, reverse-proxy authentication, or service mesh policy. Run Ollama with a dedicated low-privilege service account, limit filesystem permissions to the required model directories, and avoid storing credentials or sensitive files in locations readable or writable by the Ollama process. If immediate upgrade is not possible, block requests containing path traversal sequences or malformed digest values at a reverse proxy/WAF and restrict the service to trusted hosts only, but treat these as temporary mitigations rather than a complete fix.

How to confirm the fix worked

Confirm the running Ollama version is 0.1.34 or later, or verify the deployed source contains commit adeb40eaf29039b8964425f69a9315f9f1694ba8 or a later fixed revision. Validate that the service process was restarted after upgrade and that no older vulnerable binary remains active. From a controlled test host, send benign negative tests to blob-related API paths using malformed digest values such as a digest shorter than 64 hex characters, longer than 64 hex characters, non-hex characters, and traversal-like values; a fixed server should reject these inputs without resolving paths outside the model blob directory. Review network exposure to ensure the Ollama API is not reachable from untrusted networks. Check package inventories, container images, systemd units, launch agents, and developer workstation tooling for embedded or manually installed Ollama versions that may not be covered by standard package management.

Typical attack path

1. Discover an exposed Ollama API endpoint, often on the default service port or through internet scanning.
2. Confirm the service is Ollama and infer whether it may be a vulnerable pre-0.1.34 build.
3. Target blob/model API routes that accept a digest value.
4. Submit malformed sha256 digest values that are shorter or longer than expected, non-hexadecimal, or contain traversal sequences such as ../.
5. Observe response codes, error messages, timing, or file-operation side effects to determine whether path traversal is accepted.
6. Use the traversal primitive to probe, read, write, or otherwise affect files reachable by the Ollama process, constrained by the specific endpoint behavior and process permissions.
7. Leverage any exposed files, credentials, or service disruption to expand access or impact the AI/model hosting environment.

How to detect it

Look for evidence in Ollama service logs, reverse proxy logs, web access logs, load balancer logs, WAF events, EDR telemetry, and host filesystem audit logs. Focus on requests to blob or model endpoints where the digest is malformed, contains traversal sequences, or is URL-encoded to hide traversal. Suspicious patterns include /api/blobs/ requests with ../, %2e%2e, %2f, backslash traversal, sha256 values that are not exactly 64 hexadecimal characters, or unusually long digest strings. Review HTTP status codes and response sizes for probing behavior, especially repeated HEAD/GET/POST requests with varying traversal depth. On the host, examine the Ollama model storage directories and parent directories for unexpected file creation, modification, or access timestamps matching suspicious requests. Common model storage locations to inspect include ~/.ollama/models/blobs, /usr/share/ollama/.ollama/models/blobs, and Windows user-profile .ollama\models\blobs paths, as well as nearby directories that should not normally be modified by Ollama. Correlate suspected requests with process telemetry for the Ollama process, file-open events outside expected model directories, unexpected child processes, and credential access. Because exploitation is weaponized and EPSS is high, absence of KEV status should not be used to lower detection priority for exposed services.

• /api/blobs/sha256:../
• /api/blobs/sha256:..%2f
• /api/blobs/sha256:%2e%2e%2f
• /api/blobs/sha256:%2e%2e/
• /api/blobs/sha256:..\\
• /api/blobs/sha256:%2e%2e%5c
• /api/blobs/sha256:%252e%252e%252f
• /api/blobs/sha256:/
• /api/blobs/sha256:%2f
• /api/blobs/sha256:%5c
• /api/blobs/sha256:....//
• /api/blobs/sha256:..;/
• /api/blobs/sha256:..%252f
• /api/blobs/sha256:..%c0%af
• /api/blobs/sha256:..%ef%bc%8f
• /api/blobs/sha256:etc/passwd
• /api/blobs/sha256:../../
• HEAD /api/blobs/sha256:../
• GET /api/blobs/sha256:../
• POST /api/blobs/sha256:../
• ~/.ollama/models/blobs
• /usr/share/ollama/.ollama/models/blobs
• .ollama\\models\\blobs

What your security team should do

• Immediately identify all Ollama deployments, including developer workstations, GPU servers, containers, notebooks, and internal AI tooling hosts.
• Prioritize patching any Ollama instance reachable from the internet, shared networks, CI/CD systems, or untrusted users to version 0.1.34 or later.
• Restrict Ollama API access to trusted networks and authenticated control planes; do not rely on the service being safe when openly exposed.
• Review reverse proxy, load balancer, web server, endpoint, and Ollama logs for malformed blob digest requests and traversal attempts.
• Run the Ollama service as a dedicated low-privilege account with access only to required model storage paths.
• Inspect model storage directories and adjacent filesystem locations for unexpected files or modification times around suspicious requests.
• If suspicious traversal attempts are found, preserve logs and filesystem metadata, rotate credentials accessible to the Ollama process, and perform host-level forensic triage.
• Add SIEM detections for /api/blobs requests containing ../, URL-encoded traversal, or sha256 digest values that are not exactly 64 hexadecimal characters.