Ollama-Lücke kann Prompts und API-Keys aus dem Speicher leaken

Worum es geht

Ollama ist für viele Entwickler und Unternehmen der schnelle Weg, Sprachmodelle wie Llama oder Mistral lokal zu betreiben. Genau deshalb ist die neue Schwachstelle so heikel: Sie betrifft nicht irgendeinen Randdienst, sondern eine verbreitete Komponente in lokalen KI-Stacks.

Cyera beschreibt die Lücke unter dem Namen Bleeding Llama. In der NVD läuft sie als CVE-2026-7482. Laut Cyera können Angreifer bei anfälligen Ollama-Servern Speicherinhalte auslesen, ohne sich vorher anmelden zu müssen. SecurityWeek berichtet von rund 300.000 öffentlich erreichbaren Ollama-Deployments, die potenziell geprüft und abgesichert werden müssen.

Was Bleeding Llama tatsächlich macht

Der Fehler sitzt im Umgang mit GGUF-Modelldateien, also dem Dateiformat, in dem viele lokale LLM-Gewichte gespeichert werden. Ein Angreifer kann eine manipulierte GGUF-Datei an einen Ollama-Server schicken. Die Datei behauptet vereinfacht gesagt: "In mir steckt mehr Modelldaten, als tatsächlich vorhanden sind."

Während der Verarbeitung liest Ollama dann über das Ende des vorgesehenen Speicherbereichs hinaus. Das ist ein klassischer Out-of-Bounds-Read. Laut NVD können dabei Umgebungsvariablen, API-Keys, Systemprompts und Daten paralleler Nutzerkonversationen im Prozessspeicher landen. Besonders kritisch ist der zweite Schritt: Über die Push-Funktion kann das erzeugte Modellartefakt anschließend an eine vom Angreifer kontrollierte Registry übertragen werden.

Die Lücke betrifft Ollama-Versionen vor 0.17.1. Die Upstream-Distribution schützt die relevanten Endpunkte nicht durch Authentifizierung. Standardmäßig bindet Ollama laut NVD zwar an 127.0.0.1, aber die Konfiguration OLLAMA_HOST=0.0.0.0 wird in der Praxis häufig genutzt, um den Dienst im Netzwerk oder über Container-Setups erreichbar zu machen.

Warum das wichtig ist

Lokale KI wird oft als sicherere Alternative zu Cloud-KI verkauft: Daten bleiben im eigenen Haus, Modelle laufen auf eigenen Maschinen, Prompts verlassen nicht den Server. Diese Annahme stimmt nur, wenn die lokale Infrastruktur genauso hart abgesichert ist wie jeder andere produktive Dienst.

Hier liegt das Risiko: Viele Ollama-Instanzen laufen als Entwicklerwerkzeug, wurden aber später in interne Workflows, Agenten, Chatbots oder RAG-Prototypen eingebaut. In solchen Umgebungen können im Speicher nicht nur harmlose Testprompts liegen, sondern auch Kundendaten, Quellcode, interne Systemanweisungen, Datenbank-URLs oder Tokens für andere APIs.

Der Fall zeigt außerdem, warum KI-Infrastruktur nicht wie ein Spielzeug behandelt werden darf. Ein Modellserver ist kein Notizblock mit GPU-Anschluss. Er ist ein Netzwerkdienst, der Dateien verarbeitet, Speicher hält und Geheimnisse sehen kann. Damit gehört er in dieselbe Sicherheitsklasse wie Datenbanken, CI-Runner und interne APIs.

Einfach erklärt

Stell dir eine verschlossene Werkstatt vor, in der jemand eine manipulierte Kiste abgibt. Auf dem Etikett steht: "Bitte hole 100 Schrauben aus dieser Kiste." Tatsächlich liegen aber nur 10 Schrauben darin. Der Mitarbeiter greift weiter und weiter und nimmt plötzlich Teile vom Nachbartisch mit: Schlüssel, Notizen und fremde Aufträge.

Genau darum geht es hier. Die Datei sagt Ollama, wie viel gelesen werden soll. Wenn diese Angabe nicht sauber geprüft wird, liest der Server zu weit und erwischt Daten, die nie Teil des Modells sein sollten.

Praktisches Beispiel

Ein mittelständisches Softwareteam betreibt Ollama auf einem internen GPU-Server. Für Tests ist Port 11434 zusätzlich im VPN erreichbar. Drei Teams nutzen den Dienst: ein Supportbot verarbeitet Tickettexte, ein Entwickleragent liest Fehlermeldungen, ein RAG-Prototyp fragt interne Dokumente ab.

Ein Angreifer mit Netzwerkzugriff sendet eine präparierte GGUF-Datei an /api/create. Der Server liest beim Quantisieren Speicherbereiche, in denen kurz zuvor ein Supportprompt mit Kundendaten und ein Environment-Token für einen Dokumentenspeicher lagen. Danach wird das Modellartefakt über /api/push herausgeschoben.

Das Beispiel ist vereinfacht, aber die Größenordnung ist realistisch: Schon ein einziger exponierter KI-Server kann viele Teams berühren, wenn er als gemeinsamer Inferenzdienst genutzt wird. Praktisch heißt das: sofort auf Ollama 0.17.1 oder neuer aktualisieren, Netzwerkzugriff begrenzen, Authentifizierungs-Proxy davor setzen und Logs sowie Secrets prüfen, wenn die Instanz öffentlich erreichbar war.

Einordnung und Grenzen

• Nicht jede Ollama-Installation ist automatisch über das Internet angreifbar. Besonders gefährdet sind Instanzen, die ohne Firewall, Proxy oder Zugriffskontrolle netzwerkweit erreichbar sind.
• Die öffentlich gemeldete Ausnutzung hängt an präparierten Modelldateien und den betroffenen API-Endpunkten. Wer Uploads, Create- und Push-Flows bereits isoliert oder blockiert, reduziert das Risiko deutlich.
• Aus den Quellen geht nicht hervor, dass jede der genannten 300.000 Instanzen kompromittiert wurde. Die Zahl beschreibt beobachtete Exposition beziehungsweise potenziell gefährdete Deployments, nicht bestätigte Opfer.

SEO- und GEO-Schlüsselbegriffe

Ollama, Bleeding Llama, CVE-2026-7482, GGUF, lokale LLMs, AI Security, API Keys, Prompt Leak, Out-of-Bounds Read, KI-Infrastruktur, Self-hosted AI, Modellserver