Originally published at HOL
Ollama can be made to call an internal host while pulling a tensor model. A registry controlled by an attacker can return a tensor-layer manifest whose blob request redirects to a private address, including a cloud metadata endpoint. The pull API does not require the victim to log in.
This is a second redirect path beside the earlier Ollama download flaw tracked as CVE-2026-5530. That earlier fix added a redirect check in server/download.go, but tensor models use the separate x/transfer/ downloader. In the v0.33.2 source, resolve() accepts a cross-host Location and returns it to the download client.
What breaks
When a client asks Ollama to pull a model, the server fetches the model manifest and then downloads its layers. Tensor layers go through x/transfer/download.go. Its redirect loop treats a 302, 303, or 307 response from a blob endpoint as a new URL. If that URL has a different host, the code returns it without checking whether the destination is private, loopback, link-local, or otherwise internal.
An attacker therefore needs a registry or model reference that they control, not a valid Ollama account. Their manifest can point a tensor blob at a server that answers with a redirect to http://169.254.169.254/latest/meta-data/, a service on the Ollama host's private network, or another reachable internal address. The downloader then issues the redirected GET. The issue reporter validated repeated requests from an Ollama container to an internal listener across the built-in retry attempts.
Why the earlier fix does not cover this
Ollama's non-tensor download path now installs a CheckRedirect callback that permits same-host redirects and stops at the first different hostname. That guard is in server/download.go. It is not shared by the tensor transfer package. The tensor path uses its own manual redirect handling and still has the unsafe cross-host return in the v0.33.2 tag.
Two upstream fixes reference the issue. PR #17082 proposes rejecting local, private, and link-local destinations, including DNS rebinding and proxy cases. PR #18021 adds a redirect guard that resolves destination names and fails closed when DNS validation fails. Those proposals were open at the time of the original publication. The released v0.34.2 source now contains redirect-target validation in x/transfer, while v0.34.1 still returned a cross-host Location without target validation.
How to fix
Upgrade to Ollama v0.34.2 or later. Released-source comparison shows v0.34.1 still returning cross-host redirects without target validation, while v0.34.2 validates redirect targets in the tensor transfer path. The CVE/NVD record does not itself identify the first fixed release, so this floor comes from the released source.
- Do not let untrusted users submit arbitrary model references to an Ollama server.
- Restrict outbound traffic from the Ollama process. Block cloud metadata addresses, loopback, RFC 1918 ranges, link-local ranges, and other internal destinations at the host or container network boundary.
- Prefer a curated internal registry and allowlist its hostname. This reduces exposure but does not replace egress filtering.
- Watch Ollama logs and network telemetry for pull requests followed by connections to private or link-local addresses.
To check an installation before approving a pull, run ollama --version and compare it with the vendor's release notes. Do not treat v0.33.2 or v0.34.1 as fixed for this issue. A source build should also be checked for a redirect guard in x/transfer/download.go, not only the older guard in server/download.go.
What this is not
This is not a direct Ollama shell takeover, and the issue does not show that every Ollama deployment is reachable from the public internet. The attacker still needs a victim server to process a model reference or registry they control, while the impact depends on what the Ollama host can reach and what its network returns.
Operator takeaway
Upgrade to v0.34.2 or later first. Network egress controls remain defense in depth for deployments that can reach cloud metadata, internal APIs, or other sensitive services.
The source record is available in HOL Guard. Primary technical references are the Ollama issue, the v0.33.2 downloader source, and the CNA advisory.
