github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-07-16 05:05:37 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[GH-ISSUE #11941] “Secure Mode” for Ollama (auth, safe defaults, restricted blob/model ops) #54441

New Issue
Open
opened 2026-04-29 05:57:14 -05:00 by GiteaMirror · 2 comments
GiteaMirror commented 2026-04-29 05:57:14 -05:00
Owner
Copy Link

Originally created by @Cristliu on GitHub (Aug 17, 2025).
Original GitHub issue: https://github.com/ollama/ollama/issues/11941

Summary

In a cross-platform study of real-world, self-hosted LLM deployments, we observed a non-trivial number of publicly reachable Ollama servers where administrative/model-management endpoints were accessible due to permissive network exposure or reverse-proxy misconfiguration. In our lab testbed (not against public targets), we confirmed that endpoints for model management and blob uploads can be abused if left open and unauthenticated, potentially leading to unauthorized model creation/replacement and broader compromise depending on the surrounding stack.

We are not sharing exploitation details here. This issue proposes a set of hardening features so that secure operation becomes the default, and misconfigurations are harder to make.

Why this matters

  • Many admins deploy quickly via containers and reverse proxies; defaults and examples are often copied verbatim.
  • If management endpoints are reachable from the Internet without controls, attackers may pull, create, or replace models, upload arbitrary blobs, or influence downstream applications.
  • Even when operators intend “local only,” a proxy/ports mapping can accidentally make the service world-reachable.

Proposed feature set: Secure Mode

A one-flag profile (e.g., --secure or OLLAMA_SECURE=1) that switches Ollama to hardened defaults:

  1. Built-in auth (opt-in but strongly encouraged)

    • API keys or mTLS for management endpoints; separate roles for inference-only vs admin/model-management.
    • Ability to run in read-only / inference-only mode that disables model creation/pull endpoints entirely.

  2. Safe network defaults

    • Bind to 127.0.0.1 by default; require an explicit flag to listen on 0.0.0.0.
    • Clear startup warnings (or refusal to start) when the server is publicly reachable without auth.

  3. Endpoint partitioning & switches

    • Distinct routes for admin/model ops vs inference; allow disabling admin routes at runtime.
    • Optional allowlist for admin routes (CIDR/IPs) and reverse-proxy headers sanity checks.

  4. Blob/model pipeline protections

    • Gate /api/blobs and model-creation endpoints behind admin auth; enforce size/quota limits, content-type checks, and rate limiting.
    • Optional registry allowlist and content trust (signed models/digests) to prevent untrusted pulls influencing production.
    • Detailed audit logs for admin actions (pull, create, delete, set-default).

  5. CORS & CSRF defaults

    • Disable permissive CORS by default; provide a minimal safe preset or explicit allowlist.
    • CSRF protection for browser-reachable admin actions.

  6. Security health checks

    • An admin-only /health/security summary (non-sensitive) surfacing: bind address, auth status, disabled admin routes, rate-limit status, proxy sanity.

  7. Docs & examples

    • A short Production Hardening guide: localhost-only compose examples, reverse-proxy snippets, firewall rules, TLS, and inference-only deployments.

Minimal evidence (kept non-sensitive)

  • Internet-wide reconnaissance found a meaningful subset of Ollama instances reachable on public interfaces.
  • In our testbed, we validated that unauthenticated access to model/blob operations can change server state and affect downstream apps.
  • Public measurements used non-intrusive checks only (connectivity/headers) with fixed source and opt-out contact; no destructive actions on third-party systems.

For full technical details and coordinated remediation, we are happy to share a private report via GHSA / security contact and help verify candidate fixes.

Appendix: safer compose snippet (example)

services:
  ollama:
    image: ollama/ollama:latest
    # Bind to localhost only; expose via VPN/reverse proxy if needed
    ports:
      - "127.0.0.1:11434:11434"
    environment:
      OLLAMA_SECURE: "1"  # proposed secure profile
      OLLAMA_READONLY: "true"  # inference-only, disables admin/model ops
    # Add volumes, resources, etc., as needed

Ethics note: We validated abuse paths only on our own infrastructure. Public-facing observations were limited to minimal connection checks. We can provide additional details privately and assist with a public PSA once fixes land.

Originally created by @Cristliu on GitHub (Aug 17, 2025). Original GitHub issue: https://github.com/ollama/ollama/issues/11941 ### Summary In a cross-platform study of real-world, self-hosted LLM deployments, we observed a non-trivial number of **publicly reachable Ollama servers** where administrative/model-management endpoints were accessible due to permissive network exposure or reverse-proxy misconfiguration. In our **lab testbed** (not against public targets), we confirmed that endpoints for model management and blob uploads can be abused if left open and unauthenticated, potentially leading to unauthorized model creation/replacement and broader compromise depending on the surrounding stack. We are **not** sharing exploitation details here. This issue proposes a set of hardening features so that secure operation becomes the default, and misconfigurations are harder to make. --- ### Why this matters - Many admins deploy quickly via containers and reverse proxies; defaults and examples are often copied verbatim. - If management endpoints are reachable from the Internet without controls, attackers may **pull, create, or replace models**, upload arbitrary blobs, or influence downstream applications. - Even when operators intend “local only,” a proxy/ports mapping can accidentally make the service world-reachable. --- ### Proposed feature set: **Secure Mode** A one-flag profile (e.g., `--secure` or `OLLAMA_SECURE=1`) that switches Ollama to hardened defaults: 1. **Built-in auth (opt-in but strongly encouraged)** - API keys or mTLS for management endpoints; separate **roles** for *inference-only* vs *admin/model-management*. - Ability to run in **read-only / inference-only** mode that disables model creation/pull endpoints entirely. 2. **Safe network defaults** - Bind to **127.0.0.1** by default; require an explicit flag to listen on `0.0.0.0`. - Clear **startup warnings** (or refusal to start) when the server is publicly reachable without auth. 3. **Endpoint partitioning & switches** - Distinct routes for *admin/model ops* vs *inference*; allow disabling admin routes at runtime. - Optional **allowlist** for admin routes (CIDR/IPs) and reverse-proxy headers sanity checks. 4. **Blob/model pipeline protections** - Gate `/api/blobs` and model-creation endpoints behind admin auth; enforce **size/quota limits**, content-type checks, and **rate limiting**. - Optional registry allowlist and **content trust** (signed models/digests) to prevent untrusted pulls influencing production. - Detailed **audit logs** for admin actions (pull, create, delete, set-default). 5. **CORS & CSRF defaults** - Disable permissive CORS by default; provide a minimal safe preset or explicit allowlist. - CSRF protection for browser-reachable admin actions. 6. **Security health checks** - An admin-only `/health/security` summary (non-sensitive) surfacing: bind address, auth status, disabled admin routes, rate-limit status, proxy sanity. 7. **Docs & examples** - A short **Production Hardening** guide: localhost-only compose examples, reverse-proxy snippets, firewall rules, TLS, and inference-only deployments. --- ### Minimal evidence (kept non-sensitive) - Internet-wide reconnaissance found a **meaningful subset** of Ollama instances reachable on public interfaces. - In our **testbed**, we validated that unauthenticated access to model/blob operations can change server state and affect downstream apps. - Public measurements used **non-intrusive checks only** (connectivity/headers) with fixed source and opt-out contact; no destructive actions on third-party systems. For full technical details and coordinated remediation, we are happy to share a private report via **GHSA / security contact** and help verify candidate fixes. --- ### Appendix: safer compose snippet (example) ```yaml services: ollama: image: ollama/ollama:latest # Bind to localhost only; expose via VPN/reverse proxy if needed ports: - "127.0.0.1:11434:11434" environment: OLLAMA_SECURE: "1" # proposed secure profile OLLAMA_READONLY: "true" # inference-only, disables admin/model ops # Add volumes, resources, etc., as needed ``` Ethics note: We validated abuse paths only on our own infrastructure. Public-facing observations were limited to minimal connection checks. We can provide additional details privately and assist with a public PSA once fixes land.
GiteaMirror added the feature request label 2026-04-29 05:57:14 -05:00
GiteaMirror commented 2026-04-29 05:57:16 -05:00
Author
Owner
Copy Link

@hkdb commented on GitHub (Apr 1, 2026):

Agree this is needed. One thought — security is a big enough scope that it might warrant a separate component rather than being baked into Ollama itself? Keeping the inference engine and the auth/access-control layer decoupled would let each evolve independently and avoid bloating Ollama's core?

That's the approach I took with LM Gate — a gateway that sits in front of Ollama and handles JWT token auth, CORS/CSRF, rate limiting, fail2ban integration, allow lists, logging, metrics, and more. All of it can be managed through a local auth + 2FA or OIDC-gated web dashboard that allows admins to configure LM Gate and users to manage JWT tokens. It also has prepackaged docker images that deploy LM Gate bundled with Ollama in a single container. It's still early stage (v0.2.0) but we've already started putting it to the test in our own projects.

Would love to hear your thoughts on this.

<!-- gh-comment-id:4167490418 --> @hkdb commented on GitHub (Apr 1, 2026): Agree this is needed. One thought — security is a big enough scope that it might warrant a separate component rather than being baked into Ollama itself? Keeping the inference engine and the auth/access-control layer decoupled would let each evolve independently and avoid bloating Ollama's core? That's the approach I took with [LM Gate](https://github.com/hkdb/lmgate) — a gateway that sits in front of Ollama and handles JWT token auth, CORS/CSRF, rate limiting, fail2ban integration, allow lists, logging, metrics, and more. All of it can be managed through a local auth + 2FA or OIDC-gated web dashboard that allows admins to configure LM Gate and users to manage JWT tokens. It also has prepackaged docker images that deploy LM Gate bundled with Ollama in a single container. It's still early stage (v0.2.0) but we've already started putting it to the test in our own projects. Would love to hear your thoughts on this.
GiteaMirror commented 2026-04-29 05:57:18 -05:00
Author
Owner
Copy Link

@Cristliu commented on GitHub (Apr 4, 2026):

@hkdb I think this is fantastic. To be honest, this is exactly the kind of protection we aim to provide following our extensive security risk analysis (Please See https://cristliu.github.io/lens/). Your repository has a very solid implementation, and I’ll try to build on it or conduct further research and improvements. I hope we can stay in touch. Thank you.

<!-- gh-comment-id:4186796733 --> @Cristliu commented on GitHub (Apr 4, 2026): @hkdb I think this is fantastic. To be honest, this is exactly the kind of protection we aim to provide following our extensive security risk analysis (Please See https://cristliu.github.io/lens/). Your repository has a very solid implementation, and I’ll try to build on it or conduct further research and improvements. I hope we can stay in touch. Thank you.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label feature request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#54441
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?