Ollama on the Open Internet: 300,000 Exposed AI Inference Servers Under Active Attack

Ollama has become the default way to run large language models locally. That's a good thing — local inference keeps your data private, avoids API costs, and works offline. But every instance you spin up is a network service listening on port 11434, and as of mid-2026 there are roughly 300,000 Ollama instances exposed to the internet. They're not all vulnerable in practice — many admins bind correctly — but runZero's scans show a persistent tail of OLLAMA_HOST=0.0.0.0 deployments that never got fixed after "just testing" became production.

This note is for people running Ollama at home or on a lab network who want to understand what attackers are actually doing and walk away with concrete steps they can implement tonight. It pulls from three sources: the Oligo/Cyera/SentinelOne CVE timelines, GreyNoise campaign data, and direct operational guidance distilled from real-world incidents.

The Threat Picture — What's Actually Happening

Ollama attacks have evolved in four distinct waves since late 2024, each getting more sophisticated:

Wave 1 (mid-2024): Exploit the binary. Wiz Research found that Ollama's /api/pull endpoint accepted private registry manifests with path-traversal payloads. Combined with a trivial container RCE in Docker root deployments, this became CVE-2024-37032 ("Probllama") — unauthenticated remote code execution. The fix shipped quickly in v0.1.34, but Oligo Security's follow-up audit in late 2024 revealed six more vulnerabilities (CVE-2024-39719–39722) — all in the model serialization layer, all reachable via /api/pull and /api/create.

Wave 2 (late 2025): Find it at scale. Cybercrime groups stopped writing exploits for individual vulnerabilities and started scanning. GreyNoise captured 91,403 SSRF attack sessions between October 2025 and January 2026, all using the same JA4H fingerprint (po11nn060000...) — almost certainly a Nuclei template. The attacker infrastructure was modest: 62 source IPs across 27 countries, mostly VPS rented in bulk.

Wave 3 (early-mid 2026): Steal the compute. Operation Bizarre Bazaar was the first fully attributed LLMjacking campaign with a commercial marketplace. "Hecker" used silver.inc — hosted on bulletproof Netherlands infrastructure — to resell access to compromised AI instances at 40-60% discount, accepting both crypto and PayPal. Over 35,000 attack sessions in 40 days; daily costs to victims exceeded $100,000 for flagship model API keys.

Wave 4 (mid-2026): Weaponize the instance. In June 2026, Sysdig documented an attacker using a publicly exposed Ollama server as the cognitive core of an offensive pipeline — automated recon, vulnerability fingerprinting, and exploit code synthesis happening inside the compromised LLM. This is no longer infrastructure abuse; it's turning your homelab into an attack tool against other networks.

The unifying thread: almost all of these required a misconfigured Ollama deployment. If port 11434 isn't reachable from outside localhost, none of Wave 2 onward applies to you. CVE-2026-7482 (the Bleeding Llama heap OOB read) is the notable exception — it has no authentication requirement, but it requires /api/create and /api/push endpoints to be reachable, which they almost never are in a correctly hardened setup.

CVE Detail: Bleeding Llama (CVE-2026-7482)

This is the highest-profile Ollama vulnerability of 2026 — CVSS 9.1–9.3 depending on the scorer. It was reported privately to Ollama by Cyera in February and patched in v0.17.1, but public disclosure happened five months later (May 2026).

What it does: An attacker crafts a GGUF file with deliberately inflated tensor shape metadata in the header. When Ollama's model loader parses this on /api/create, WriteTo() constructs read boundaries from those values using Go's unsafe package without validating them against actual data length. The result is an out-of-bounds heap read that dumps entire process memory to disk — including system prompts, user conversations, API keys for other AI providers, environment variables, and whatever data was in concurrent sessions.

Why it matters: You don't need credentials. You just need POST /api/create reachable from the internet. And on default Ollama installations with zero authentication, that's exactly what you have.

Exploitation steps (summarized):

1. Upload crafted GGUF blob: POST /api/blobs/sha256:[digest] — file with inflated shape fields
2. Create model referencing the blob: POST /api/create — triggers WriteTo() OOB read, memory leaks to attacker's local filesystem
3. Push leaked data as a poisoned model: POST /api/push — exfiltrates the artifact back

The fix in v0.17.1 adds bounds validation before calling into unsafe code. If you're running anything older than 0.17.1, upgrade today.

Other CVEs You Should Know About

^*LiteLLM is a separate project often co-deployed with Ollama as an AI gateway/proxy.

Real-World Campaigns — What Homelabbers Need to Know

GreyNoise SSRF Campaign (Oct 2025 – Jan 2026)
Attackers used Ollama's model pull feature as an SSRF pivot: they fed crafted URLs into /api/pull and the server made HTTP requests to attacker-controlled infrastructure (OAST callbacks). GreyNoise saw 91,403 attack sessions over four months. The tooling signature was nearly identical across all attacks — suggesting a single operator or small team using automated scanning rather than opportunistic botnets.

Operation Bizarre Bazaar (Dec 2025 – Jan 2026)
The most serious documented campaign. An attacker named "Hecker" built silver.inc, a marketplace reselling access to compromised Ollama and MCP instances at 40-60% discount for API credits. This wasn't just scanning — it was a commercial operation with customer support (Discord + Telegram), PayPal payments, and verified service providers. If you run Ollama on any publicly accessible network segment, treat this as a personal risk, not an abstract threat.

Agentic Weaponization (June 2026)
Sysdig captured an attacker using a compromised Ollama instance to autonomously enumerate private networks, fingerprint services, and generate exploit code. The LLM was acting as the "cognitive core" of an offensive pipeline — routing decisions made by AI based on network observations. This is still in prototype stage (target addresses were non-routable), but it demonstrates why a compromised Ollama instance isn't just a resource sink: it's intelligence gathering infrastructure that can adapt to your specific environment.

The Hardening Checklist

This section distills operational guidance from the hardening research into immediate, actionable steps. Implement in this order — each one makes the next layer more effective.

Step 1: Lock Down Network Binding (5 minutes)

Do this tonight. This single step blocks every attack that requires internet reachability to your Ollama instance.

# Verify current binding — should show 127.0.0.1 only
ss -tlnp | grep 11434

# If running systemd-managed:
sudo systemctl edit ollama
# Add under [Service]:
# Environment="OLLAMA_HOST=127.0.0.1:11434"
sudo systemctl daemon-reload && sudo systemctl restart ollama

If you need remote access, use a reverse proxy or VPN — never change the binding to 0.0.0.0. The homelab standard is loopback only with authentication at the layer above (nginx + basic auth for multi-user access).

Step 2: Verify No Exposed Listeners (1 minute)

ss -tlnp | grep 11434   # Should show: 127.0.0.1:11434 only
lsof -nP -iTCP:11434 -sTCP:LISTEN  # Confirms process binding

If anything shows 0.0.0.0:11434 or a specific external IP — that's your misconfiguration. Fix it immediately; re-test until only loopback appears.

Step 3: Block the Port at the Firewall (2 minutes)

Even with correct binding, defense in depth requires firewall rules:

sudo ufw default deny incoming
sudo ufw allow 22/tcp          # SSH — your management path
sudo ufw allow 443/tcp         # Reverse proxy if exposing externally
sudo ufw deny 11434/tcp        # Kill it at the door
sudo ufw enable

For multi-host setups, allowlist by source IP in nftables. For distributed homelabs, Tailscale or WireGuard eliminates most exposure without a public IP.

Step 4: Add Authentication (15 minutes)

Ollama ships with zero authentication. If you have multiple users on your network, deploy nginx as a reverse proxy:

# Require Bearer token for all requests
map $http_authorization $is_authorized {
    default 0;
    "Bearer ol-prod-7f3c2e9b1a4d8e6f..." 1;  # Generated with openssl rand -hex 24
}

server {
    listen 443 ssl http2;
    server_name ollama.local;
    
    location / {
        if ($is_authorized = 0) { return 401; }
        proxy_pass http://127.0.0.1:11434;
    }
}

Rotate tokens every 90 days. For per-user access, use htpasswd-based basic auth or oauth2-proxy if you have an identity provider.

Step 5: Restrict Model Pulls (10 minutes)

Prevent any user — authenticated or not — from pulling arbitrary models that drain resources or inject malicious payloads:

# Only allow specific IPs to pull/create/delete models
location ~ ^/api/(pull|push|create|delete) {
    allow 10.20.30.5;  # Your bastion/admin IP only
    deny all;
    proxy_pass http://127.0.0.1:11434;
}

# Normal inference from authenticated clients
location / {
    allow 10.20.30.5;
    deny all;
    proxy_pass http://127.0.0.1:11434;
}

Critical rule: Only pull models from ollama.com registry prefixes (e.g., llama3.2, mistral). Community GGUFs with arbitrary hostnames are treated as URLs — if the hostname is wrong, you're fetching from wherever it points.

Step 6: Apply OS-Level Hardening (10 minutes)

For systemd-managed Ollama, create /etc/systemd/system/ollama.service.d/hardening.conf:

[Service]
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ProtectKernelTunables=true
RestrictNamespaces=true

Verify with systemd-analyze security ollama.service — aim for score below 3.0 (lower is better). For Docker deployments, apply non-root user, read-only filesystem, and drop all capabilities:

services:
  ollama:
    user: "1000:1000"
    read_only: true
    cap_drop: ["ALL"]
    security_opt: [no-new-privileges:true]

Step 7: Audit Logging and Monitoring (30 minutes)

Ollama itself logs nothing useful for security purposes. Build audit logging at the proxy layer:

log_format ollama_audit escape=json '{
    "ts":"$time_iso8601",
    "user":"$remote_user",
    "ip":"$remote_addr",
    "path":"$request_uri",
    "status":$status,
    "latency_ms":$request_time
}';
access_log /var/log/nginx/ollama.audit.log ollama_audit;

Monitor for: auth failure spikes (10+ 401s in one minute = active reconnaissance), unexpected disk usage growth from model pulls, latency anomalies suggesting DoS attempts. Retain logs minimum 365 days for incident investigation.

Step 8: Keep It Updated (ongoing)

Run ollama --version weekly and compare to the latest GitHub release tag. Pin to a known-good version after testing (sudo apt-mark hold ollama) if you're on stable hardware — auto-updates can pull in unpatched CVEs before fixes ship.

What Your Ollama Instance Should Look Like After Hardening

• Port 11434 only reachable from 127.0.0.1 or trusted internal IPs
• Reverse proxy in front with authentication (Bearer token or OAuth)
• TLS on any external-facing endpoint (Let's Encrypt via certbot)
• Model pulls restricted to approved admin IPs only
• Audit logging active and piped to a log aggregation system
• systemd-analyze security score below 3.0
• Version current — within one minor release of the latest GitHub tag

Bottom Line

Ollama is excellent software for local AI — but it was designed for single-user localhost development, not as a network service. The threat landscape has moved from opportunistic scanning (Waves 1-2) to organized commercial exploitation (Wave 3) and now autonomous weaponization (Wave 4). Every wave after Wave 1 required either an exposed instance or a misconfigured deployment.

The hardening steps above take less than two hours total and block every known attack vector except supply chain compromise of the binary itself — which is mitigated by keeping Ollama updated and pinning to verified releases. The single most impactful action is step one: bind OLLAMA_HOST to 127.0.0.1. Everything else compounds from there.

References

• Cyera Bleeding Llama research (CVE-2026-7482) — cyera.com/research/bleeding-llama
• CSA Labs Ollama exposure notes — labs.cloudsecurityalliance.org
• GreyNoise SSRF campaign data — greynoise.io/blog/threat-actors-targeting-llms
• Pillar Security Operation Bizarre Bazaar report — pillar.security/blog/operation-bizarre-bazaar
• Sysdig agentic weaponization documentation (June 2026)
• Oligo Security "More ProbLLMs" audit (CVE-2024-39719–39722) — oligo.security