Ollama, eine der beliebtesten Plattformen für den lokalen Betrieb von LLM-Modellen, ist gleichzeitig mit zwei Klassen kritischer Probleme konfrontiert: einem Speicherdatenleck des Prozesses ohne Authentifizierung (CVE-2026-7482, Bleeding Llama, CVSS 9.1) und einer damit verbundenen Kette von Schwachstellen im Update-Mechanismus des Clients für Windows (CVE-2026-42248, CVE-2026-42249, CVSS 7.7), die eine persistente Codeausführung beim Anmelden ermöglichen. Dies betrifft Hunderttausende von Servern und Workstations, auf denen Ollama in Unternehmensservices und Entwicklungswerkzeuge integriert ist, und erfordert ein sofortiges Aktualisieren der Versionen, die Isolation der Instanzen sowie das Deaktivieren des Autoupdates des Windows-Clients, bis Patches verfügbar sind.

Technische Details: vom Speicherleck bis zur persistenten RCE

Bleeding Llama (CVE-2026-7482): Memory Leak über GGUF-Modelle

Die Schwachstelle CVE-2026-7482 wird in der Datenbank von CVE.org als Fehler beim Lesen außerhalb des Heap-Speichers im GGUF-Loader von Ollama bis einschließlich Version 0.17.1 beschrieben. Der Eintrag ist in der offiziellen CVE-Karte verfügbar und in der NVD gespiegelt. Betroffen ist der Code in den Dateien fs/ggml/gguf.go und server/quantization.go, in der Funktion WriteTo().

Der Kern des Problems:

• Das Interface /api/create akzeptiert vom Client bereitgestellte Modelldateien im GGUF-Format.
• Die GGUF-Datei enthält Metadaten über den Tensor (Offset, Größe, Form), ähnlich den im Tensor-Leitfaden von TensorFlow beschriebenen.
• Ollama vertraut den deklarierten Größen und der Form des Tensors, ohne sie mit der tatsächlichen Länge der Datei abzugleichen.
• Bei der Quantisierung des Modell-Tensors in WriteTo() erfolgt ein Lesezugriff außerhalb des zugewiesenen Heap-Puffers.

Die eigentliche Ursache ist der Einsatz des Go-Pakets unsafe bei der Arbeit mit den binären GGUF-Strukturen. Die Go-Dokumentation weist ausdrücklich darauf hin, dass das Paket unsafe die Speichersicherheitsgarantien umgeht; in diesem Fall führt dies dazu, dass zusätzliche Bytes aus dem Prozessspeicher gelesen werden können.

Die Forscher von Cyera haben eine dreistufige Exploit-Kette demonstriert:

1. Upload einer speziell präparierten GGUF-Datei mit überhöhten Tensorformen auf einen über das Netzwerk erreichbaren Ollama-Server per HTTP POST.
2. Start der Modellerstellung über /api/create, wodurch das Lesen außerhalb des Puffers ausgelöst und Speicherfragmente in das resultierende Modellartefakt geschrieben werden.
3. Export des erzeugten Modells in ein externes Registry des Angreifers über /api/push.

Kritische Aspekte für die Absicherung:

• Die Ausnutzung erfordert keine Authentifizierung – das REST-Interface von Ollama besitzt standardmäßig keine eingebaute Authentifizierung.
• Der Angreifer kontrolliert den Inhalt des GGUF, die ausgelesenen Daten sind jedoch beliebige Bytes aus dem Ollama-Prozessspeicher und nicht durch die Dateigrenzen begrenzt.
• Der Quellcode des Projekts ist offen auf GitHub verfügbar, was die Vorbereitung eines Exploits erleichtert.

Praktisch wird damit jede nach außen exponierte Ollama-Instanz zu einer Quelle für Datenabfluss:

• Umgebungsvariablen (einschließlich Cloud-Provider-Keys, CI/CD-Tokens usw.);
• LLM-Systemprompts und vertrauliche Anweisungen;
• Code und Daten, die von mit Ollama integrierten Tools (z. B. Entwicklungsumgebungen) verarbeitet werden;
• Fragmente der Dialoge anderer Nutzer, die vom selben Prozess bedient werden.

CVE-2026-42248 und CVE-2026-42249: Autoupdate von Ollama für Windows als Vektor für persistente RCE

Die zweite Gruppe von Schwachstellen steht mit dem Update-Mechanismus des Ollama-Clients für Windows in Zusammenhang. Die Untersuchung wurde vom Striga-Team auf ihrer Seite Striga Research veröffentlicht, die koordinierte Offenlegung erfolgte durch CERT Polska.

Der Client für Windows:

• startet beim Anmelden des Benutzers automatisch über den Autostart-Ordner von Windows;
• läuft lokal auf 127.0.0.1:11434 und fragt periodisch /api/update zur Update-Prüfung ab;
• lädt bei gefundenem Update eine Binärdatei herunter und installiert sie beim nächsten Start.

Es wurden zwei Schwachstellen entdeckt:

• CVE-2026-42248 (CVSS 7.7) – fehlende Signaturprüfung des Updates: Anders als die macOS-Version überprüft der Windows-Client die kryptografische Signatur des Binaries vor der Installation nicht.
• CVE-2026-42249 (CVSS 7.7) – Path Traversal: Der Pfad zum lokalen Verzeichnis für den Installer wird direkt aus den HTTP-Headern der Antwort des Update-Servers gebildet, ohne Normalisierung und Validierung.

Kann ein Angreifer den für den Ollama-Client erreichbaren Update-Server kontrollieren (durch Umleitung von OLLAMA_UPDATE_URL auf einen lokalen HTTP-Server, Kompromittierung des echten Servers oder Manipulation des Netzwerkverkehrs), ergibt sich folgende Exploit-Kette:

1. Der Client fragt ein Update über /api/update an.
2. Der Angreifer liefert ein „Update“ – eine beliebige ausführbare Datei – und Header, die auf einen Pfad außerhalb des erwarteten Verzeichnisses verweisen (z. B. in den Windows-Autostart-Ordner).
3. Der Client speichert die Datei an dem angegebenen Pfad, ohne die Signatur zu prüfen und ohne nicht signierte Dateien im Anschluss zu bereinigen.
4. Beim nächsten Login startet Windows die abgelegte ausführbare Datei automatisch mit den Rechten des Benutzers.

Nach Angaben von CERT Polska sind die Ollama-Versionen für Windows von 0.12.10 bis einschließlich 0.22.0 verwundbar; zum Zeitpunkt der Veröffentlichung der Empfehlungen war die Schwachstelle noch nicht behoben. Temporäre Maßnahmen umfassen das Deaktivieren der automatischen Updates und das Entfernen der Ollama-Verknüpfung aus dem Autostart-Ordner.

Bereits das Fehlen der Integritätsprüfung ermöglicht eine einmalige Codeausführung im Kontext des Updates; der hinzu kommende Path-Traversal-Fehler macht daraus eine persistente Codeausführung bei jeder Benutzeranmeldung, solange sich die bösartige Datei im Autostart-Ordner befindet.

Auswirkungsanalyse und Priorisierung der Risiken

Bleeding Llama (CVE-2026-7482) ist die primäre Bedrohung für Organisationen, bei denen:

• Ollama-Server aus dem Internet oder aus weit gefassten internen Netzen ohne strikte Segmentierung erreichbar sind;
• über Ollama sensible Daten laufen: Quellcode, Verträge, interne Dokumente, Kundendaten;
• Ollama mit zusätzlichen Tools integriert ist (z. B. Code-Analysewerkzeuge), deren Ergebnisse an das Modell übergeben und im Speicher gehalten werden.

Ohne Gegenmaßnahmen können die Folgen Folgendes umfassen:

• massive Kompromittierung von Schlüsseln und Tokens mit nachfolgenden Einbrüchen in andere Systeme;
• Abfluss vertraulicher Prompts und Geschäftslogik, auf denen interne LLM-Services basieren;
• Offenlegung von Nutzer- und Kundendaten, die über die Dialoge mit dem Modell laufen.

CVE-2026-42248/CVE-2026-42249 stellen ein erhöhtes Risiko für Entwickler- und Analysten-Workstations dar, auf denen Ollama für Windows als lokales Interface zu Modellen genutzt wird und Zugriff auf Folgendes hat:

• SSH-Keys und Repository-Tokens;
• Browser-Credentials und Unternehmens-VPN;
• Arbeitsverzeichnisse von Projekten.

Die Kette ermöglicht dem Angreifer eine persistente Ausführung von Schadcode mit den Rechten des aktuellen Benutzers – ausreichend, um Spionagesoftware zu installieren, Geheimnisse zu stehlen und sich weiter in der Infrastruktur auszubreiten. Der einzige „Abschaltpunkt“ ist das Entfernen der Datei aus dem Autostart-Ordner; die logischen Fehler in der Update-Komponente selbst bleiben bestehen.

Wichtig ist, dass sich beide Vektoren gegenseitig verstärken: Die serverseitige Schwachstelle offenbart Geheimnisse und Kontext, während die clientseitige eine verlässliche Basis auf Benutzersystemen schafft. Konzeptionell sind Szenarien möglich, in denen über Bleeding Llama abgeflossene Daten (z. B. Proxy-Konfigurationen oder Update-Parameter) die nachfolgende Ausnutzung des Windows-Clients vereinfachen.

Praktische Empfehlungen und Prüfung der Verwundbarkeit

Server und Container: Schutz vor Bleeding Llama

1. Ollama umgehend auf Version 0.17.1 oder höher aktualisieren.
   Die verwendete Version lässt sich über das offizielle GitHub-Repository von Ollama und den Release 0.17.1 prüfen. Alle Instanzen unterhalb dieser Version sind als verwundbar zu betrachten.
2. Netzwerkzugriff auf das Ollama-API einschränken.
   • Direkten Internetzugriff auf sämtliche Ollama-Interfaces schließen.
   • Zugriff nur über VPN, API-Gateway oder Reverse Proxy mit Authentifizierung erlauben.
   • Interne Netze strikt segmentieren: Entwicklungs- und Testinstanzen dürfen nicht aus Benutzernetzsegmenten erreichbar sein.
3. Authentifizierenden Proxy oder API-Gateway vorschalten.
   Da das REST-API von Ollama keine integrierte Authentifizierung besitzt, sollte vor allen Instanzen eine Komponente stehen, die Zugangsdaten, Tokens oder Client-Zertifikate prüft.
4. Log-Analyse und Prüfung auf mögliche Kompromittierung.
   • In den Logs nach HTTP-Requests auf /api/create mit großen Bodies und untypischen Quellen suchen, insbesondere in Kombination mit nachfolgenden /api/push-Aufrufen zu externen Registries.
   • War die Instanz von außen erreichbar und lief auf einer verwundbaren Version, ist von einem Abfluss sämtlicher im Ollama-Prozessspeicher befindlicher Geheimnisse auszugehen; entsprechend sollten Keys, Tokens und Passwörter rotiert werden.
5. Richtlinien für das Hochladen von Modellen überarbeiten.
   Anonymen oder nicht verifizierten Nutzern sollte nicht erlaubt werden, eigene GGUF-Modelle auf Server hochzuladen, die sensible Daten verarbeiten.

Windows-Workstations: temporäre Maßnahmen gegen RCE über Updates

Bis ein offizieller Patch für den Ollama-Client auf Windows vorliegt, wird empfohlen:

1. Automatische Updates deaktivieren.
   Den Anweisungen von CERT Polska folgen: die Option AutoUpdateEnabled ausschalten und die Variable OLLAMA_UPDATE_URL nicht für Umleitungen auf nicht standardisierte oder ungesicherte (HTTP-)Server verwenden.
2. Unkontrollierten Autostart entfernen.
   Die Ollama-Verknüpfung aus dem Autostart-Ordner löschen:
   %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. Dies beseitigt die Schwachstellen nicht, nimmt dem Angreifer aber einen bequemen Punkt für persistente Ausführung.
3. Auf verdächtige Dateien im Autostart prüfen.
   Ausführbare Dateien im Autostart-Ordner inventarisieren und mit der erwarteten Programmliste abgleichen; unbekannte oder kürzlich hinzugefügte Dateien sollten separat analysiert werden.
4. Kontrolle des Netzwerkperimeters rund um Updates verstärken.
   • Sicherstellen, dass der Traffic zum Ollama-Update-Server über einen kontrollierten Proxy läuft und nicht manipuliert werden kann.
   • Die Nutzung von unverschlüsseltem HTTP für den Download von Updates auf Proxy- oder Firewall-Ebene verbieten.
5. Überwachung der Prozessaktivität.
   Endpoint-Schutzlösungen so konfigurieren, dass sie das Starten unbekannter ausführbarer Dateien aus dem Autostart-Ordner sowie von Prozessen, die durch Ollama erzeugt werden, überwachen.

In Infrastrukturen, in denen Ollama sowohl auf Servern als auch auf Windows-Workstations eingesetzt wird, sollten zunächst die Serverinstanzen auf Version 0.17.1+ aktualisiert und das Netz segmentiert werden; anschließend ist das Autoupdate des Windows-Clients zentral zu deaktivieren und der Autostart auf den Workstations zu bereinigen.