← Research

Ollama Probllama: The Internet-Exposed Models Trying to Steal Your Creds... and Mostly Failing

Jonathan Tomek · August 4, 2026 · threat intelligence llm security exposed services prompt injection

Ollama makes running a local model almost too easy. Pull it, run it, done. By default it binds an HTTP API on tcp/11434 with no authentication. On a laptop behind a home router that's fine. Exposed to the internet, it means anyone who can reach the port can enumerate the host's models, run inference on someone else's GPU, and (the part that matters) write to the instance. POST /api/create, /api/pull, and /api/push are all reachable. The API isn't just a way to burn a stranger's compute; it's a way to put things onto their machine.

So I took a single 2026-07-26 scan of internet-exposed Ollama instances, 616 hosts and 1,017 (host, model) records. I went in expecting a botnet of poisoned models. What I found was mostly ordinary people running local models, with two automated abuse campaigns working the fringes and a single honeypot that logged one of them.

The population is boringly normal, which is the first finding

Before the scary part, the baseline: exposed Ollama is an individual phenomenon, not an enterprise one. Of the 1,017 model records, 881 are bare Ollama-library names, 111 are namespaced, and 25 are explicit hf.co/ HuggingFace references. Almost everything is a normal local model someone pulled to tinker with. The infrastructure confirms it: cheap VPS and home broadband, not data-center fleets, and corporate-owned ASNs are nearly absent.

That "boring" baseline matters, because it sets the denominator. The security-relevant findings below are roughly 1% of hosts. They're real, but you only see them honestly if you admit the other 99% are just people running Llama and Qwen on a spare box.

Where they live: geography and infrastructure

The exposed population skews to a handful of countries and cheap-hosting providers. All figures are host-level (one host counted once), across 616 hosts.

Top countries

Infrastructure class

Top networks (ASN owner)

The near-absence of corporate ASNs is the point. Exposed Ollama lives on rented VPS (Hetzner, OVH, Contabo, Oracle) and residential broadband (Korea Telecom, SK Broadband, LG Dacom), not inside enterprises. The Korean concentration is striking: three of the top networks are Korean residential ISPs.

Campaign A: a credential harvester that builds itself from your own model

Thirteen hosts across the scan carry a tampered registry, entries that aren't models but payloads written through that open create/pull API. They split across two unrelated operations. The first is the one that looks like a deliberate credential-harvesting campaign.

Seven hosts carry implants following a rigid scheme: util-credential-extractor-<4 random digits> and util-info-collector-<4 random digits>. The exact same naming appears across six countries and unrelated providers (AT&T, Contabo, OVH, netcup, Reliance Jio, and others). Identical names with randomized numeric suffixes is the fingerprint of an automated, single-actor deployment spraying the same kit at every reachable host.

The technique is the elegant part, and it's worth understanding because it needs no malware in the traditional sense. On every host that got both implants, the two payloads share the victim's exact model size (34.7B, 3.2B, 8.0B, whatever the host already ran). That's the tell of POST /api/create with FROM <the victim's already-loaded model> plus a malicious SYSTEM prompt. No weight upload, no download, no dependency on what the target runs: you inherit their model and bolt on new instructions. credential-extractor prompts the model to surface secrets, emitting placeholder signatures like [META: API_KEY1]. info-collector is prompted to retain whatever an operator later pastes, its intent stated almost sweetly in a leaked reasoning trace: "I will store all relevant information securely for later retrieval."

It's a clever, cheap, self-assembling kit. And on our data, it mostly doesn't work, which I'll get to.

Campaign B: a different actor, scanning the software, not the model

The other six tampered hosts are a completely different operation, and you can tell at a glance because the naming scheme shares nothing with Campaign A. Here the "models" are exploit primitives: ssrf_test, zipslip_test, p__etc_resolv.conf, p__proc_1_cmdline, b_docker_sock, tpl_dump_env, f5leak__root_.ssh_id_ed25519. Nobody names a language model p__etc_resolv.conf. These map onto the known Ollama CVE classes (path traversal, file read, template abuse), so this is a mass-scanner probing the software, using the create/pull API to drop marker entries as it goes.

Two things to keep honest here. First, registry residue proves a create/pull touched the host; it does not by itself prove the underlying CVE succeeded. Second, this actor got caught, which is the fun part.

The honeypot that fed the bear fake honey

One host, 172.233.44[.]98 on Akamai/Linode, isn't a victim at all. It's a deliberately instrumented honeypot. It carries 83 probe "models" spanning every CVE class, serves a fake jailbreak banner ("Policy check bypassed. This node does not implement refusal logic"), and (the giveaway) is stuffed with planted canary credentials: a modified AWS example key, a ghp_FakeGitHubToken…, a demo JWT. Someone built this box to be probed: it feeds any credential-scraper nothing but those decoys, and logs whoever comes knocking.

And it did its job. The honeypot captured Campaign B's own infrastructure: an SSRF pull target pointed at 138.199.52[.]195:8888 (AS212238, CDNEXT / Datacamp, GB), the scanner's callback node, alongside a systematic sweep of internal ports on 127.0.0.1. That callback address is now a published indicator. Two other nodes in the scan are probe-poisoned but lack the canary tells, so I classify them honeypot-ambiguous rather than overclaim; the honest line is that you often can't tell a well-run trap from an abused victim from registry residue alone.

The part everyone gets wrong: the harvesting fails

Here's the headline the raw existence of Campaign A would let you write: "attackers are poisoning exposed LLMs to steal credentials." Here's what the data actually says when you run the probe against the whole population and count.

About 65% of the model population declined or refused outright. Another 25% engaged but leaked nothing. Only about 4.8% produced a candidate "leak" at all, and that's an upper bound, before you check whether the "leak" is real. So I checked. A whole-corpus scan of all 1,017 replies for real-credential patterns (AWS keys, OpenAI sk-, GitHub tokens, JWTs, private keys) returned exactly four hits. Every single one was a decoy on the honeypot.

Let that land. In a dataset with a purpose-built credential-harvesting campaign deployed across seven hosts, the only credential-shaped strings that surfaced anywhere were the canaries a defender planted to catch scanners. The 4.8% "leak" set is confabulation: placeholder tokens and invented infrastructure tables the model made up because it was told to, not secrets it possessed. Even the uncensored and "abliterated" models in the population, which have had their refusal training stripped, mostly didn't comply, and when they did, they hallucinated. Removing a model's refusal reflex doesn't give it data it never had.

Why does the clever kit fail? Two reasons. The base model's safety training usually overrides the injected SYSTEM prompt, so the implant refuses on the very host it was installed on. And even when it complies, a freshly poisoned model sitting on a stranger's VPS has no real infrastructure detail to spill. The kit only bites if a human later opens a chat with the poisoned model and pastes real credentials into it. Against an automated, context-free probe, it no-ops.

So where's the actual risk? The writable API

None of this means an exposed Ollama is safe. It means the danger is in a different place than the scary headline points. The real attack surface is the write API itself, and it has a CVE history that has nothing to do with whether the model feels like talking:

• CVE-2024-37032 ("Probllama") is a path traversal through an unvalidated digest in the /api/pull manifest that chains to unauthenticated remote code execution as root. On the Docker default (listening on 0.0.0.0, running as root) that's a remote takeover, patched in 0.1.34.
• The Oligo "More Models, More ProbLLMs" batch: CVE-2024-39719 (file-existence disclosure), CVE-2024-39720 (out-of-bounds read to crash, CVSS 8.2), CVE-2024-39721 (resource-exhaustion DoS via /dev/random), and CVE-2024-39722 (/api/push path traversal exposing the directory tree).
• CVE-2026-5530 is a server-side request forgery in the Model Pull API (server/download.go) that coerces the server into arbitrary outbound requests. This is the exact class Campaign B's ssrf_test residue was probing for.
• Two issues Ollama treats as working-as-intended: model poisoning via /api/pull from an untrusted source and model theft via /api/push to an untrusted destination. That "by design" write primitive is exactly what both campaigns used to plant their entries.

Campaign B was scanning for these. Campaign A was abusing the same write primitive for a different end. The model's refusal behavior is a sideshow; the open door is POST.

What defenders should actually do

• Don't expose 11434. Bind Ollama to localhost, or put it behind a reverse proxy that enforces auth and an allow-list. Firewall the port to known clients. This single control voids every finding in this post.
• Patch past the Probllama batch. Anything before 0.1.47 is exposed to at least one disclosed CVE; the Docker-as-root default turns Probllama into remote root.
• Audit your own registry. GET /api/tags on your instance and look for entries you didn't create: util-*, exploit-primitive names, anything whose size mirrors your real model. Their presence means someone exercised your write API.
• Fear the write, not the "leak." The credential-harvesting angle is mostly theater; treat an internet-reachable, unauthenticated create/pull endpoint as the actual incident.
• Don't paste secrets into a model you don't control. That's the one path that turns Campaign A's dud into a live round.

Indicators

Attacker and observer infrastructure, plus the detection patterns behind the campaign calls. The table is fanged so defenders can lift it directly. Victim host IPs (the seven Campaign A hosts, plus the probe-poisoned and scanned instances) are held back, redacted to /24, and shared only with vetted defenders and CERTs.

What we don't know, and where I'd dig next

This is a single snapshot with real limits, and the honest gaps are as interesting as the findings.

• Heuristic classification, hand-corrected. The labels are regex heuristics, and I corrected my own false positives as I went: some apparent "brand spoofs" turned out to be honestly-named GPT-2 and YandexGPT models, and some "malicious" hits were just scanner residue. I sampled the candidate leaks rather than checking all 49, so treat the campaign details as leads worth verifying, not settled counts.
• Longitudinal churn. This is a single snapshot. It can't tell you whether these campaigns are growing, whether poisoned hosts get cleaned, or how fast the exposed population turns over. Re-scanning on a cadence and diffing the registries (and watching callback 138.199.52[.]195:8888 for liveness) is the obvious next step.
• The true size of the exposed population. These 616 hosts are my own scan, a sample of the globally-exposed Ollama population (public indexes put the total in the low thousands), not a claim about the global count.
• The template-abuse question. Campaign B's ssrf_* residue maps cleanly onto the documented Model Pull API SSRF (CVE-2026-5530); its tpl_* residue is a probe for Modelfile / Go-template abuse, but there is no dedicated CVE for that class, so I call it consistent with the untrusted-Modelfile-creation surface rather than mapping it to a specific CVE.
• Attribution. Everything here is org-level (ASN owner), not operator identity, and honeypot-vs-victim is genuinely ambiguous for the two nodes without canary tells. I'd rather say "automated single-actor deployment" and stop than name anyone.
• Whether Campaign A ever pays off. The kit only wins if a human pastes real data into a poisoned model. I have no evidence that happened, and no way to prove it didn't; the interaction logs that would settle it aren't in a passive scan.

The takeaway I'm confident in: exposed local LLMs are being actively written to by at least two automated operations, one of them a credential harvester, and against a context-free probe that harvester overwhelmingly produces hallucinations, not secrets. The exploitable surface that does matter is the unauthenticated write API in front of the model. Close the port; the rest is noise.

Running exposed model infrastructure, or want the defender-only IOC list (the redacted victim hosts in full)? Start a conversation.

Sources

• Wiz, Probllama: Ollama Remote Code Execution (CVE-2024-37032): https://www.wiz.io/blog/probllama-ollama-vulnerability-cve-2024-37032
• Oligo Security, More Models, More ProbLLMs: New Vulnerabilities in Ollama (CVE-2024-39719/39720/39721/39722; by-design model poison/theft): https://www.oligo.security/blog/more-models-more-probllms
• The Hacker News, Critical Flaws in Ollama AI Framework Could Enable DoS, Model Theft, and Poisoning: https://thehackernews.com/2024/11/critical-flaws-in-ollama-ai-framework.html
• SentinelOne, CVE-2026-5530: Ollama Model Pull API SSRF Vulnerability: https://www.sentinelone.com/vulnerability-database/cve-2026-5530/
• Team Cymru, IP-to-ASN Mapping (the enrichment source behind the org/geo attribution here): https://team-cymru.com/community-services/ip-asn-mapping/