Ollama security hardening: auth proxies / exposure / CVEs

Parent: Ollama deployment, cloud, security and operations · Published reference · snapshot 2026-10-14 · skill ollama-expert/references/ollama-ops-platform.md

Also known as: Ollama security hardening, exposure and CVEs

↓ Facts as markdown all context files

Everything the scanned sources say about Ollama security hardening, exposure and CVEs: 51 source-anchored units across 10 sources, grouped by facet.

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Definitions

evandhoffman/ollama-prometheus-exporter is a reverse proxy that extracts token and timing fields from completed inference responses. It exposes /metrics, /health and / with counters such as ollama_inference_requests_total, ollama_prompt_eval_seconds_total, ollama_eval_seconds_total and ollama_load_seconds_total. [source]
127.0.0.1:11434 means local only. 0.0.0.0:11434 or *:11434 means every network interface, which on a VPS means the public internet. Put a reverse proxy with authentication or a private network in front of it, as described in securing your Ollama API endpoint. [source]
CVE-2024-37032 is an easy-to-exploit remote code execution that affects modern AI infrastructure. Despite the codebase being relatively new and written in modern programming languages, classic vulnerabilities such as Path Traversal remain an issue. [source]

Structure and components

Ollama before 0.17.1 contains a heap out-of-bounds read vulnerability in the GGUF model loader. The /api/create endpoint accepts an attacker-supplied GGUF file in which the declared tensor offset and size exceed the file's actual length; during quantization in fs/ggml/gguf.go and server/quantization.go (WriteTo()), the server reads past the allocated heap buffer. The leaked memory contents may include environment variables, API keys, system prompts, and concurrent users' conversation data, and can be exfiltrated by uploading the resulting model artifact through the /api/push endpoint to an att [source]
GitHub Advisory GHSA-x8qc-fggm-mpqg (CVE-2026-7482) is titled "Ollama contains a heap out-of-bounds read vulnerability in the GGUF model loader". Its severity is HIGH. [source]

How it works

Ollama binds to 127.0.0.1:11434 by default, so only the machine itself can reach it. Set OLLAMA_HOST=0.0.0.0 to reach it from your laptop, and anyone on the internet who finds the port can use it too, because the server has no API key or password. A stranger can run prompts on your CPU, pull large models to fill your disk, or delete the models you have. Check what the port is bound to: [source]
<Note>Ollama must be installed and running before the installer runs. When running inside WSL2 or a container, ensure Ollama is reachable from the sandbox (e.g. `OLLAMA_HOST=0.0.0.0`).</Note> [source]

How-to and procedures

Recommended hardening checklist (LeakIX, Wiz, Cyera): bind OLLAMA_HOST to 127.0.0.1; front with an authenticating reverse proxy or API gateway; firewall port 11434 to trusted IPs; log at the proxy because Ollama does not log requests by default; restrict egress (CVE-2026-7482 exfiltrates via /api/push); rotate secrets if an exposed instance was vulnerable; patch. [source]
Bind to localhost: set OLLAMA_HOST=127.0.0.1 (not 0.0.0.0) [source]
Put a reverse proxy in front: nginx or Caddy with bearer token auth. Example configs are available in the Ollama issue thread [source]

Examples and snippets

apiVersion: apps/v1 kind: Deployment metadata: name: ollama-gpu labels: app: ollama spec: replicas: 1 selector: matchLabels: app: ollama template: metadata: labels: app: ollama spec: containers: - name: ollama image: ollama/ollama:0.24.0 ports: - containerPort: 11434 env: - name: OLLAMA_HOST value: "0.0.0.0:11434" - name: OLLAMA_KEEP_ALIVE value: "24h" - name: OLLAMA_NUM_PARALLEL value: "4" [source]
kill $SERVER_PID env: - name: OLLAMA_HOST value: "0.0.0.0:11434" resources: requests: cpu: "2" memory: 8Gi nvidia.com/gpu: 1 limits: nvidia.com/gpu: 1 volumeMounts: - name: ollama-data mountPath: /root/.ollama containers: - name: ollama image: ollama/ollama:0.24.0 [source]
apiVersion: apps/v1 kind: Deployment metadata: name: ollama labels: app: ollama spec: replicas: 1 selector: matchLabels: app: ollama template: metadata: labels: app: ollama spec: containers: - name: ollama image: ollama/ollama:0.24.0 ports: - containerPort: 11434 name: http env: - name: OLLAMA_HOST value: "0.0.0.0:11434" [source]
apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ollama-ingress annotations: nginx.ingress.kubernetes.io/proxy-read-timeout: "300" nginx.ingress.kubernetes.io/proxy-send-timeout: "300" [source]
nginx.ingress.kubernetes.io/auth-type: basic nginx.ingress.kubernetes.io/auth-secret: ollama-basic-auth nginx.ingress.kubernetes.io/auth-realm: "Ollama LLM API" spec: ingressClassName: nginx tls: - hosts: - ollama.internal.example.com secretName: ollama-tls rules: - host: ollama.internal.example.com http: paths: - path: / pathType: Prefix backend: service: name: ollama port: number: 11434 [source]
```nginx theme={"system"} — `server {` … [source]
```shell theme={"system"} — `ngrok http 11434 --host-header="localhost:11434"` … [source]
```shell theme={"system"} — `cloudflared tunnel --url http://localhost:11434 --http-host-header="localhost:11434"` … [source]
``` — `# Allow all Chrome, Firefox, and Safari extensions` … [source]

Measurements and reference values

In containers the server must listen beyond loopback: Ollama binds 127.0.0.1:11434 by default and OLLAMA_HOST changes it. Kubernetes examples set OLLAMA_HOST=0.0.0.0:11434 and probe HTTP GET / on 11434 (readiness 10s delay, liveness 30s). Exposing the port exposes an unauthenticated API (security is a sibling concept). [source]
Among the exposed instances, we find everything from llama3.3:latest running on 42 GB of VRAM to proprietary fine-tuned models that represent months of training work. Some instances have 30+ models loaded, representing hundreds of gigabytes of weights sitting on the open internet. [source]

Problems, failure modes and limitations

LeakIX (2026-02-23) counted 12,269 Ollama instances reachable on the public internet without authentication; about 1,000 ran versions vulnerable to CVE-2024-37032. Top countries were US, China, France, Germany; top hosts were AWS, Hetzner, OVH, Contabo. Exposed endpoints allow model listing (/api/tags), free inference (/api/generate, /api/chat) and model pull/push. [source]
Wiz Research discovered an easy-to-exploit Remote Code Execution vulnerability in Ollama: CVE-2024-37032, dubbed “Probllama.” This security issue was responsibly disclosed to Ollama’s maintainers and has since been mitigated. Ollama users are encouraged to upgrade their Ollama installation to version 0.1.34 or newer. [source]
The critical issue is not just the vulnerabilities themselves but the inherent lack of authentication support in these new tools. If exposed to the internet, any attacker can connect to them, steal or modify the AI models, or even execute remote code as a built-in feature (as seen with TorchServe and Ray Anyscale). The lack of authentication support means these tools should never be exposed externally without protective middleware, such as a reverse proxy with authentication. Despite this, when scanning the internet for exposed Ollama servers, our scan revealed over 1,000 exposed instances hos [source]
Cyera estimates about 300,000 internet-facing Ollama instances were exposed to CVE-2026-7482 at disclosure. This is a vendor estimate that other outlets repeat; no independent scan was found. [source]
Critical Unauthenticated Memory Leak in Ollama [source]
Cyera's research team discovered a critical memory-leak vulnerability in Ollama, the world's most popular platform for running large language models (LLMs) locally. [source]
Assess your organization's exposure to AI infrastructure vulnerabilities. Cyera can identify unauthenticated or misconfigured AI inference endpoints, flag internet-facing Ollama instances, and provide a risk-prioritized remediation roadmap. [source]
Vulnerability Unauthenticated Heap Memory Leak (Out-of-Bounds Read) [source]
The Vulnerability: Arbitrary File Write via Path Traversal [source]
However, we found that the digest field was used without proper validation, resulting in path traversal when attempting to store it on the filesystem. This issue can be exploited to corrupt arbitrary files on the system. [source]

Facts and statements

Ollama binds 127.0.0.1:11434 by default per the official FAQ; the bind address is changed with the OLLAMA_HOST environment variable, and exposing it to a network is an explicit operator choice. [source]
Let’s see what Ollama is spitting out. First, make sure you have Ollama running and have enabled Prometheus metrics. This is usually done by setting OLLAMA_HOST=0.0.0.0:11434 (or your desired IP/port) and OLLAMA_ENABLE_METRICS=true in your environment or Ollama’s config file. Then, you can curl the metrics endpoint: [source]
The official FAQ documents an nginx proxy_pass example with `proxy_set_header Host localhost:11434`, and ngrok / Cloudflare Tunnel recipes that use a host-header override. The FAQ examples add no authentication; the operator must add it at the proxy or tunnel. [source]
```bash theme={"system"} launchctl setenv OLLAMA_HOST "0.0.0.0:11434" ``` [source]
```ini theme={"system"} [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" ``` [source]
Ollama binds 127.0.0.1 port 11434 by default. Change the bind address with the `OLLAMA_HOST` environment variable. [source]
Affected: ollama/ollama versions 0 lessThan 0.17.1 (semver). CVSS v3.1 (secondary, CNA abd028dc): 9.1 CRITICAL AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H CVSS v4.0 (secondary): 8.8 HIGH [source]
Ollama has no built-in authentication. Wiz and LeakIX both direct operators to put a reverse proxy that enforces authentication (nginx, Caddy) in front of it; LeakIX says the maintainers have repeatedly declined to add auth and point users to proxies. [source]
Wiz noted the default Linux install binds localhost, which greatly limits Probllama exposure, while the Docker image runs as root and listens on 0.0.0.0 so the API is remotely reachable. Wiz's scan (June 2024) found over 1,000 exposed instances, some hosting private models. [source]
Authentication would not prevent these bugs from existing. But it would prevent random people on the internet from reaching them. Right now, every exposed Ollama instance is one CVE away from a root shell. And there are 12,269 of them. [source]
Publishing the Docker port as -p 11434:11434 exposes the API on all host interfaces and the Wiz write-up shows Docker defaults are remotely reachable; use a loopback-only publish or an internal network behind a proxy. (Docker deployment detail belongs to the sibling Docker/Kubernetes concept.) [source]
Prometheus exporter and reverse proxy for an Ollama⁠ service, typically running at http://localhost:11434. [source]
Ollama allows cross-origin requests from `127.0.0.1` and `0.0.0.0` by default. Additional origins can be configured with `OLLAMA_ORIGINS`. [source]
For browser extensions, you'll need to explicitly allow the extension's origin pattern. Set `OLLAMA_ORIGINS` to include `chrome-extension://*`, `moz-extension://*`, and `safari-web-extension://*` if you wish to allow all browser extensions access, or specific extensions as needed: [source]
Prometheus exporter and reverse proxy for Ollama token metrics [source]
Not on its own. The Ollama server has no authentication, so anyone who reaches port 11434 can run prompts, pull models and delete models. Keep the default bind of 127.0.0.1:11434, and put an authenticating reverse proxy or a private network in front of it for remote access. [source]
The top networks hosting exposed instances are AWS (1,686 combined), Hetzner (1,004), OVH (773), and Contabo (634). These aren’t hobbyist setups on home networks. These are cloud deployments, often running expensive GPU instances with production models loaded. [source]
Oct 2023: Issue #849. “How to secure the API with api key.” Response: use nginx. [source]
Nov 2023: Issue #1053. “Requesting support for basic auth or API key authentication.” 25+ comments. Closed. [source]
12,269 exposed instances say the “use a proxy” approach isn’t working. At some point you have to stop blaming users and start taking responsibility for the software you ship. [source]

Related concepts

ollama — is a related of Ollama security hardening, exposure and CVEs
auth proxy — is a part of Ollama security hardening, exposure and CVEs
11434 — is a related of Ollama security hardening, exposure and CVEs
CVE — is a problem of Ollama security hardening, exposure and CVEs
api key — is a part of Ollama security hardening, exposure and CVEs
ollama-metrics — is a instance of Ollama security hardening, exposure and CVEs
ingress — is a part of Ollama security hardening, exposure and CVEs
GHSA — is a part of Ollama security hardening, exposure and CVEs
GPU passthrough — is a part of Ollama security hardening, exposure and CVEs
docker desktop — is a instance of Ollama security hardening, exposure and CVEs

Children

No children recorded.

← the whole tree · 3D view· how to read this page