CVE-2026-108836: Ollama Pull API SSRF Vulnerability

CVE-2026-108836 Overview

CVE-2026-108836 is a server-side request forgery (SSRF) vulnerability in Ollama versions up to and including 0.34.1. The flaw resides in the IsValid function within types/model/name.go, which is reached through the Pull API component. An unauthenticated attacker can send a crafted request over the network to coerce the Ollama server into issuing arbitrary HTTP requests to attacker-controlled or internal destinations. The issue is tracked as CWE-918: Server-Side Request Forgery. A public exploit disclosure exists, and upgrading to version 0.34.2 resolves the vulnerability.

Critical Impact
Remote, unauthenticated attackers can abuse the Ollama Pull API to coerce the server into making outbound requests to internal services, enabling reconnaissance and interaction with resources otherwise isolated from the public network.

Affected Products

Ollama versions up to and including 0.34.1
Ollama Pull API component (types/model/name.go)
Fixed in Ollama release v0.34.2

Discovery Timeline

2026-10-12 - CVE-2026-108836 published to the National Vulnerability Database
2026-10-13 - Last updated in NVD database

Technical Details for CVE-2026-108836

Vulnerability Analysis

The vulnerability is a server-side request forgery condition in Ollama's model-pull workflow. When a client requests a model pull, the server resolves the registry base URL and subsequently initiates HTTP transfers through the transfer.Download routine. Prior to the fix, redirect handling during registry requests did not restrict the server from following redirects into private address space. An attacker able to reach the Pull API can therefore request a model from a controlled registry that returns redirects pointing at internal IPs, localhost services, or cloud metadata endpoints. The server will dereference those targets while carrying any attached credentials or network trust associated with the Ollama host.

Root Cause

The IsValid validation in types/model/name.go does not enforce safe destination constraints on registry hosts, and the download pipeline previously followed redirects without differentiating between public and private hosts. The patch (dfabde4539e42ba1e1eab50a3a50b88aea7958a0) introduces an explicit AllowPrivateHosts flag that is only set when the registry is marked as Insecure, closing the implicit trust that previously allowed redirects into private networks.

Attack Vector

Exploitation is network-based, requires no authentication, and no user interaction. An attacker issues a Pull API request referencing a hostile registry; the registry responds with HTTP redirects to internal destinations such as 127.0.0.1, RFC1918 ranges, or 169.254.169.254 (cloud metadata). The Ollama process performs those requests on behalf of the attacker.

// Patch excerpt: server/images.go
// Explicitly gates private-host redirects behind the Insecure flag.
if err := transfer.Download(ctx, transfer.DownloadOptions{
    Blobs:             blobs,
    BaseURL:           baseURL,
    DestDir:           destDir,
    Repository:        n.DisplayNamespaceModel(),
    BodyConcurrency:   max(1, int(envconfig.MaxTransferStreams())),
    Progress:          progress,
    Token:             regOpts.Token,
    GetToken:          getToken,
    Logger:            slog.Default(),
    AllowPrivateHosts: regOpts != nil && regOpts.Insecure,
}); err != nil {
    return err
}
// Source: https://github.com/ollama/ollama/commit/dfabde4539e42ba1e1eab50a3a50b88aea7958a0

// Patch excerpt: x/transfer/download.go
// New downloader field enforces the private-host decision at transfer time.
progress     *progressTracker
speeds       *speedTracker
logger       *slog.Logger
allowPrivate bool
// Source: https://github.com/ollama/ollama/commit/dfabde4539e42ba1e1eab50a3a50b88aea7958a0

Detection Methods for CVE-2026-108836

Indicators of Compromise

Outbound HTTP requests from the Ollama process to RFC1918 ranges, loopback addresses, or 169.254.169.254 immediately following a /api/pull call.
Pull API requests referencing non-standard or newly observed registry hostnames.
HTTP 3xx responses received by Ollama from external registries that redirect to internal hosts.

Detection Strategies

Inspect reverse-proxy or application logs for /api/pull requests originating from untrusted networks, and correlate with egress traffic from the Ollama host.
Enable DNS logging on the Ollama server and alert on resolutions of internal zones initiated by the Ollama binary.
Baseline the registry hosts the Ollama service is expected to contact and alert on deviations.

Monitoring Recommendations

Monitor process-level network telemetry from the ollama binary for connections to private address space or cloud metadata endpoints.
Track Ollama version strings in asset inventory and flag any instance running 0.34.1 or earlier.
Alert on HTTP redirect chains terminating at internal services for registry-bound traffic.

How to Mitigate CVE-2026-108836

Immediate Actions Required

Upgrade Ollama to version 0.34.2 or later, which contains the fix in commit dfabde4539e42ba1e1eab50a3a50b88aea7958a0.
Restrict network exposure of the Ollama API so the Pull endpoint is not reachable from untrusted networks.
Audit recent Pull API usage for requests referencing unknown registries.

Patch Information

The fix is published in Ollama Release v0.34.2 and merged via Pull Request #18512. The relevant commit details introduce an AllowPrivateHosts option that defaults to false and is only enabled when the registry is explicitly marked insecure. Additional tracking is available in the VulDB CVE-2026-108836 entry.

Workarounds

Place Ollama behind a reverse proxy that filters outbound redirects and blocks responses whose Location header points to private address space.
Enforce egress firewall rules on the Ollama host that deny traffic to RFC1918 ranges, loopback, and cloud metadata endpoints.
Require authentication at the network layer for the Ollama API until the upgrade is deployed.

bash

# Example egress restriction using iptables on the Ollama host
iptables -A OUTPUT -m owner --uid-owner ollama -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner ollama -d 10.0.0.0/8     -j REJECT
iptables -A OUTPUT -m owner --uid-owner ollama -d 172.16.0.0/12  -j REJECT
iptables -A OUTPUT -m owner --uid-owner ollama -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner ollama -d 127.0.0.0/8    -j REJECT