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.

Updated 2026-09-11: added GreyNoise enumeration-campaign data (80,469 sessions from two IPs in Dec 2025/Jan 2026), fingerprint-query detection patterns with occurrence counts, the Kaspersky Raspberry Pi honeypot corroboration (113,000+ requests, May 2026), and DNS-level OAST blocking as a hardening step. No technical section was rewritten.

Audit your network exposure now. The fastest way to know whether this note applies to you is to check whether port 11434 is reachable from outside your network: run the Step 1 and Step 2 commands in the hardening checklist, and if anything other than 127.0.0.1 is listening, treat the instance as exposed and work through the checklist in order. Every wave of Ollama attacks since 2024, including the enumeration campaign GreyNoise caught from two IPs in late December 2025, started with an instance like that.

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 (including two distinct campaigns this year), 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 two distinct campaigns against exposed instances in late 2025 / early 2026: 91,403 SSRF sessions (October 2025–January 2026) using a single JA4H fingerprint (po11nn060000..., almost certainly Nuclei tooling), and an 80,469-session enumeration campaign in just 11 days (December 28–January 8, 2026) from only two IPs probing 73+ model endpoints. The enumeration operator sent repetitive fingerprint queries like hi (32,716 hits), How many states are there in the United States? (27,778 hits), and a well-known LLM failure-mode test using strawberry (2,024 hits). GreyNoise labeled that second operator "a professional threat actor conducting reconnaissance" building target lists for follow-on exploitation.

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 Kaspersky corroboration: A separate honeypot experiment by Kaspersky (April–May 2026) recorded 113,000+ probe requests from thousands of unique IPs targeting AI-serving instances. Twenty-three percent of probes were specifically hunting for AI capabilities. By week three, scanner tooling had evolved to include abstract questions designed to detect honeypots rather than real models: the same fingerprint-pattern behavior we see in GreyNoise's data, now confirmed across independent operators. Seventeen active hijack attempts logged during the experiment's final week alone.

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. The ~300,000 exposure figure used throughout this note traces to the CVE-2026-7482 (Bleeding Llama) advisory and the reporting around it; the "Recent developments (2026)" section below reconciles it against independent censuses.

Recent developments (2026)

As of this 2026-09-11 update, three things are worth knowing before you act on the numbers above.

Where the 300,000 figure comes from: The headline exposure estimate traces to Cyera's Bleeding Llama research (CVE-2026-7482, published 2026-05-05) and the press coverage of it (The Hacker News, SecurityWeek): an unauthenticated heap out-of-bounds read affecting Ollama versions before 0.17.1, with roughly 300,000 internet-facing instances estimated vulnerable. The advisory link is in References below.

Independent censuses measure less: LeakIX's continuous scanning found 12,269 unauthenticated instances exposed at its February 2026 measurement; Cisco's Shodan-based survey (1,100+ instances in that analysis) looked at cloud VMs deployed with no firewall rule on port 11434; and the catalog behind the CSA's research note counts approximately 175,000 publicly accessible instances across 130+ countries. Different scopes, tools, and times: none of them contradicts the others. Treat 300,000 as an upper-bound estimate of pre-0.17.1 instances, not a current count, and check your own exposure directly (steps 1–2 of the checklist).

The June 2026 Sysdig incident, with primary sources: On 2026-06-12 Sysdig's Threat Research Team captured an attacker using a publicly exposed, unauthenticated Ollama server as the reasoning engine for a tool it calls VAPT: a multi-stage offensive pipeline that scanned targets, matched discovered services to known vulnerabilities, synthesized proof-of-concept exploits, and attempted command execution, with the model routing every stage. The captured targets were non-routable private ranges and a penetration-testing lab (HackTheBox), so the tool was a prototype; the CSA's follow-up research note (2026-06-20) nonetheless marks it as the point where stolen AI compute became documented offensive infrastructure. Both primary sources are in References.

The GreyNoise enumeration campaign (Dec 28 – Jan 8, 2026), new in this update: Two IPs (45.88.186.70 in the US, 204.76.203.125 in the Netherlands) ran 80,469 sessions against 73+ Ollama model endpoints in 11 days. Fingerprint queries were almost identical across all sessions: a baseline hi, then layered probes for factual knowledge and clock checks, then the "strawberry" failure-mode test to distinguish real models from canned responses. GreyNoise assessed this operator as professional reconnaissance, not opportunistic scanning. The campaign generated over 4 million hits on GreyNoise's broader sensor network when correlated against CVE-exploitation activity.

The Kaspersky honeypot (Apr–May 2026), new in this update: Kaspersky deployed an Ollama honeypot on a Raspberry Pi for three months starting April. They recorded 113,000+ requests from thousands of unique IPs; 23% probed specifically for AI capabilities using the same fingerprint patterns GreyNoise documented. Scanner tooling (called "LLM-Scanner" by Kaspersky) evolved within the experiment: by week three it was sending abstract questions designed to detect honeypots rather than real models, confirming these enumeration techniques had become standard across multiple operators.

OAST-domain DNS blocking as a practical control: GreyNoise confirmed successful SSRF exploitation when Ollama resolved ProjectDiscovery's OAST subdomains (*.oast.live, *.oast.me). Blocking those domains at the DNS level (dnsmasq, Pi-hole, or /etc/hosts) stops the callback that confirms an exploit succeeded. This is the only control that works without modifying Ollama itself.

Practical implications:

• An exposed Ollama server is now attacker tooling, not just a cost center: the inference you leave free can be pointed at other networks.
• Detection: watch inference endpoints for the VAPT markers (VAPTb3gin / VAPTfin sentinels, structured-output contracts, anomalous request volume), plus fingerprint-query patterns (hi, How many states..., strawberry). Sysdig's blog carries the full VAPT IOC table; GreyNoise has the enumeration fingerprints.
• Detect SSRF callbacks: alert on any outbound connection from Ollama to non-whitelisted hostnames (especially *.oast.*, registry.ollama.ai is expected). Block those domains at DNS time if you can.
• Assume compromise if your instance was internet-facing before you patched or bound it to loopback: rotate the API keys, environment secrets, and credentials that lived in its process memory: the exact leak class of CVE-2026-7482.
• Audit network exposure now: run the Step 1 and Step 2 commands in the checklist below and confirm only 127.0.0.1 is listening on 11434. If anything else shows up, work through the checklist in order tonight.

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

This is the highest-profile Ollama vulnerability of 2026: CVSS 9.1 to 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: 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):

• Upload crafted GGUF blob: POST /api/blobs/sha256:[digest]: file with inflated shape fields
• Create model referencing the blob: POST /api/create: triggers WriteTo() OOB read, memory leaks to attacker's local filesystem
• 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, the server made HTTP requests to attacker-controlled infrastructure, and ProjectDiscovery OAST callbacks (*.oast.live, *.oast.me) confirmed successful exploitation. GreyNoise saw 91,403 attack sessions over four months.

The tooling signature was nearly identical across all attacks: JA4H fingerprint po11nn060000..., consistent with ProjectDiscovery Nuclei automation. The attacker infrastructure was modest: 62 source IPs across 27 countries, mostly VPS rented in bulk.

GreyNoise Enumeration Campaign (Dec 28 – Jan 8, 2026)

A separate campaign ran by two operators (45.88.186.70 US, 204.76.203.125 NL) probed 73+ Ollama endpoints across 80,469 sessions in just 11 days. Every session followed the same script:

• Baseline probe: "hi"
• Factual-capability check: "How many states are there in the United States?"
• Multi-question fingerprint to identify model type and clock state
• Empty-string test to see whether the API accepts blank prompts
• The "strawberry" failure-mode test: distinguishing real models from canned responses

This is reconnaissance, not exploitation. GreyNoise assessed these two IPs as a professional threat actor building target lists for follow-on CVE work (the same campaign IP space later appeared in over 4 million hits correlated with known CVE-exploitation activity). The pattern matters because it tells you what enumeration looks like before any payload fires.

Kaspersky Honeypot Findings (Apr–May 2026)

Kaspersky deployed an Ollama honeypot on a Raspberry Pi for three months starting in April. They recorded 113,000+ probe requests from thousands of unique IPs. Twenty-three percent were specifically hunting for AI capabilities using the same fingerprint patterns GreyNoise documented: it was not just GreyNoise's data point but a cross-campaign technique by then.

The attacker tooling ("LLM-Scanner" per Kaspersky) ran across seven cloud providers from eight countries. By week three, that tooling had evolved to send abstract questions designed to detect honeypots rather than real models: the operators were learning about the honeypot as it was learning about them. Seventeen active hijack attempts logged during the experiment's final week alone.

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 was not 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 is not 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, concrete 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.

Ostensibly additional: Ollama has no native registry allowlist in any documented version. Egress filtering at the OS level (iptables/nftables) or DNS-level blocking of non-allowlisted outbound domains is the only control that works without modifying Ollama itself. GreyNoise specifically recommends this because their SSRF campaign succeeded against servers whose /etc/hosts did not resolve *.oast.live to a dead address.

Step 6: Block OAST Domains at DNS Time (2 minutes)

Ollama confirmed as SSRF-exploited whenever it resolved ProjectDiscovery's OAST subdomains. Block them at your DNS layer:

# dnsmasq: drop oast probes before they leave the network
address=/oast.live/0.0.0.0
address=/oast.me/0.0.0.0
address=/oast.online/0.0.0.0

This works with Pi-hole, systemd-resolved stub resolver overrides, or a simple /etc/hosts entry pointing the domains at 127.0.0.1. The goal is to make SSRF callback confirmation impossible: if Ollama can't resolve the attacker's domain, it cannot complete the exfiltration loop.

Step 7: 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 8: 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;

New detection signatures in this update:

• Fingerprint queries: alert on requests containing "hi", "How many states", or "strawberry" in the prompt body. These do not appear in normal usage.
• Rapid-fire model enumeration: >50 distinct model names queried within 60 seconds across /api/generate, /api/tags, or any other endpoint is a GreyNoise-confirmed pattern from the Dec 2025 campaign.
• Non-standard /api/pull targets: alert on pull requests where the hostname does not match registry.ollama.ai.

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 9: 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; egress filtering blocks non-whitelisted outbound connections
• OAST domains (*.oast.live/.me/.online) blocked at DNS level: no SSRF callback confirmation possible
• Audit logging active and piped to a log aggregation system, with fingerprint-query alert rules in place
• 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. Attackers have 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 enumeration campaign GreyNoise caught in late December 2025: two IPs, 80,000 sessions, fingerprint queries that have since become standard across multiple operators. That is what "reconnaissance before exploitation" looks like against your homelab right now. If you run Ollama on any network segment reachable from the internet, you already have one of those targets.

The hardening steps above take less than three 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 thing that makes the biggest difference is step one: bind OLLAMA_HOST to 127.0.0.1. Everything else compounds from there.

Related guidance

If exposed AI services are showing up in your scans, two other notes on this site go further:

• Detection Guidance: Auditing Your Homelab for Exposed MCP Servers: the same exposure-without-authentication failure, written for MCP servers on a homelab; the detection and remediation steps transfer directly to Ollama.
• The Gateway in the Middle: Why Your AI Proxy Is a Perimeter Device and What a Pre-Auth SQLi Taught Us: what a proxy in front of local AI actually protects, and what a pre-auth SQLi in that layer can still reach.

References

• Cyera Bleeding Llama research (CVE-2026-7482): cyera.com/research/bleeding-llama
• CSA Labs Ollama exposure notes: labs.cloudsecurityalliance.org
• GreyNoise, threat actors actively targeting LLMs (SSRF campaign, enumeration campaign data, fingerprint-query table, JA4H signatures, OAST domains): greynoise.io/blog/threat-actors-targeting-llms
• SC Media republish of GreyNoise enumeration campaign data (2 IPs: 45.88.186.70 US, 204.76.203.125 NL; "professional threat actor conducting reconnaissance"): scworld.com/news/honeypots-detect-threat-actors-mass-scanning-llm-infrastructure
• Kaspersky, LLMjacking: What These Attacks Are and Why They Matter (Raspberry Pi honeypot experiment data): kaspersky.com/blog/llmjacking-2026
• Pillar Security Operation Bizarre Bazaar report: pillar.security/blog/operation-bizarre-bazaar
• Sysdig, LLMjacking evolved (June 2026 VAPT pipeline capture): sysdig.com/blog/llmjacking-evolved
• Oligo Security "More ProbLLMs" audit (CVE-2024-39719–39722): oligo.security
• Sysdig security briefing, June 2026 (VAPT tool development observed on a HackTheBox practice range): sysdig.com/blog/security-briefing-june-2026
• CSA AI Safety Initiative, LLMjacking Evolved: Stolen AI Compute as Offensive Infrastructure (research note, 2026-06-20): labs.cloudsecurityalliance.org
• LeakIX, 12,000 Ollama instances exposed (February 2026 census; 12,269 found unauthenticated): blog.leakix.net
• Cisco Security: references in the "Recent developments" section of this post.
• Official Ollama FAQ, network config, bind address default 127.0.0.1, proxy settings: docs.ollama.com/faq
• SentinelOne CVE-2026-7482 entry (CVSS 8.8): corroborates CSA's 9.1 runZero score with alternate methodology.