Ollama CVE-2026-7482: Kritische Sicherheitslücke behoben

Überblick: „Bleeding Llama“ trifft lokale KI-Server

Am 4. Mai 2026 wurde unter CVE-2026-7482 eine kritische Schwachstelle in Ollama veröffentlicht, der weit verbreiteten Laufzeitumgebung zum lokalen Betrieb großer Sprachmodelle (LLMs). Die von den Forschern bei Cyera unter dem Namen „Bleeding Llama“ dokumentierte Lücke betrifft den GGUF-Modell-Loader und erlaubt es nicht authentifizierten Angreifern, Speicherinhalte des Server-Prozesses über das Netzwerk auszulesen. Laut Eintrag in der NVD (National Vulnerability Database) beträgt der CVSS-3.1-Score 9.1 (CRITICAL).

Behoben wurde der Fehler mit dem Patch-Commit 88d57d0 (Pull Request #14406) und in Ollama v0.17.1 ausgeliefert. Betroffen sind nach Herstellerangabe sämtliche Versionen vor 0.17.1. Der Vorfall ist deshalb so brisant, weil – laut mehreren Scans, u. a. von runZero und Cyera – rund 300.000 Ollama-Instanzen öffentlich im Internet erreichbar sind und die kritischen Endpunkte standardmäßig keine Authentifizierung verlangen.

Technische Analyse der Out-of-Bounds-Read-Lücke

Die Schwachstelle liegt in der Verarbeitung von GGUF-Modelldateien – einem von der llama.cpp-/Ollama-Community etablierten Containerformat für quantisierte LLMs. Konkret nimmt der HTTP-Endpunkt /api/create eine vom Angreifer kontrollierte GGUF-Datei entgegen. Laut NVD-Beschreibung sind in dieser Datei der deklarierte Tensor-Offset und die Tensor-Größe größer als die tatsächliche Dateilänge. Beim anschließenden Quantisierungsvorgang in den Dateien fs/ggml/gguf.go und server/quantization.go (Funktion WriteTo()) liest der Server über das Ende des allokierten Heap-Puffers hinaus.

Da diese fremden Speicherinhalte anschließend in das durch die Quantisierung erzeugte Modell-Artefakt einfließen, lassen sie sich über den ebenfalls unauthentifizierten Endpunkt /api/push an eine vom Angreifer kontrollierte Registry exfiltrieren. CVE-2026-7482 beschreibt damit nicht nur einen klassischen Memory-Leak (CWE-125), sondern eine vollständige Exfiltrationskette ohne Benutzerinteraktion.

Angriffskette: Vom manipulierten GGUF zum Datenabfluss

Wer den Ablauf von „Bleeding Llama“ verstehen will, muss die unauthentifizierten Endpunkte und den Quantisierungs-Workflow gemeinsam betrachten. Die folgenden Schritte spiegeln die in der NVD-Beschreibung dokumentierte Kette wider.

Auffällig ist, wie wenige Voraussetzungen Angreifer mitbringen müssen: keine Zugangsdaten, kein Nutzerklick, kein lokaler Zugriff. Wer Ollama mit OLLAMA_HOST=0.0.0.0 betreibt – eine in offiziellen Beispielen dokumentierte Konfiguration – exponiert die anfälligen Endpunkte direkt am Netzwerkrand.

# Nur in autorisierten Testumgebungen verwenden!
# Prüft, ob ein Ollama-Server auf /api/create antwortet und welche Version läuft.

curl -sS http://ollama.example.internal:11434/api/version
# -> {"version":"0.17.0"}   ← anfällig, weil < 0.17.1

# Schnelltest auf bekannten Standardport via netcat (nur Reachability)
nc -zv ollama.example.internal 11434

Sofortmaßnahmen für Betreiber

Die wichtigste Maßnahme ist trivial, aber kritisch: sofortiges Upgrade auf v0.17.1 oder neuer. Darüber hinaus sollten Betreiber den Netzwerkpfad zu Ollama härten und konsequent prüfen, ob die Endpunkte überhaupt extern erreichbar sein müssen.

# Linux (Standard-Installer)
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
# erwartete Ausgabe: ollama version is 0.17.1 (oder höher)

# Docker-Deployment
docker pull ollama/ollama:0.17.1
docker stop ollama && docker rm ollama
docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  ollama/ollama:0.17.1

# Optional: Bind explizit auf Loopback erzwingen
export OLLAMA_HOST=127.0.0.1:11434

Einordnung: Was „Bleeding Llama“ für die KI-Sicherheit bedeutet

CVE-2026-7482 ist exemplarisch für eine Klasse von Schwachstellen, die mit der zunehmenden Verbreitung lokaler KI-Stacks häufiger auftreten wird. Modellformate wie GGUF sind hochkomplexe, binäre Container; ihre Parser bewegen sich auf der Grenze zwischen Performance-Optimierung und Speichersicherheit. Fehlen dort Bounds-Checks, entstehen klassische Memory-Safety-Probleme – diesmal in einem Go-Codepfad, der eigentlich als robust gilt.

Zwei strukturelle Lehren lassen sich ziehen: Erstens müssen unauthentifizierte Admin-Endpunkte wie /api/create oder /api/push als Anti-Pattern verstanden werden – jede Inferenz-Plattform sollte standardmäßig Authentifizierung verlangen. Zweitens wird das Thema LLM-Pentesting über klassische Prompt-Injection hinausgehen: Auch die Runtime-Schicht (Modell-Loader, Quantisierer, Tool-Use-Engines) muss aktiv geprüft werden.

Fazit und Quellenüberblick

CVE-2026-7482 zeigt: Lokal betriebene KI-Modelle sind keine Sicherheits-Insel. Eine fehlende Bounds-Prüfung im GGUF-Parser und unauthentifizierte Verwaltungs-Endpunkte ergeben in Summe einen kritischen Memory-Leak, der nicht nur API-Schlüssel und System-Prompts, sondern auch Daten paralleler Nutzer offenlegt. Der Patch in Ollama v0.17.1 beseitigt die unmittelbare Lücke – die strukturellen Lehren rund um AuthN, Netzwerksegmentierung und LLM-Runtime-Härtung bleiben dauerhaft relevant.