On-Premise- oder lokal betriebene LLMs über Ollama oder LM Studio sind inzwischen Teil ausgeschriebener Infrastruktur-Rollen. Wer aktuell eine Stelle für On-Premise- oder LLM-Infrastructure-Engineering ausschreibt oder eine dieser Runtimes öffentlich nennt, betreibt diese Modelle in aller Regel produktiv. Genau dort liegt eine Lücke, die mit CVE-2026-7482 sichtbar wurde.
Bleeding Llama: eine kritische Lücke in Ollama
Die Schwachstelle CVE-2026-7482, bekannt als „Bleeding Llama“, hat laut CVSS 3.1 einen Score von 9.1 (Critical), Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L. Betroffen sind Ollama-Versionen vor 0.17.1, die Korrektur liegt mit 0.17.1 vor. CVSS-Vektor und Versionsangaben sind bei Indusface dokumentiert, die technische Beschreibung des Fehlers bei runZero.
Wie der Angriff abläuft
Der Fehler liegt im GGUF-Model-Loader von Ollama. Ein unauthentifizierter Angreifer sendet eine präparierte GGUF-Datei an den Endpunkt /api/create. Die Datei deklariert Tensor-Offsets und -Größen, die über die tatsächliche Dateilänge hinausgehen. Beim Quantisieren liest Ollama dadurch über den zugewiesenen Heap-Puffer hinaus und legt dabei Umgebungsvariablen, API-Keys und System-Prompts offen. Über den Endpunkt /api/push lassen sich diese Daten anschließend exfiltrieren.
Ollama bindet standardmäßig an 127.0.0.1, also nur lokal. Erreichbar wird eine Instanz über das Netz erst, wenn OLLAMA_HOST=0.0.0.0 gesetzt ist, eine Einstellung, die in der Praxis verbreitet vorkommt. Mehrere Branchenblogs schätzen die Zahl dadurch öffentlich erreichbarer Ollama-Server unabhängig voneinander auf rund 300.000. Eine eigene Methodik dafür nennt keiner dieser Blogs, die Zahl ist also eine Fremdschätzung und keine eigene Erhebung.
Das eigentliche Problem bleibt nach dem Patch bestehen
Bleeding Llama ist der aktuellste Beleg für ein strukturelles Problem, keine Ausnahme. Lokal abgelegte Modell-Dateien laufen in den meisten Setups ohne Signaturprüfung und ohne Stückliste. Für Software-Abhängigkeiten ist diese Prüfpraxis etabliert: npm-Pakete, Container-Images und ihre Herkunft lassen sich über eine SBOM nachvollziehen. Für ein GGUF-Modell gibt es in der Regel kein vergleichbares Dokument. Das Modell ist ein binäres Artefakt ohne Build-Log und meist ohne durchgehenden Herkunftsnachweis zur ursprünglichen Download-Quelle. Ob die Datei, die heute auf dem Server liegt, noch exakt die ist, die einmal heruntergeladen wurde, lässt sich ohne Hash-Verifikation gegen die Quelle nicht beantworten.
Wie diese Prüfpraxis für klassische Software-Komponenten aussieht, steht in SBOM vom Lieferanten prüfen: vier Checks vor dem Ablegen. Dort geht es um die SBOM einer Software-Komponente, die ein Lieferant mitliefert. Bei einem lokal abgelegten LLM-Modell fehlt dieses Dokument in der Regel ganz, das Modell selbst ist das ungeprüfte binäre Artefakt.
Was sich jetzt konkret prüfen lässt
- Die OLLAMA_HOST-Konfiguration kontrollieren: läuft die Instanz nur auf 127.0.0.1, oder wurde 0.0.0.0 gesetzt?
- Den Versionsstand prüfen und auf 0.17.1 oder neuer aktualisieren.
- Herkunft jeder geladenen GGUF-Datei dokumentieren: Bezugsquelle, Datum, Prüfsumme.
- Den Hash der lokal liegenden Datei gegen die vom Anbieter veröffentlichte Prüfsumme verifizieren, wo eine solche Prüfsumme existiert.
Eine strukturierte Übersicht, welche Prüfschritte dafür am eigenen Modellbestand einzeln nötig sind, steht unter mhm-digitale-loesungen.de/llm-sbom-check.
Das Leistungsspektrum ist gestaffelt und baut auf Delivery-Transparenz auf. Es läuft über drei Felder: Implementation (Delivery- und Nachweiskontrollen in die Pipeline einziehen), AI Governance (Nachvollziehbarkeit dort schaffen, wo KI-gestützte Schritte in Build und Deployment Freigaben und Verantwortung verwischen) und Maintenance (die Übergabefrage: wem ein System nach dem Go-Live gehört und woran man merkt, dass es niemandem gehört). Ein festes Angebot daraus entsteht erst, wenn klar ist, was du wirklich brauchst. Kontakt: mm@mhm-dl.de.
Kommentar verfassen