Is Your AI Server Exposed? How to Lock Down Ollama

Watch the 2-minute video:

Running your own AI models with Ollama is great, until the whole internet can use them. Ollama’s API has no password. If port 11434 is reachable from outside, anyone can list your models, run prompts on your GPU, pull or push models, and use any bug in your version.

Attackers are already doing this at scale:

• PoeLLM botnet (October 2026). Lumen’s Black Lotus Labs found a campaign that has hit more than 3,400 servers since April 2026. Most victims run open-source AI tools such as LiteLLM and Ollama. Infected servers run XMRig crypto miners, open a remote shell, and scan for new victims. The botnet even hides its control server address inside a poem hosted on GitHub.
• Bleeding Llama, CVE-2026-7482 (CVSS 9.1). Cyera found that a crafted model file makes older Ollama versions leak heap memory, including prompts, chats and environment variables, with no login needed. They counted about 300,000 internet-facing Ollama instances.

Here’s how to check your server and fix it. Every command below is for Ubuntu/Debian with systemd. The full list is in ollama-lockdown-commands.txt.

Step 0: check what Ollama listens on

On the server:

ss -tlnp | grep 11434

Then check from another machine (your laptop, or your phone on mobile data):

curl http://YOUR-SERVER-IP:11434/api/tags

If you get a JSON list of your models, so can an attacker.

Fix 1: bind Ollama to localhost

Ollama listens on 127.0.0.1:11434 by default. Servers usually end up exposed because someone set OLLAMA_HOST=0.0.0.0 to use it from another PC. Put it back:

sudo systemctl edit ollama.service

Add these lines, then save and exit:

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ss -tlnp | grep 11434    # now 127.0.0.1:11434

On Windows, change the OLLAMA_HOST user environment variable and restart Ollama. On macOS, use launchctl setenv OLLAMA_HOST "127.0.0.1:11434" and restart the app.

The tricky part: Docker

This is the case that catches experienced admins.

1. The ollama/ollama image listens on all interfaces inside the container, which is expected, because Docker has to forward traffic to it.
2. -p 11434:11434 publishes that port on every interface of the host.
3. Docker writes its own iptables rules, so published ports skip UFW. Docker’s own documentation says traffic “gets diverted before it goes through the ufw firewall settings”. Your ufw deny rule does nothing here.

The fix is to publish the port on localhost only:

docker run -d --name ollama -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 ollama/ollama

With Docker Compose:

services:
  ollama:
    image: ollama/ollama
    ports:
      - "127.0.0.1:11434:11434"

If Open WebUI runs in the same Compose file, it can reach Ollama on the internal network (http://ollama:11434), so you may not need to publish the port at all.

Fix 2: block the port anyway

Defense in depth: if someone changes OLLAMA_HOST later, the firewall still blocks it (for native installs; see the Docker note above).

sudo ufw deny 11434/tcp
sudo ufw status numbered

If you’re on a cloud VM, also make sure 11434 isn’t open in the provider’s security group.

Fix 3: need remote access? Nginx with a password and HTTPS

Never open 11434 itself. Put Nginx in front, require a login, and let Nginx talk to Ollama on localhost:

sudo apt install nginx apache2-utils
sudo htpasswd -c /etc/nginx/.ollama-users mouhimen

/etc/nginx/sites-available/ollama:

server {
    listen 443 ssl;
    server_name ai.mouhimen.dev;
    ssl_certificate     /etc/letsencrypt/live/ai.mouhimen.dev/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/ai.mouhimen.dev/privkey.pem;

    location / {
        auth_basic           "Ollama";
        auth_basic_user_file /etc/nginx/.ollama-users;
        proxy_pass           http://127.0.0.1:11434;
        proxy_set_header     Host localhost:11434;
        proxy_read_timeout   300s;
        proxy_buffering      off;
    }
}

sudo ln -s /etc/nginx/sites-available/ollama /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo ufw allow 443/tcp
curl -u mouhimen https://ai.mouhimen.dev/api/tags

Why Host localhost:11434? The Ollama FAQ uses it in its own Nginx example, and it keeps Ollama’s host check happy. proxy_buffering off lets tokens stream instead of arriving all at once. For HTTPS and security headers, see my Secure Nginx in 5 settings video. A VPN such as WireGuard or Tailscale is an even safer option if only your own devices need access.

Fix 4: update Ollama (and LiteLLM)

ollama -v
curl -fsSL https://ollama.com/install.sh | sh    # re-running the installer updates Ollama on Linux
docker pull ollama/ollama                        # Docker: pull, then recreate the container

• Ollama 0.17.1 or newer fixes Bleeding Llama (CVE-2026-7482). The fix shipped in February 2026, but the release notes didn’t flag it as a security fix, so many servers never updated.
• LiteLLM 1.83.7 or newer fixes CVE-2026-42271, a command injection bug that CISA lists as actively exploited and that the PoeLLM botnet targets. After updating, rotate your LiteLLM master key and every API key behind it.

Were you already exposed?

If the server was reachable before you fixed it, treat it as possibly compromised:

• Look for miners: top or htop for high CPU, ps aux | grep -i -E "xmrig|kryptex|iron", and nvidia-smi for unknown GPU processes.
• Check for new cron jobs, systemd services and SSH keys: crontab -l, ls /etc/systemd/system, cat ~/.ssh/authorized_keys.
• Run ollama list and remove models you didn’t pull.
• Rotate any secrets in the server’s environment variables, since Bleeding Llama can leak them.

Checklist

• [ ] ss -tlnp | grep 11434 shows 127.0.0.1:11434
• [ ] Docker publishes 127.0.0.1:11434:11434 (or no port at all)
• [ ] ufw deny 11434/tcp is in place, and the cloud security group is closed
• [ ] Remote access only through Nginx with a password and HTTPS, or a VPN
• [ ] Ollama is 0.17.1 or newer, and LiteLLM is 1.83.7 or newer with rotated keys
• [ ] curl http://YOUR-SERVER-IP:11434/api/tags from another machine is refused

Watch the video:

Sources

• Help Net Security, PoeLLM malware hides its C2 in a GitHub poem (Lumen Black Lotus Labs), 2026-10-08: https://www.helpnetsecurity.com/2026/10/08/poellm-malware-github-poem-ai-servers/
• Cyera Research, Bleeding Llama, a critical memory leak in Ollama (CVE-2026-7482): https://www.cyera.com/blog/bleeding-llama-a-critical-memory-leak-in-the-worlds-most-popular-local-ai-platform
• Indusface, CVE-2026-7482 timeline and fixed version (0.17.1): https://www.indusface.com/blog/cve-2026-7482-bleeding-llama-vulnerability/
• Help Net Security, LiteLLM CVE-2026-42271 under active attack, CISA warns: https://helpnetsecurity.com/2026/06/09/litellm-vulnerability-under-active-attack-cisa-warns-cve-2026-42271
• Ollama FAQ (OLLAMA_HOST, Nginx proxy): https://docs.ollama.com/faq
• Docker docs, packet filtering and firewalls (Docker and ufw): https://docs.docker.com/engine/network/packet-filtering-firewalls/

Abd Almouhimen Shamout · mouhimen.dev · Take away support: IT fixes, delivered in under two minutes.