Ollama: model pull follows cross-host redirects, giving SSRF to internal and metadata endpoints

Impact

When pulling tensor-layer models, Ollama does not validate the destination of a redirect, so a registry the server is pointed at can steer blob downloads to any host the server can reach. The advisory calls out cloud metadata endpoints explicitly: on a GPU node, 169.254.169.254 usually hands back the instance service-account token, which is what makes this more than a curiosity - a model pull turns into credential disclosure for whatever role the node carries, and on a shared cluster that role often reaches object storage holding other tenants' datasets and checkpoints. VulnCheck lists 0.30.0 through 0.33.2 as affected. Impact is read/exfiltration of responses, not code execution.

Who can reach it

Unauthenticated with respect to Ollama itself: whoever controls the registry or the manifest being pulled. That includes anyone who can get your operators to pull a model from a hostile registry, and - where the Ollama API is exposed to tenants or to a notebook network - any caller who can issue a pull request to it. No credentials on the Ollama side are needed.

What to do

The record points to an open upstream issue and does not name a fixed release, so treat this as mitigate-only for now: block egress from inference nodes to link-local and internal address ranges, require IMDSv2 with a hop limit of 1 (or the equivalent metadata hardening on your cloud), restrict model pulls to registries you control, and keep the Ollama API off any network a tenant can reach. All of that is config and network policy - no node drain or reboot. Re-check the upstream issue for a fixed version before relying on the mitigations long term.

References

Related entries

• Axolotl: multipack patch loads Hugging Face base models with trust_remote_code=True, giving RCE on the training nodeCVE-2026-86169 · Axolotl (multipack patch path, trust_remote_code guard)High
• vLLM: rejected requests leak decode-worker metadata until the worker exhausts memoryCVE-2026-93436 · vLLM NIXL KV connector (decode-side metadata cleanup for rejected requests)High
• vLLM: negative token IDs in embeddings requests poison the CUDA context and wedge the engineCVE-2026-93592 · vLLM (/v1/embeddings and /pooling token ID validation)High
• vLLM: incomplete NIXL kv_transfer_params kills the decode engine with an uncaught KeyErrorCVE-2026-94622 · vLLM NIXL KV connector (kv_transfer_params metadata handling)High
• vLLM: multi-prompt completion request trips a NIXL prefix-caching assertion and kills the decode workerCVE-2026-94623 · vLLM NIXL connector prefix caching (NixlBaseConnectorWorker._apply_prefix_caching)High
• vLLM: attacker-chosen P2P offload peers exhaust ZeroMQ contexts and crash EngineCoreCVE-2026-94624 · vLLM P2P KV offloading (OffloadingConnector TieringOffloadingSpec, ZeroMQ control)High