DEF CON 34: 10 Schwachstellen gefährden lokale KI

Lokale KI bietet Unternehmen mehr Datenschutz, Kostenkontrolle und Datenhoheit, doch der lokale Betrieb von Modellen beseitigt Sicherheitsrisiken nicht. 

Untersuchungen die im Zusammenhang mit DEF CON 34 vorgestellt wurden identifizierten 10 Schwachstellen in llama[.]cpp, einer weit verbreiteten Inferenz-Engine, die vielen lokalen KI-Anwendungen zugrunde liegt.

Die wichtigsten Erkenntnisse

• Forscher identifizierten 10 Schwachstellen in llama[.]cpp, darunter Use-after-free, Integer-Überläufe und Speicherzugriffsfehler außerhalb gültiger Grenzen, die mehrere Vertrauensgrenzen betreffen.
• Zwei Schwachstellen in llama-server erhielten CVSS-Werte von 9,2, was das potenzielle Risiko für Unternehmen verdeutlicht, die lokale KI-Inferenzdienste für nicht vertrauenswürdigen Datenverkehr zugänglich machen.
• Lokale KI beseitigt Sicherheitsrisiken nicht. Die Speicherung von Prompts und sensiblen Daten in der eigenen Infrastruktur erfordert weiterhin, die Inferenz-Engine, Modelle, APIs, Abhängigkeiten und unterstützende Infrastruktur abzusichern.
• Unternehmen sollten ermitteln, wo llama[.]cpp eingesetzt wird, und die Angriffsfläche reduzieren, unter anderem durch die Härtung internetseitig erreichbarer APIs, die Validierung nicht vertrauenswürdiger Eingaben, das Einspielen von Patches für anfällige Komponenten, die Segmentierung von KI-Workloads und die Überwachung auf verdächtige Aktivitäten.

llama.cpp und lokale LLM-Inferenz verstehen

Bei der Inferenz großer Sprachmodelle (LLMs) werden die trainierten Modellgewichte in den Speicher geladen, Eingabetokens durch das Modell verarbeitet und die Ausgabe Token für Token erzeugt. 

Bei der Remote-Inferenz werden Prompts und Daten an einen externen Anbieter übertragen. Bei der lokalen Inferenz finden diese Vorgänge stattdessen auf einer vom Nutzer oder Unternehmen kontrollierten Infrastruktur statt.

Dieser Unterschied ist für Unternehmen wichtig, die mit geistigem Eigentum, Verschlusssachen, eigenen Finanzstrategien oder anderen sensiblen Daten umgehen, die nicht an Drittanbieter von KI-Diensten übermittelt werden dürfen.

Was ist llama.cpp und wie unterstützt es lokale KI?

Llama[.]cpp hat sich zu einer wichtigen Komponente dieses Ökosystems entwickelt. 

Die hauptsächlich in C/C++ geschriebene Bibliothek lädt GGUF-Modelldateien, verwaltet Inferenzkontexte, führt Tokenisierung und Modellberechnungen durch und stellt Schnittstellen bereit, die von anderen Anwendungen genutzt werden. 

Sie dient als Backend oder Integrationsschicht für Produkte wie Ollama, LM Studio, Jan und GPT4All.

Ihre weite Verbreitung bedeutet zugleich, dass Schwachstellen in der zugrunde liegenden Engine potenziell zahlreiche nachgelagerte Implementierungen beeinträchtigen können.

Schwachstellen in Llama[.]cpp legen kritische Speicherfehler offen

Forscher von Cyera untersuchten llama[.]cpp mit besonderem Augenmerk auf drei Vertrauensgrenzen: 

• Android-Java-Native-Interface-(JNI)-Integrationen
• den HTTP-Lebenszyklus von llama-server
• die Verarbeitung von GGUF-Modellmetadaten

Die Untersuchung identifizierte Schwachstellen im Zusammenhang mit bekannten Speicherfehlern, darunter Use-after-free (UAF), Integer-Überläufe und Zugriffe außerhalb gültiger Grenzen. 

VulnCheck vergab anschließend CVE-2026-43622 bis CVE-2026-43632 für die gemeldeten Befunde, mit Ausnahme von CVE-2026-43625 (CodexBar-Schwachstelle).

Zum Stand einer Bewertung von Build b9445 und gguf-v0.19.0 im Juni 2026 berichteten die Forscher, dass fünf der 10 Schwachstellen weiterhin ungepatcht waren. 

Zu den bedeutendsten gehörten zwei UAF-Schwachstellen im Server, CVE-2026-43631 und CVE-2026-43632, die jeweils einen CVSS-Wert von 9,2 aufweisen.

Wie Fehler bei der Nebenläufigkeit Speichersicherheitsrisiken in lokaler KI erzeugen

Mehrere Befunde zeigen, wie Nebenläufigkeit gewöhnliche Fehler bei der Speicherverwaltung in Sicherheitslücken verwandeln kann.

Nebenläufigkeit im Android-JNI erzeugt Use-after-free-Risiken

In einer älteren Android-JNI-Integration nutzten mehrere Vorgänge globale native Zeiger gemeinsam. 

Ein Hintergrundthread konnte eine Inferenz durchführen, während ein anderer Thread denselben Kontext freigab. 

Ohne ausreichende Synchronisierung konnte der erste Thread anschließend auf Speicher zugreifen, der bereits freigegeben worden war.

Die Forscher berichteten, dass sie diese Bedingung ausnutzten, indem sie den freigegebenen Speicher zurückerlangten und die weitere Programmausführung manipulierten.

Fehler in llama-server führen zu einer weiteren Use-after-free-Bedingung

Ein ähnliches Problem bei der Verwaltung von Objektlebenszyklen betraf llama-server. 

Wenn die Funktion –sleep-idle-seconds aktiviert war, konnte das Beenden im Leerlauf Modell- oder Vokabularressourcen freigeben, während ein anderer Worker weiterhin eine Anfrage mit diesen Ressourcen verarbeitete. 

Dadurch entstand eine weitere UAF-Bedingung, die potenziell über die Serverschnittstelle erreichbar war.

Diese Befunde verdeutlichen eine wichtige Sicherheitsüberlegung bei lokaler KI: Die Speicherung von Prompts in der eigenen Umgebung stellt nicht automatisch sicher, dass der zugrunde liegende Inferenz-Stack vertrauenswürdig ist. 

So lassen sich die Schwachstellen in llama[.]cpp eindämmen

Unternehmen, die llama[.]cpp einsetzen, sollten zunächst feststellen, wo die Bibliothek in ihrer KI-Umgebung vorhanden ist, einschließlich Anwendungen, die sie indirekt integrieren.

llama-server und API-Zugriff absichern

Bei internetseitig erreichbaren llama-server-Bereitstellungen sollte –sleep-idle-seconds bei der Annahme nicht vertrauenswürdigen HTTP-Datenverkehrs nicht aktiviert werden, bis bestätigt ist, dass die zugehörigen UAF-Schwachstellen behoben wurden. 

APIs sollten nicht uneingeschränkt auf 0.0.0.0 erreichbar sein, sondern eine Authentifizierung über einen Reverse-Proxy oder eine vergleichbare Zugriffskontrollschicht verwenden, um unbefugten Zugriff zu begrenzen. 

llama.cpp-Integrationen und nicht vertrauenswürdige Eingaben absichern

Android-Entwickler, die den älteren llama-android[.]cpp-JNI-Wrapper verwenden, sollten von Versionen vor Build b7446 migrieren und native Komponenten auf unsicheren gleichzeitigen Zugriff überprüfen.

Anwendungen, die llama_batch_init verwenden, sollten nicht vertrauenswürdige Eingaben validieren, bevor sie an nativen Code übergeben werden. 

Ebenso sollten Anwendungen das Wiederherstellen von Zuständen oder KV-Cache-Daten aus nicht vertrauenswürdigen Quellen vermeiden, bis die damit verbundenen Speicherfehler behoben sind. 

So sichern Sie lokale KI und Modelle mit offenen Gewichten ab

Lokale Inferenz bietet erhebliche Vorteile bei Datenschutz und Kontrolle, doch diese Vorteile bringen die Verantwortung mit sich, die Laufzeitumgebung selbst abzusichern.

Speicherbeschädigungen, unsichere Objektlebenszyklen, schädliche Modelldateien und offen zugängliche Inferenz-APIs können Angriffsflächen schaffen, die mit denen herkömmlicher nativer Anwendungen vergleichbar sind.

Unternehmen, die KI mit offenen Gewichten einsetzen, sollten Inferenz-Engines daher als sicherheitskritische Infrastruktur betrachten und unter anderem folgende Kontrollen integrieren:

• Ein Inventar der lokalen KI-Modelle führen, Inferenz-Engines, Abhängigkeiten und sonstigen Komponenten.
• Die Netzwerkexposition beschränken und KI-Workloads segmentieren von sensiblen Produktionssystemen.
• Zugriff nach dem Prinzip der geringsten Privilegien durchsetzen und eine starke Authentifizierung für APIs und administrative Funktionen verlangen.
• Modelldateien validieren und scannen, ebenso Zustandsdateien, Abhängigkeiten und andere Artefakte vor der Bereitstellung.
• SicherheitsPatches zeitnah anwenden und vorgelagerte Projekte sowie Abhängigkeiten auf neu offengelegte Schwachstellen überwachen.
• Inferenz-Workloads mithilfe von Containern, virtuellen Maschinen oder anderen Isolierungsmechanismen, wo dies angemessen ist, in einer Sandbox ausführen.
• Aktivitäten von KI-Systemen protokollieren und überwachen sowie regelmäßig Pläne zur Reaktion auf Sicherheitsvorfälle testen, um sicherzustellen, dass Teams Sicherheitsvorfälle im Zusammenhang mit KI eindämmen und beheben können.

Zusammengenommen können diese Maßnahmen Unternehmen dabei helfen, die Gefährdung durch KI-bezogene Bedrohungen zu verringern und zugleich ihre Widerstandsfähigkeit zu stärken. 

Fazit

Die Schwachstellen in llama[.]cpp verdeutlichen eine wichtige Realität lokaler KI: Die Speicherung sensibler Daten innerhalb der Unternehmensumgebung kann Datenschutz und Kontrolle verbessern, beseitigt Sicherheitsrisiken jedoch nicht. 

Unternehmen müssen die Inferenz-Engines, Modelle, Abhängigkeiten und die Infrastruktur absichern, die diese Daten verarbeitet, um die Gefährdung zu verringern und widerstandsfähigere lokale KI-Bereitstellungen aufzubauen. 

Zero Trust kann diesen Schutz erweitern, indem es Zugriffe nach dem Prinzip der geringsten Privilegien durchsetzt, Vertrauen kontinuierlich validiert und die möglichen Auswirkungen eines kompromittierten KI-Workloads oder einer kompromittierten Komponente begrenzt.