Bleeding Llama: Die Ollama-Schwachstelle CVE-2026-7482 leakt System-Prompts und Secrets

Bleeding Llama im Überblick: Was ist CVE-2026-7482?

Der Name ist griffig, der technische Kern nüchtern: CVE-2026-7482, in der Fachpresse schnell „Bleeding Llama" getauft, bezeichnet eine Schwachstelle in der Quantisierungs-Pipeline von Ollama, der verbreiteten Open-Source-Laufzeitumgebung für lokal gehostete Sprachmodelle. Betroffen ist der GGUF-Modell-Loader, konkret der /api/create-Endpunkt, über den Ollama aus einer hochgeladenen Modell-Datei ein lauffähiges, quantisiertes Modell erzeugt. Offengelegt wurde die Lücke Anfang Mai 2026, in einem engen Fenster vom 5. bis 7. Mai. Der Hersteller reagierte mit Version 0.17.1, die den fehlerhaften Validierungspfad schließt.

Dieser Beitrag erscheint bewusst nicht als Eilmeldung zu einer brandneuen Entdeckung. Zum Zeitpunkt der Veröffentlichung liegt die Offenlegung von Bleeding Llama gut vier Monate zurück, ein Patch steht seit ebenso langer Zeit bereit. Was den Fall trotzdem relevant hält, ist eine Kombination aus Schwere, Verbreitung und – das zeigt die Praxis in Beratungsmandaten immer wieder – der erschreckend hohen Zahl an Installationen, die bis heute nicht aktualisiert wurden. Dieser Artikel ist als fundierte Nachlese und Härtungsleitfaden gedacht: Was ist passiert, wer war betroffen, und vor allem, welche strukturellen Lehren bleiben für jedes On-Premise-Ollama-Deployment, unabhängig davon, ob die konkrete CVE bereits gepatcht ist.

Bei der Einordnung der Schwere lohnt ein zweiter Blick, weil kursierende Zahlen auseinanderlaufen. Der offizielle GitHub Security Advisory GHSA-x8qc-fggm-mpqg bewertet Bleeding Llama nach CVSS v4 mit 8.8 und stuft sie als „High" ein. Mehrere Medien – darunter SecurityWeek und CSO Online – führen die Lücke dagegen mit 9.1 bis 9.3 als „Critical", vermutlich nach CVSS v3.1 berechnet, das unauthentifizierte Netzwerkangriffe tendenziell höher gewichtet. Beide Zahlen sind aus ihrer jeweiligen Methodik heraus nachvollziehbar; für die Praxis zählt weniger das exakte Label als der gemeinsame Nenner: unauthentifizierter Fernzugriff auf sensiblen Prozessspeicher, ohne jede Nutzerinteraktion auf Opferseite.

Kenngröße	Wert
CVE-ID	CVE-2026-7482 („Bleeding Llama")
Komponente	GGUF-Modell-Loader, Endpunkt /api/create
Schweregrad	CVSS v4: 8.8 (High, GHSA) · Medien: 9.1–9.3 (Critical, vmtl. CVSS v3.1)
Betroffene Versionen	Alle Ollama-Versionen < 0.17.1
Gepatcht in	Version 0.17.1
Offenlegung	5.–7. Mai 2026

Für die Geschäftsleitung lohnt sich an dieser Stelle eine nüchterne Zwischenbilanz, bevor es ins technische Detail geht: Bleeding Llama ist weder ein exotischer Forschungs-Exploit, der nur unter Laborbedingungen funktioniert, noch eine Lücke, die gezielte Vorkenntnisse über eine bestimmte Firma voraussetzt. Sie betrifft die Standardinstallation eines der meistgenutzten Werkzeuge für selbst gehostete Sprachmodelle, wirkt vollautomatisiert gegen jede erreichbare Instanz und hinterlässt – das wird im weiteren Verlauf noch wichtig – keine verwertbare Spur. Genau diese Kombination aus Breite, Automatisierbarkeit und Unsichtbarkeit macht den Fall zu einem Lehrstück, nicht nur zu einer weiteren Zeile in einer CVE-Datenbank.

Technische Anatomie: Wie der Heap-Read funktioniert

Das GGUF-Format in Kürze

Um die Lücke zu verstehen, hilft ein Blick auf das Dateiformat. GGUF ist das binäre Containerformat, in dem Ollama – wie das zugrunde liegende llama.cpp – Modellgewichte ablegt. Eine GGUF-Datei beginnt mit einem Header aus Metadaten, gefolgt von einem Verzeichnis der enthaltenen Tensoren: für jeden Tensor Name, Dimensionen, Datentyp und ein Offset, der angibt, an welcher Byte-Position im Datei-Body die eigentlichen Gewichte beginnen. Größe und Lage jedes Tensors im Speicher leiten sich aus Dimension, Datentyp und diesem Offset ab – Werte, die die Datei selbst deklariert und denen grundsätzlich vertraut werden muss, wenn man sie nicht gegenprüft.

Wo die Validierung fehlt

Genau an dieser Stelle liegt der Fehler. Wenn Ollama über /api/create ein Modell aus einer hochgeladenen GGUF-Datei erzeugt und dabei die Quantisierung durchführt – also die Gewichte in ein kompakteres Zahlenformat überführt –, liest die Loader-Routine Offset und Größe jedes Tensors aus dem Dateiheader, ohne zu prüfen, ob die resultierende Byte-Spanne tatsächlich innerhalb der Dateigrenzen und des dafür reservierten Heap-Puffers liegt. Deklariert eine präparierte Datei für einen Tensor eine Größe, die über den zugewiesenen Buffer hinausreicht, liest der Loader klaglos weiter – und kopiert dabei Speicherinhalte, die gar nicht zur Datei gehören, sondern zuvor im selben Prozessadressraum lagen: Reste anderer Anfragen, Konfigurationswerte, Umgebungsvariablen. Ein klassischer Heap-Out-of-Bounds-Read, nur eben nicht in einem Nischenparser, sondern im zentralen Einstiegspunkt für jede Modellerstellung.

Für Entscheider lässt sich das Problem auf einen Satz verdichten: Die hochgeladene Datei hat über ihre eigene Größe gelogen, und niemand hat nachgemessen. Diese Klasse von Fehlern – fehlende Bounds-Checks bei Datei-Metadaten, die als vertrauenswürdig behandelt werden – ist in Parsern für binäre Formate ein wiederkehrendes Muster, weit über Ollama und GGUF hinaus. Der Unterschied hier: Der betroffene Prozess hält typischerweise hochsensible Daten im selben Adressraum.

Warum das Modell trotzdem klaglos lauffähig bleibt

Ein Detail macht Bleeding Llama besonders tückisch: Der Heap-Read führt in aller Regel nicht zu einem Absturz. Die überlesenen Bytes werden einfach als vermeintliche Tensor-Werte in das neu erzeugte, quantisierte Modell übernommen – der Prozess läuft weiter, die Antwort ist ein gültiges Modell-Artefakt, kein Fehlercode. Ein Absturz oder eine Segmentation Fault, die zumindest ein Monitoring-Alarmsignal auslösen könnte, bleibt aus, weil der gelesene Speicherbereich in aller Regel noch innerhalb des dem Prozess zugewiesenen virtuellen Adressraums liegt – nur eben außerhalb des für diesen einen Tensor vorgesehenen Puffers. Aus Betriebssystemsicht ist das ein völlig legaler Lesezugriff auf eigenen Speicher, nur eben auf den falschen Teil davon.

Der Angriffsablauf in drei API-Calls

Das eigentlich Beunruhigende an Bleeding Llama ist nicht nur die Schwere, sondern die Schlichtheit der Ausnutzung. Der komplette Angriff besteht aus drei unauthentifizierten Aufrufen gegen die Ollama-API:

1. Upload der präparierten GGUF-Datei. Der Angreifer lädt eine manipulierte GGUF-Datei mit falsch deklarierten Tensor-Offsets auf die Zielinstanz hoch – ein regulärer, für die Modellerstellung vorgesehener Vorgang, der ohne Zugangsdaten funktioniert, wenn die Instanz keine vorgeschaltete Authentifizierung hat.
2. Trigger der Quantisierung über /api/create. Der Aufruf löst die Modellerstellung samt Quantisierung aus. Genau hier greift der fehlerhafte Validierungspfad: Die zu groß deklarierten Tensor-Offsets führen zum Heap-Out-of-Bounds-Read, benachbarter Prozessspeicher landet im resultierenden Modell-Artefakt.
3. Exfiltration über /api/push. Das neu erzeugte, mit fremden Speicherinhalten durchsetzte Modell wird über den Push-Endpunkt an eine Registry unter Kontrolle des Angreifers übertragen. Von dort lässt sich der Speicherauszug in aller Ruhe extrahieren und durchsuchen.

Für keinen der drei Schritte ist eine Authentifizierung erforderlich, sofern die Instanz – wie in der Standardkonfiguration üblich – ohne Zugriffsschutz betrieben wird. Ebenso wichtig: In Standard-Logs erscheint kein Fehler. Aus Sicht der Anwendung ist der gesamte Vorgang ein erfolgreicher Vorgang mit Statuscode 200 – eine Modellerstellung, die technisch funktioniert hat, nur eben mit unerwünschtem Zusatzinhalt. Wer sein Monitoring auf Fehlerraten und Exceptions ausrichtet, wird diesen Angriff nicht bemerken.

Was wirklich leakt: System-Prompts, Secrets, Gespräche

• System-Prompts aller aktuell geladenen Modelle – inklusive unternehmensspezifischer Anweisungen, Rollen- und Guardrail-Definitionen, die häufig als vertraulich gelten.
• Nutzeranfragen und Gesprächsverläufe anderer Anwender, die zufällig zum Auslesezeitpunkt im selben Prozessspeicher lagen – keine Mandantentrennung, kein Zugriffskonzept.
• Umgebungsvariablen des Ollama-Prozesses, darunter potenziell API-Schlüssel, Zugangstoken zu nachgelagerten Diensten (Vektordatenbanken, interne APIs, Cloud-Credentials) und weitere Secrets, die per Konvention in der Prozessumgebung abgelegt werden.
• Fragmente proprietären Codes oder Kundendaten, sofern diese über RAG-Pipelines, Function-Calling-Antworten oder Copy-Paste-Kontexte durch das Modell liefen.

Gerade im On-Premise-Kontext wiegt das schwerer, als es auf den ersten Blick wirkt. Ein Cloud-Anbieter betreibt strikte Mandantentrennung zwischen Kundenumgebungen – ein Bug in einer Komponente führt im Regelfall nicht dazu, dass die Daten eines fremden Unternehmens im eigenen Prozessspeicher landen. Bei einer selbst betriebenen Ollama-Instanz gibt es diese Trennung schlicht nicht: Alle Modelle, alle Nutzer, alle Secrets laufen im selben Prozess, oft auf demselben Server wie weitere interne Dienste. Was dort im Speicher liegt, ist nicht anonymisiertes Cloud-Rauschen, sondern typischerweise genau die internen, vertraulichen Daten, derentwegen viele Mittelständler überhaupt erst auf On-Premise-Betrieb gesetzt haben.

300.000 Instanzen: Das Ausmaß der Expositionslage

Ollama bindet in der Standardkonfiguration an 127.0.0.1 und ist damit zunächst nur lokal erreichbar – ohne jede Authentifizierung, aber wenigstens nicht aus dem Netz. Das Problem entsteht durch eine verbreitete Betriebspraxis: Um Ollama im lokalen Netzwerk, aus einem Docker-Container oder für ein Team erreichbar zu machen, setzen viele Administratoren die Umgebungsvariable OLLAMA_HOST=0.0.0.0 und öffnen den Dienst damit auf allen Netzwerkschnittstellen – inklusive solcher, die aus dem Internet erreichbar sind, sobald Firewall-Regeln fehlen oder eine Portweiterleitung aktiv ist. Eine Authentifizierung liefert Ollama an dieser Stelle nicht automatisch mit; wer sie will, muss sie selbst vorschalten.

Wie verbreitet diese Praxis ist, zeigten netzwerkweite Scans zum Offenlegungszeitpunkt: Übereinstimmend berichteten mehrere unabhängige Quellen – darunter SecurityWeek, CSO Online sowie die Sicherheitsdienstleister Cyera und runZero – von rund 300.000 öffentlich auffindbaren Ollama-Instanzen Anfang Mai 2026, identifiziert über internetweite Scan-Dienste vom Typ Shodan oder Censys, die gezielt nach dem charakteristischen Antwortverhalten von Ollama auf Port 11434 suchen. Nicht jede dieser Instanzen war zwangsläufig verwundbar – einige liefen bereits auf gepatchten Versionen –, aber die Zahl markiert die Grundgesamtheit potenziell exponierter Systeme, und sie liegt um Größenordnungen höher, als „Ollama ist ein Entwickler-Tool für den Laptop" vermuten lässt.

In der Beratungspraxis begegnen uns drei wiederkehrende Muster für diese Offenheit: Entwicklungssysteme, die „nur kurz" für einen Test geöffnet und nie wieder geschlossen wurden; Docker- und Kubernetes-Setups, in denen 0.0.0.0 als Bind-Adresse schlicht die pragmatische Standardlösung für Container-Erreichbarkeit ist, ohne dass jemand die Netzwerkgrenze nach außen mitgedacht hat; und interne Tools, die von einer Fachabteilung aufgesetzt wurden, ohne dass IT-Sicherheit oder Betrieb je davon erfahren haben. Keines dieser Muster ist böswillig – alle sind vermeidbar.

Bemerkenswert an den Scan-Ergebnissen ist zudem die Verteilung: Betroffen waren nicht nur einzelne Enthusiasten-Server, sondern auch Instanzen, die erkennbar in Unternehmensnetzen liefen – erkennbar an begleitend offenen internen Diensten, an Hostnamen-Mustern und an der Art der über die offenen Instanzen erreichbaren, bereits geladenen Modelle. Die Scan-Berichte unterscheiden zwar nicht immer sauber zwischen privaten Experimentierumgebungen und produktiven Unternehmenssystemen, aber die schiere Größenordnung von 300.000 Treffern lässt sich mit „nur Hobby-Setups" nicht erklären.

Patch-Status und Nachweis: Bin ich betroffen?

Der erste Schritt ist banal, wird aber überraschend oft übersprungen: ollama --version auf jeder betriebenen Instanz ausführen. Betroffen sind alle Versionen vor 0.17.1; ab dieser Version ist der Validierungsfehler im GGUF-Loader behoben. Wer mehrere Instanzen betreibt – Entwicklung, Staging, verschiedene Abteilungen –, sollte diesen Check systematisch über ein Inventar laufen lassen, nicht stichprobenartig. Erfahrungsgemäß ist genau die vergessene, nicht in der Inventarliste geführte Instanz diejenige, die am längsten ungepatcht bleibt.

Schwieriger ist die zweite Frage: Wurde ich bereits angegriffen? Weil der Ausnutzungspfad keine Fehlermeldung erzeugt und aus Anwendungssicht wie eine normale Modellerstellung aussieht, lässt sich ein vergangener Angriff aus Standard-Logs praktisch nicht rekonstruieren. Es gibt keinen Stack-Trace, keinen 500er, keine auffällige Exception, nach der man in einem Log-Grep suchen könnte. Diese Eigenschaft macht Bleeding Llama nicht nur schwer zu entdecken, sondern auch schwer im Nachhinein forensisch zu bewerten.

Als kompensierende Maßnahme bleibt Netzwerk- und Endpoint-Monitoring, das nicht auf Fehler, sondern auf Muster achtet: ungewöhnlich große oder häufige Uploads an /api/create, insbesondere von IP-Adressen ohne bekannten Zusammenhang zu regulären Nutzungs-Workflows, gefolgt von /api/push-Aufrufen an Registry-Ziele außerhalb der eigenen Infrastruktur. Wer ein Reverse-Proxy- oder WAF-Log vor Ollama liegen hat, kann diese Muster retrospektiv für den Zeitraum vor dem eigenen Patch-Datum durchsuchen. Ohne ein solches Log bleibt nur die ehrliche Einordnung: Ein sauberer Nachweis der Nicht-Kompromittierung ist im Nachhinein kaum zu führen, was die Priorität klar auf Prävention verschiebt.

Härtungsmaßnahmen für On-Premise-Ollama-Deployments

Aus dem Vorfall lässt sich eine Checkliste ableiten, die unabhängig von der konkreten CVE für jedes selbst betriebene Ollama-Deployment gilt. Keine der Maßnahmen ist exotisch – die meisten sind in wenigen Stunden umsetzbar.

Maßnahme	Wirkung	Aufwand
Sofort-Update auf 0.17.1+	Schließt CVE-2026-7482 direkt	Minuten
Bindung an 127.0.0.1 statt 0.0.0.0	Entfernt Erreichbarkeit von außen	Minuten
Authentifizierender Reverse-Proxy vor Port 11434	Erzwingt Login/Token je Zugriff	Stunden
Netzwerksegmentierung & Firewall-Regeln	Begrenzt Erreichbarkeit auf definierte Quellen	Stunden bis Tage
Zero-Trust-Prinzipien für interne KI-Dienste	Reduziert Blast-Radius bei künftigen Lücken	Wochen (organisatorisch)
Regelmäßige Pentests der KI-Infrastruktur	Deckt neue Schwachstellen proaktiv auf	wiederkehrend

Sofortmaßnahmen: Update, Bind-Adresse, Proxy

Die drei wirksamsten Einzelmaßnahmen – Update auf 0.17.1 oder neuer, Bindung an 127.0.0.1 statt 0.0.0.0 und ein authentifizierender Reverse-Proxy vor Port 11434 – werden in praktisch allen Sicherheitsanalysen zu CVE-2026-7482 übereinstimmend als wirksamste Mitigation genannt. Der Reverse-Proxy ist dabei kein Nice-to-have: Selbst nach dem Patch bleibt Ollama ohne vorgeschalteten Login offen für jeden, der das Netzwerksegment erreicht – die nächste Schwachstelle dieser Art ist nur eine Frage der Zeit, nicht der Wahrscheinlichkeit.

Strukturelle Maßnahmen: Segmentierung, Zero Trust, Pentests

Netzwerksegmentierung bedeutet konkret: Ollama-Instanzen gehören in ein eigenes Segment, erreichbar ausschließlich von den Diensten, die sie tatsächlich brauchen – nicht vom gesamten Firmennetz. Zero-Trust-Prinzipien für interne KI-Dienste heißen, jeden Zugriff zu authentifizieren und zu autorisieren, auch wenn er „von innen" kommt; das interne Netz ist kein vertrauenswürdiger Perimeter mehr, sobald Dutzende Abteilungen eigene KI-Tools betreiben. Regelmäßige Pentests schließlich prüfen genau die Klasse von Schwachstellen, die Bleeding Llama repräsentiert – Parser- und Validierungsfehler in selbstgehosteten KI-Frameworks –, bevor sie öffentlich werden. Für Unternehmen, die diese Maßnahmen nicht selbst aufbauen wollen, bieten wir sie als Paket im Rahmen unserer Air-Gapped-On-Premise-KI-Lösungen an – inklusive Netzwerksegmentierung, Zugriffskontrolle und wiederkehrendem KI-Pentest.

Lehren für den Mittelstand: Open-Source-KI sicher betreiben

Die übergeordnete Lehre aus Bleeding Llama betrifft nicht nur Ollama. Open-Source- und Self-Hosted-KI-Werkzeuge sind kein Selbstläufer in Sachen Sicherheit. Ihre Stärke – schnelle Einrichtung, keine Cloud-Abhängigkeit, volle Kontrolle – ist gleichzeitig ihr Risiko: Die Standardkonfiguration ist in aller Regel auf einfache Inbetriebnahme optimiert, nicht auf Angriffsresistenz im Produktivbetrieb. Das gilt für Ollama ebenso wie für vLLM, für Vektordatenbanken und für die meisten Frameworks aus dem schnelllebigen KI-Ökosystem.

Daraus folgt eine organisatorische, keine rein technische Konsequenz: Wer im Unternehmen KI-Infrastruktur aufsetzt – oft ein einzelner engagierter Entwickler oder eine Fachabteilung im Alleingang –, braucht eine klare Governance-Anbindung an IT-Sicherheit, bevor der Dienst produktiv geht. Verantwortlichkeit für Patch-Management, Netzwerkkonfiguration und Zugriffskontrolle darf nicht implizit bei der Person liegen, die zufällig das Setup-Skript ausgeführt hat. Ein einfaches, aber wirksames Mittel ist ein Inventar aller selbstgehosteten KI-Dienste mit benanntem Verantwortlichen – genau das, was im vorigen Praxisbeispiel gefehlt hat.

Auch die Verantwortungsfrage lohnt einen klaren Schnitt: Das Ollama-Projekt hat auf die Meldung reagiert und den Fehler zügig behoben – das ist verantwortungsvolles Schwachstellenmanagement, wie man es sich von einem Open-Source-Projekt wünscht. Was das Projekt nicht liefert und auch nicht liefern kann, ist die sichere Netzwerkkonfiguration beim Betreiber, die Zugriffskontrolle vor dem Dienst oder die Entscheidung, welche Secrets in derselben Prozessumgebung landen. Diese Aufgabenteilung – Hersteller patcht die Software, Betreiber härtet den Betrieb – ist bei kommerzieller Software oft vertraglich geregelt und mit Support-Zusagen unterlegt. Bei selbstgehosteter Open-Source-KI liegt sie vollständig und ausschließlich beim eigenen Unternehmen.

Ein Blick nach vorn: Der EU AI Act baut Melde- und Dokumentationspflichten für schwerwiegende Vorfälle sukzessive aus. Ein Sicherheitsvorfall wie Bleeding Llama, der System-Prompts und Zugangsdaten offenlegt, ist genau die Art von Ereignis, die perspektivisch nachweispflichtig wird – ein weiterer Grund, Härtung nicht erst bei einer konkreten CVE, sondern strukturell zu betreiben. Einen Überblick über die relevanten Fristen geben wir im EU AI Act 2026 im Überblick.

Einordnung: Warum Self-Hosted nicht automatisch sicher ist

On-Premise- und Self-Hosted-Betrieb bringt echte Datenhoheit: Die Entscheidung, wo Daten liegen und wer physischen und administrativen Zugriff hat, bleibt im eigenen Haus. Was er nicht automatisch mitbringt, ist professionelles Hardening, kontinuierliches Monitoring und disziplinierten Betrieb. Bleeding Llama war kein Konstruktionsfehler des On-Premise-Gedankens, sondern ein Beleg dafür, dass Souveränität und Sicherheit zwei verschiedene Baustellen sind, die beide bearbeitet werden müssen.

Wer Ollama, vLLM oder ein vergleichbares Framework im eigenen Haus betreibt und nicht mit letzter Sicherheit sagen kann, ob Netzwerkkonfiguration, Zugriffskontrolle und Patch-Stand aktuell den eigenen Ansprüchen genügen, sollte das nicht auf die lange Bank schieben. Ein strukturierter Sicherheitscheck oder ein gezielter Pentest der KI-Infrastruktur zeigt in der Regel innerhalb weniger Tage, wo die eigenen blinden Flecken liegen – oft an Stellen, die niemand mehr auf dem Schirm hatte.

Quellen & Primärbelege

Alle Zahlen, Fristen und technischen Angaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.

1. SecurityWeek: Kritische Ollama-Lücke exponiert 300.000 Deployments Bestätigt CVE-2026-7482, ~300.000 exponierte Instanzen weltweit, CVSS 9.3 (Medien-Einordnung), Patch in Ollama 0.17.1, Angriffsablauf über /api/create und /api/push.
2. CSO Online: Ollama-Schwachstelle zeigt Risiken ungesicherter KI-Frameworks Beschreibt die Quantisierungs-Pipeline/den GGUF-Loader, konkrete leakbare Datentypen (System-Prompts, Secrets, Kundendaten) und die strukturelle Ursache (Ollama lauscht per Default ohne Authentifizierung).
3. GitHub Security Advisory GHSA-x8qc-fggm-mpqg (CVE-2026-7482) Offizielle, autoritative technische Beschreibung, CVSS v4 8.8 (High), betroffene/gepatchte Versionen (< 0.17.1 / 0.17.1).
4. The Hacker News: Ollama Out-of-Bounds Read Vulnerability Zusätzliche unabhängige Bestätigung von CVE-2026-7482, Angriffsmechanik und Empfehlung zum Update auf 0.17.1.

Häufig gestellte Fragen zu Bleeding Llama

Was ist CVE-2026-7482 ("Bleeding Llama") genau?

CVE-2026-7482 ist eine kritische Schwachstelle im GGUF-Modell-Loader von Ollama: Der /api/create-Endpunkt validiert bei der Modell-Quantisierung nicht, ob die in einer hochgeladenen GGUF-Datei deklarierten Tensor-Offsets und -Größen tatsächlich innerhalb der Dateigrenzen liegen. Ein manipulierter Wert führt zu einem Heap-Out-of-Bounds-Read, der Prozessspeicher preisgibt. Der offizielle GitHub-Security-Advisory bewertet die Lücke mit CVSS v4 8.8 ("High"), mehrere Medien führen sie unter CVSS 9.1-9.3 als "Critical".

Bin ich mit meiner Ollama-Installation betroffen?

Betroffen sind alle Ollama-Versionen vor 0.17.1. Prüfen Sie die laufende Version per 'ollama --version' und aktualisieren Sie umgehend, falls sie älter ist. Besonders kritisch ist es, wenn Ollama nicht nur an 127.0.0.1, sondern per OLLAMA_HOST=0.0.0.0 auf allen Netzwerkschnittstellen lauscht - das ist bei geschätzt rund 300.000 öffentlich erreichbaren Instanzen weltweit der Fall (Stand Offenlegung Anfang Mai 2026).

Wie erkenne ich einen Angriffsversuch auf mein System?

Das ist der eigentliche Schock an Bleeding Llama: Der Angriff besteht aus nur drei unauthentifizierten API-Aufrufen (Upload der präparierten GGUF-Datei, Modell-Erstellung, Exfiltration über /api/push) und hinterlässt keine Fehlermeldungen in den Standard-Logs. Ohne dediziertes Endpoint- bzw. Netzwerk-Monitoring, das ungewöhnliche Requests an /api/create und /api/push erkennt, bleibt ein erfolgreicher Angriff faktisch unsichtbar.

Welche Sofortmaßnahmen schützen mein On-Premise-Deployment?

Erstens: Update auf Ollama 0.17.1 oder neuer. Zweitens: Ollama nie ungeschützt an 0.0.0.0 binden, sondern auf 127.0.0.1 beschränken oder hinter einen authentifizierenden Reverse-Proxy stellen. Drittens: Netzwerksegmentierung und Firewall-Regeln, die Port 11434 grundsätzlich von öffentlichem Zugriff abschotten. Diese drei Maßnahmen wurden in den Sicherheitsanalysen zu CVE-2026-7482 übereinstimmend als wirksamste Mitigation genannt.