Ollama EUVD-2026-97364

The Ollama HTTP API (which runs without authentication by default) must be network-reachable so an attacker can invoke the Pull API; exploitation then relies on the server following HTTP redirects across hosts when contacting a model registry, letting an attacker-controlled or malicious registry steer manifest/blob requests to internal addresses. The fix (v0.34.2) enforces a default same-host-only redirect policy and only follows cross-host redirects when the operator explicitly sets --insecure, so vulnerable behavior is the pre-0.34.2 default. Limiting factors: impact is confined to SSRF with LOW confidentiality/integrity/availability (no direct RCE), the instance must be exposed (localhost-only bindings are not remotely reachable), and abuse requires the victim server to initiate a pull toward attacker-influenced registry/redirect targets.

This is a medium-severity SSRF (CWE-918) in Ollama's Pull API, and the signals are internally consistent rather than conflicting. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VC:L/VI:L/VA:L, score 5.5) indicates a remotely reachable, low-complexity, unauthenticated flaw with only LOW impact to confidentiality, integrity, and availability - appropriate for an SSRF that lets the server be steered at other hosts rather than yielding direct code execution. The E:P flag in the vector denotes a proof-of-concept exploit, and the description explicitly states the exploit was publicly disclosed, so this is best treated as: publicly available exploit code exists. There is NO CISA KEV listing and NO EPSS score provided in the input, so there is no evidence of active or widespread exploitation - the realistic risk is targeted abuse of internet-exposed Ollama instances rather than mass exploitation. The key real-world caveat is that PR:N/UI:N is only accurate when the Ollama Pull API is network-reachable; Ollama ships without authentication, so an exposed instance genuinely is unauthenticated, but an instance bound to localhost is not remotely exploitable. A second caveat: the NVD description locates the flaw in function IsValid of types/model/name.go, yet the referenced fix commit (dfabde45) actually hardens HTTP redirect handling in server/images.go and x/transfer/download.go (blocking cross-host redirects unless --insecure is set) - verify the precise sink with the vendor, as the description and patch point at different code. Net: a legitimate patch-now item for exposed deployments, but a medium-impact SSRF, not a critical issue.

An attacker reaches an internet-exposed Ollama instance's unauthenticated Pull API and requests a model from an attacker-controlled registry; the registry answers with an HTTP redirect pointing at an internal address (for example a cloud metadata endpoint or an internal service), and the pre-0.34.2 Ollama server follows the cross-host redirect, performing a server-side request to that internal target. A proof-of-concept has been publicly disclosed (CVSS E:P and referenced test repository), lowering the effort to reproduce.