CVE-2026-85180: Ollama SSRF — HIGH

CISO Take

Ollama's model-pull mechanism follows HTTP redirects returned by a registry without validating the destination host, so a malicious or compromised registry can redirect a tensor-layer blob download to an arbitrary internal address, including the cloud metadata service. This matters because Ollama is one of the most widely deployed self-hosted LLM runtimes, and any deployment running on AWS, GCP, or Azure compute with an unauthenticated Ollama endpoint or a permissive model-pull configuration is a candidate for credential theft via SSRF-to-metadata, a pattern that has repeatedly led to full cloud account compromise in other products. There is no public exploit, no CISA KEV listing, no Nuclei template, and no EPSS score yet, so near-term mass exploitation is unlikely, but the flaw requires no authentication and no user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N) and needs only a registry the attacker controls or can spoof via DNS/MITM. Treat any Ollama instance that pulls models from non-default or third-party registries as exposed until patched, and in the meantime block egress from the Ollama host to link-local and cloud metadata ranges (169.254.169.254, 100.100.100.200) and to internal RFC1918 space. Track the fix referenced in ollama/ollama#17041 and upgrade past v0.33.2 as soon as a patched release ships, restricting `OLLAMA_MODELS` pulls to trusted registries in the interim.

Sources:NVDGitHub Advisoryvulncheck.comATLAS

What is the risk?

High-severity, low-complexity, unauthenticated SSRF (CVSS 7.5, confidentiality-only impact). Exploitability is currently theoretical — no KEV listing, no public PoC, no scanner template, and EPSS is unscored — but the prerequisites are trivial for an attacker who can stand up or spoof a model registry, and the target class (self-hosted LLM inference hosts, frequently deployed in cloud VMs or containers with attached IAM roles) makes successful exploitation high-value. Risk should be rated elevated-but-not-critical today, with a recommendation to re-triage to critical if a PoC or KEV addition appears, given how directly SSRF-to-metadata chains into cloud account takeover.

How does the attack unfold?

Malicious registry setup

Attacker stands up or spoofs a model registry and publishes a tensor-layer manifest configured to redirect the blob download to an internal target.

AML.T0010

Triggered model pull

Victim's Ollama server is directed to pull the model, exploiting the missing redirect-destination validation in the download logic.

AML.T0049

SSRF to internal/metadata host

Ollama follows the redirect and issues a GET request to an internal host or the cloud metadata endpoint, retrieving sensitive data as if it were model content.

AML.T0075

Credential exfiltration and lateral movement

Attacker obtains and uses leaked cloud credentials or internal data to expand access beyond the Ollama host.

AML.T0025

Malicious registry setup

Attacker stands up or spoofs a model registry and publishes a tensor-layer manifest configured to redirect the blob download to an internal target.

AML.T0010

Triggered model pull

Victim's Ollama server is directed to pull the model, exploiting the missing redirect-destination validation in the download logic.

AML.T0049

SSRF to internal/metadata host

Ollama follows the redirect and issues a GET request to an internal host or the cloud metadata endpoint, retrieving sensitive data as if it were model content.

AML.T0075

Credential exfiltration and lateral movement

Attacker obtains and uses leaked cloud credentials or internal data to expand access beyond the Ollama host.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Ollama	pip	—	No patch
185.5K1.9K dependentsPushed yesterday19% patched~29d to patchFull package profile →

Do you use Ollama? You're affected.

How severe is it?

CVSS 3.1

7.5 / 10

EPSS

0.5%

chance of exploitation in 30 days

Higher than 43% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AVNetwork

ACLow

PRNone

UINone

SUnchanged

CHigh

INone

ANone

What should I do?

1 step

1) Upgrade Ollama past the vulnerable range (0.30.0–0.33.2) once a patched release addressing ollama/ollama#17041 is available — confirm the exact fixed version from the vendor advisory before rolling out. 2) Until patched, restrict model pulls to a pinned allowlist of trusted registry hosts and disable pulling from arbitrary/user-supplied registry URLs. 3) Apply network-level egress controls on the Ollama host: block outbound requests to 169.254.169.254, 100.100.100.200, and RFC1918 ranges not explicitly required, or run Ollama in a network namespace/container without a route to the cloud metadata service (use IMDSv2 with hop-limit=1 as a defense-in-depth backstop on AWS). 4) Detection: monitor Ollama server logs and egress proxy/firewall logs for outbound GET requests to metadata IPs or unexpected internal hosts originating from the Ollama process, and alert on any HTTP redirect chain during a model pull that crosses hosts.

What does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableYes

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Supply ChainData LeakageInferenceModelAML.T0010- AI Supply Chain Compromise AML.T0010.003- Model AML.T0049- Exploit Public-Facing Application AML.T0075- Cloud Service Discovery

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

Annex A.6.2-Third-party and supplier relationships

NIST AI RMF

MEASURE 2.7-AI system security and resilience evaluation

OWASP LLM Top 10

LLM03-Supply Chain Vulnerabilities

Frequently Asked Questions

What is CVE-2026-85180?

Ollama's model-pull mechanism follows HTTP redirects returned by a registry without validating the destination host, so a malicious or compromised registry can redirect a tensor-layer blob download to an arbitrary internal address, including the cloud metadata service. This matters because Ollama is one of the most widely deployed self-hosted LLM runtimes, and any deployment running on AWS, GCP, or Azure compute with an unauthenticated Ollama endpoint or a permissive model-pull configuration is a candidate for credential theft via SSRF-to-metadata, a pattern that has repeatedly led to full cloud account compromise in other products. There is no public exploit, no CISA KEV listing, no Nuclei template, and no EPSS score yet, so near-term mass exploitation is unlikely, but the flaw requires no authentication and no user interaction (CVSS 7.5, AV:N/AC:L/PR:N/UI:N) and needs only a registry the attacker controls or can spoof via DNS/MITM. Treat any Ollama instance that pulls models from non-default or third-party registries as exposed until patched, and in the meantime block egress from the Ollama host to link-local and cloud metadata ranges (169.254.169.254, 100.100.100.200) and to internal RFC1918 space. Track the fix referenced in ollama/ollama#17041 and upgrade past v0.33.2 as soon as a patched release ships, restricting `OLLAMA_MODELS` pulls to trusted registries in the interim.

Is CVE-2026-85180 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-85180, increasing the risk of exploitation.

How to fix CVE-2026-85180?

1) Upgrade Ollama past the vulnerable range (0.30.0–0.33.2) once a patched release addressing ollama/ollama#17041 is available — confirm the exact fixed version from the vendor advisory before rolling out. 2) Until patched, restrict model pulls to a pinned allowlist of trusted registry hosts and disable pulling from arbitrary/user-supplied registry URLs. 3) Apply network-level egress controls on the Ollama host: block outbound requests to 169.254.169.254, 100.100.100.200, and RFC1918 ranges not explicitly required, or run Ollama in a network namespace/container without a route to the cloud metadata service (use IMDSv2 with hop-limit=1 as a defense-in-depth backstop on AWS). 4) Detection: monitor Ollama server logs and egress proxy/firewall logs for outbound GET requests to metadata IPs or unexpected internal hosts originating from the Ollama process, and alert on any HTTP redirect chain during a model pull that crosses hosts.

What systems are affected by CVE-2026-85180?

This vulnerability affects the following AI/ML architecture patterns: model serving, LLM inference deployments, AI model supply chain / registry pulls.

What is the CVSS score for CVE-2026-85180?

CVE-2026-85180 has a CVSS v3.1 base score of 7.5 (HIGH). The EPSS exploitation probability is 0.50%.

What is the AI security impact?

Affected AI Architectures

model servingLLM inference deploymentsAI model supply chain / registry pulls

MITRE ATLAS Techniques

AML.T0010AI Supply Chain Compromise

AML.T0010.003Model

AML.T0049Exploit Public-Facing Application

AML.T0075Cloud Service Discovery

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: Annex A.6.2

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM03

What are the technical details?

Original Advisory

Ollama fails to validate redirect destinations when pulling tensor-layer models, allowing unauthenticated attackers to redirect blob downloads to arbitrary hosts. An attacker can control a registry, serve a malicious tensor-layer manifest, and cause the server to issue GET requests to internal hosts including cloud metadata endpoints.

Exploitation Scenario

An attacker stands up a model registry (or compromises/typosquats an existing one) and publishes a model whose tensor-layer manifest points a blob download at a URL that returns an HTTP redirect to `http://169.254.169.254/latest/meta-data/iam/security-credentials/<role>`. A victim organization configures Ollama to pull this model — via a supply-chain trick (a popular-looking model name), a compromised internal mirror, or a user manually pointing Ollama at the attacker's registry. Ollama's download client follows the redirect without re-validating that the new host matches the original registry, issuing the GET request from the trusted server context. The response (cloud credentials or other internal service data) is retrieved as if it were model blob content; if the attacker can also influence how that 'blob' is subsequently stored, logged, or surfaced (e.g., via an error path or a follow-up inference request that echoes cached data), they can exfiltrate the leaked secrets and use them for lateral movement into the victim's cloud account.

Weaknesses (CWE)

CWE-918Server-Side Request ForgeryPrimary CWE-918Server-Side Request Forgery

CWE-918 — Server-Side Request Forgery: The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

[Implementation, Operation] If there is a known list of applications, IP, hostname, and/or domains to which the product is allowed to communicate, then use allowlists to ensure that outgoing requests are restricted to these known entities. The allowlists could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].
[Implementation, Operation] If the product is expected to be able to connect to arbitrary IP addresses or domains, consider using a denylist that includes private network addresses, internal domain names, etc. The denylist could be in the application code or possibly enforced by firewalls or network segmentation [REF-1511].

Source: MITRE CWE corpus.