BREAKING: CVE-2026-85180 lets Ollama model pulls reach internal hosts

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 current 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. Both are open and unmerged at the time of publication.

How to fix

No patched Ollama release is available yet. The latest release page identifies v0.33.2, and the vulnerable redirect logic is still present in that tag and on main. Until a fix ships, treat remote model pulls as a server-side network access feature:

• 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 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

If Ollama runs beside cloud credentials, internal APIs, or other sensitive services, its model puller should be treated like a network-capable service. The concrete control that matters now is egress policy: a redirect in an untrusted tensor manifest must not be able to turn a model download into a request to the host's private network.

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.