Ollama Pull API SSRF (CVE-2026-108836): Medium-Severity Flaw in Versions Up to 0.34.1, With a Public Exploit

CVE-2026-108836 is a server-side request forgery (SSRF) flaw in the pull API of Ollama up to and including 0.34.1. An advisory published on 12 October 2026 says the exploit has been disclosed publicly and upgrading to 0.34.2 fixes it. We found no report of exploitation in the wild, and the CVE is not in CISA's Known Exploited Vulnerabilities (KEV) catalog as of 13 October. The risk is mainly for operators who exposed port 11434 beyond localhost.

What happened

NVD and the GitHub Advisory Database both published the record on 12 October (GHSA-fr42-jr2w-mx59). The description reads: "A vulnerability has been found in Ollama up to 0.34.1. The affected element is the function IsValid of the file types/model/name.go of the component Pull API. The manipulation leads to server-side request forgery." The weakness is CWE-918. NVD lists 0.34.0 and 0.34.1 as affected and 0.34.2 as unaffected. The GitHub advisory text adds that the attack can be started remotely and that the exploit "has been disclosed to the public and may be used".

Why it matters

Ollama's pull API makes the server fetch model data over HTTP on the caller's behalf. An SSRF in that path lets an outsider borrow the server's network position, which can include internal services the attacker cannot reach directly (we covered a similar MCP Fetch Server SSRF).

Exposure is the deciding factor. Ollama listens on 127.0.0.1:11434 by default, so a stock desktop install is not reachable from the network. Our earlier article on CVE-2026-103663 found that the official Docker image sets OLLAMA_HOST=0.0.0.0:11434, so container deployments with a published port are reachable by anyone who can reach that port.

For scale, the OpenA2A April 2026 exposure sweep (scan date 11 April 2026) identified 25,036 hosts as Ollama using Shodan's product:"Ollama" signature. That is six months old and counts exposed Ollama servers of any version, not vulnerable ones (other self-hosted AI servers, such as LightLLM's visual nodes, have also been left reachable). The same project's March figure of 224,551 came from a raw port 11434 query, and the report says the port number over-counts real instances by roughly nine times. We found no current dated count of vulnerable servers, so we do not give one.

Technical details

The CVE text names IsValid in types/model/name.go. The commit it references does not touch that file. Commit dfabde4 (PR #18512, by Patrick Devine, dated 17 September 2026) is titled "x/transfer, server: tighten redirect handling for registry requests", and changes server/images.go and the x/transfer package. According to the commit message and diff, redirects for registry and blob transfers now:

• validate the target scheme and resolved addresses before being followed;
• re-check DNS on each redirect and dial a pinned IP, which blocks DNS rebinding;
• refuse targets that are not public: loopback, private, link-local and unspecified addresses, plus the carrier-grade NAT range 100.64.0.0/10 (the code comment cites Alibaba Cloud metadata at 100.100.2.148) and 198.18.0.0/15;
• refuse a redirect from an https session to plain http.

The --insecure option still relaxes address checks for private registries but not scheme checks.

Read together, the patch suggests the practical chain is: an API client that can reach the pull endpoint asks the server to pull from a registry it controls, and that registry redirects the transfer to an internal address. That is our inference from the diff; the CVE record does not spell out the chain, and the vendor has not published an advisory of its own. We did not test it.

Scoring: why the numbers disagree

NVD shows three scores, all supplied by VulDB (cna@vuldb.com); NVD has not added its own. GitHub's advisory carries the same two modern vectors.

This is one assessment scored under different versions, not a dispute. The 3.1 vector rates low impact on confidentiality, integrity and availability with no authentication and low complexity, and scores 7.3. The 4.0 vector rates low impact on confidentiality, integrity and availability, none on subsequent systems, and sets exploit maturity to proof-of-concept (E:P), giving 5.5. GitHub labels the advisory medium. We treat it as medium: the impact ratings are all "low", and the main risk is reaching internal services rather than direct code execution. We could not read VulDB's own page (it returned 403 to us), so the VulDB figures here come through NVD.

What defenders should do

• Upgrade to 0.35.0 or later. 0.34.2 contains the SSRF fix, but the earlier path traversal, CVE-2026-103663, affects 0.34.2 up to but not including 0.35.0. The latest stable release we saw was v0.40.3 (11 October).
• Do not expose port 11434. Keep Ollama on loopback or a private interface, and put authentication or a network allowlist in front of any shared instance. Check OLLAMA_HOST, published container ports and reverse proxies.
• Firewall outbound traffic from inference hosts. Block access to cloud metadata addresses and internal admin interfaces that the model server has no need to reach.
• Review logs on any previously exposed instance for unexpected /api/pull requests from unfamiliar clients, particularly ones naming unknown registries.
• Because a public exploit exists, treat patching as a matter of days for any internet-reachable instance. For loopback-only installs, it is routine maintenance.

What is still unclear

• The v0.34.2 release page shows a 15 September publish date, but the release was re-cut: the v0.34.2 tag points at the fix commit (17 September), the release object was created on 17 September and its assets were uploaded that evening. Docker Hub shows ollama/ollama:0.34.2 pushed on 17 September. So 0.34.2 as shipped contains the redirect hardening, as the CVE says. A later release, 0.34.3, re-allows cross-host redirects among allowlisted hosts after 0.34.2 broke some Hugging Face pulls.
• The v0.34.2 release notes do not mention a security fix.
• The CVE names IsValid, while the commit changes redirect handling. Whether these describe the same flaw is not documented.
• No exploit code is linked here. We have not found vendor guidance, a current exposure count, or evidence of in-the-wild exploitation.

Sources

• NVD record for CVE-2026-108836
• GitHub advisory GHSA-fr42-jr2w-mx59
• Ollama PR #18512
• Commit dfabde4
• Ollama v0.34.2 release
• Ollama releases
• CISA KEV catalog
• OpenA2A April 2026 exposure sweep
• ThreatFrontier: CVE-2026-103663