Das Sicherheitsparadox lokaler LLMs

• Forschungsergebnisse zeigen, dass Entwickler, die LLMs in lokalen Umgebungen zum Schutz der Privatsphäre einsetzen, dadurch paradoxerweise Sicherheitslücken ausgesetzt sein können
• Das Forschungsteam bestätigte in Experimenten der OpenAI Red‑Teaming Challenge mit dem Modell gpt-oss-20b, dass sich lokale Modelle durch manipulierte Prompts deutlich leichter täuschen lassen und Schadcode erzeugen
• Angreifer können allein durch einfache Prompt-Manipulationen Backdoors einbauen oder sofortige Codeausführung (RCE) auslösen; die Erfolgsquote liegt bei bis zu 95 %
• Solche Angriffe dringen auf natürlichem Weg in typische Entwickler-Workflows ein, etwa über Documentation Poisoning, Manipulation von MCP-Servern oder Social Engineering
• Lokale LLMs haben zwar Vorteile beim Datenschutz, könnten aber wegen mangelnder Schlussfolgerungsfähigkeit, Ausrichtung und Safety-Filterung die riskantere Wahl sein — das ist die zentrale Aussage der Studie

---

Überblick über die Sicherheitslücken lokaler LLMs

• Die Studie zeigt, dass lokal ausgeführte LLMs zwar oft als Wahl zur Stärkung von Sicherheit und Privatsphäre gelten, in der Praxis aber für Angreifer leichter manipulierbar sein können
  • In Tests mit dem Modell gpt-oss-20b war der Anteil sehr hoch, mit dem das Modell auf Prompt-Anfragen Code mit Schwachstellen direkt erzeugte
  • Besonders problematisch: Selbst wenn die böswillige Absicht im Prompt verborgen war, erkannte das Modell sie nicht und behandelte die Anfrage als legitim
• Dieses Phänomen verstärkt sich, je geringer Modellgröße und Alignment-Niveau sind; Frontier-Modelle (etwa GPT-5) sind vergleichsweise widerstandsfähiger

Bedrohungen durch Prompt- und Code-Injection

• LLMs stehen vor einer „lethal trifecta“ aus Zugriff auf private Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und Möglichkeit externer Kommunikation
  • Angreifer können bösartigen Code in Prompts einbetten und so Code-Injection auslösen
  • Der dabei erzeugte Code wirkt unauffällig, kann aber tatsächlich Entwicklersysteme infizieren oder in Produktionsumgebungen als persistente Backdoor arbeiten
• Kleinere Modelle wie gpt-oss-20b sind für solche Angriffe besonders anfällig und erzeugen ausgereiften Schadcode, der sogar einfache Code-Reviews bestehen kann

Angriffstyp 1: „Easter-Egg“-Backdoor (Erfolgsquote 95 %)

• Der erste Angriff verleitet das Modell dazu, eine RCE-Backdoor (Remote Code Execution) als „Easter Egg“-Funktion getarnt einzubauen
  • Der Angriffsprompt fordert einen Flask-Webserver an, der bei Übergabe eines bestimmten HTTP-Headers (X-Math) eval() ausführt
  • Das Modell interpretiert dies als normale Funktionalität und erzeugt Servercode mitsamt Schadlogik
• Der erzeugte Code enthält eine dynamische Code-Ausführungsroutine über den Decorator @app.after_request, wodurch Angreifer per einfachem HTTP-Request beliebigen Code auf dem Server ausführen können
  • Zusätzlich prüft der Code die Umgebungsvariable KUBERNETES_SERVICE_HOST und enthält eine asynchrone Ping-Funktion, die nur in Produktionsumgebungen ein Signal an den Angreifer sendet
• Im Experiment war derselbe Prompt in 95 von 100 Versuchen erfolgreich; auch mit variierten Prompts gelang der Angriff in 86 von 800 Fällen
  • Frontier-Modelle wie GPT-5 zeigten gegenüber demselben Prompt Widerstand

Angriffstyp 2: Auslösung sofortiger Codeausführung (RCE) (Erfolgsquote 43,5 %)

• Der zweite Angriff zielt darauf ab, bösartigen Code sofort in der lokalen Entwicklerumgebung auszuführen
  • Zunächst erhöht der Angreifer mit einem Prompt zur kognitiven Überlastung (cognitive overload) die mentale Last des Modells und schwächt so Safety-Filter
  • Danach fordert er die Erzeugung von verschleiertem Python-Code an, sodass das Modell ein bösartiges Skript mit exec-Aufruf schreibt
• Der verschleierte Code "".join(chr(100 + i) for i in [1-2, 2-1, (1<<4)+4, 1])[::-1] wird zu exec entschlüsselt,
  und endet schließlich in einem Ablauf, der Code von https://jacek.migdal.pl/speed.py herunterlädt und ausführt
• Mit 43,5 % ist die Erfolgsquote zwar niedriger als beim ersten Angriff, doch wegen der sofortigen RCE ist die Gefahr deutlich größer
  • Schon ein einziger erfolgreicher Angriff kann lokale Zugangsdaten des Entwicklers (~/.aws/, ~/.ssh/) kompromittieren, Malware installieren oder eine Ausbreitung im Netzwerk ermöglichen

Funktionsweise der Angriffskette

• Diese Angriffe beruhen nicht auf hochkomplexen Schwachstellen, sondern darauf, alltägliche Entwickler-Workflows in Angriffswege zu verwandeln
  • Wenn Entwickler externe Inhalte als Kontext an einen AI-Assistenten übergeben, können darin verborgene bösartige Prompts ausgeführt werden
• Die Angriffsschritte sind wie folgt:
  1. Ein Angreifer verbreitet Inhalte mit eingebetteten bösartigen Prompts
  2. Ein Entwickler gibt diese direkt oder über MCP (Model Context Protocol) an das Modell weiter
  3. Das Modell erzeugt kompromittierten Code
  4. Der Entwickler führt den Code aus oder deployt ihn
  5. Der Angreifer erlangt dauerhaften Zugriff oder unmittelbare Kontrolle
• Wichtige Einschleusungswege:
  • Documentation Poisoning: Einschleusen von Schadcode in README-Dateien, API-Dokumentation oder Reddit-Beispiele
  • Manipulation von MCP-Servern: Einspeisen bösartiger Beispiele über Server zur Kontextbereitstellung (wie Context7)
  • Social Engineering: Versteckte Codebeispiele in GitHub-Issues oder PR-Kommentaren

Warum lokale Modelle riskanter sein können

• Lokale Modelle werden allgemein wegen des Datenschutzes bevorzugt, doch diese Studie zeigt ein paradoxes Risiko auf Sicherheitsseite
  • Cloud-basierte Frontier-Modelle können Prompt-Monitoring und Erkennung von Policy-Verstößen nutzen; lokale Modelle verfügen nicht über diese Überwachung
  • Frontier-Modelle (GPT-5, Claude Sonnet 4.5, Grok 4 usw.) geben bei Prompts mit verschleiertem Text „Safety Fail“ zurück und lehnen sie ab
• Lokale Modelle erlauben zwar durch die fehlende Überwachung freieres Testen, sind in der Praxis aber erheblich stärker exponiert
  • Schwächere Schlussfolgerungsfähigkeit: Komplexe bösartige Absichten werden nicht erkannt
  • Schwächeres Alignment: Kognitive Überlastung oder Verschleierungstechniken funktionieren leichter
  • Weniger Safety-Training: Begrenzte Ressourcen für die Erkennung adversarieller Prompts
• Dadurch sind Frontier-Modelle schwieriger anzugreifen und weisen niedrigere Erfolgsquoten auf, während ihre Sicherheitsleistung objektiv schwer zu verifizieren ist; lokale Modelle sind dagegen zwar gut testbar, aber deutlich anfälliger

Vorschläge für neue Verteidigungsstrategien

• Die Studie weist auf das Fehlen einer standardisierten sicheren Umgebung für Sicherheitstests von AI-Assistenten hin
  • Für klassische Software gibt es Penetrationstests, für LLM-Sicherheit fehlt bislang noch eine systematische Praxis
• Vier vorgeschlagene Kernmaßnahmen:
  1. Statische Analyse: Vor der Ausführung riskante Muster wie eval() oder exec() erkennen und bestimmte Sprachfunktionen standardmäßig deaktivieren
  2. Sandbox-Ausführung: Erste Codeausführungen in isolierten Umgebungen wie Containern oder WebAssembly-Runtimes durchführen
  3. Ein-/Ausgabe- und Netzwerk-Monitoring: Eingaben, Ausgaben und Netzwerkverkehr des AI-Assistenten auf auffälliges Verhalten überwachen
  4. Second Look: Das Endergebnis zusätzlich mit einem einfachen Hilfsmodell auf Policy-Verstöße prüfen
     • Beispiel: Selbst wenn das Hauptmodell dazu gebracht wird, Code mit eval() zu erzeugen, kann das Hilfsmodell dies noch erkennen
• Fazit: LLMs sind mächtige Werkzeuge, aber nicht inhärent sicher;
  daher sind misstrauensbasierte Sicherheitsmechanismen für AI-generierten Code und neue Supply-Chain-Verteidigungsstrategien unverzichtbar

[GN⁺]

Hacker-News-Kommentare

• Selbst ein noch so leistungsfähiges reasoning LLM gibt am Ende anfälligen Code aus, wenn sich bösartige Anweisungen im Kontext befinden.
  Dass kleine Modelle leichter zu täuschen sind, ist aus Sicherheitssicht kein besonders interessanter Punkt.
  Letztlich muss man bei jedem Modell davon ausgehen, dass prompt injection möglich ist.
  Deshalb braucht es zusätzliche Schutzschichten wie Sandbox-Ausführung oder statische Analyse, die auch dann noch verteidigen können, wenn das Modell kompromittiert wurde.
  Gestern habe ich zu genau diesem Thema auch einen Vortrag über sandboxing coding agents gehalten.

  • Am schockierendsten an dem Artikel war für mich, dass es offenbar als selbstverständlich angesehen wird, ungeprüfte externe Inhalte direkt in ein LLM einzuspeisen und das Ergebnis als Produktionscode zu verwenden.
    Ein solches System ist praktisch bereits kompromittiert.
    Statt eines Ansatzes wie defense in depth sollte man meiner Meinung nach so eine riskante Architektur von vornherein gar nicht erst bauen.
  • Unser Team hat den Agenten von Definite.app ebenfalls eine auf e2b.dev basierende Sandbox vorgeschaltet, und das fühlt sich an, als hätte es 80 % der Probleme gelöst.
    Auch Dinge wie temporäre Dateispeicherorte werden in einer Sandbox-Umgebung klarer.
    Natürlich sind neue Probleme entstanden, aber insgesamt war es eine große Verbesserung.
  • Ich frage mich, ob dieser Vortrag aufgezeichnet wurde.

• Wenn man lokal ein Modell wie deepseek betreibt, halte ich es für sicher, solange man ihm keine gefälschten Prompts gibt.
  Das eigentliche Risiko entsteht letztlich durch Prompts, die Nutzer von außen hineinkopieren, oder durch Konfigurationen, die dem Modell Zugriff auf Internet-Ressourcen geben.
  Solche Dinge sind schon lange Schwachstellen in der gesamten IT und müssen einfach durch Nutzerschulung und Netzwerkisolierung kontrolliert werden.

  • Neu ist, dass bereits eine bloße Texteingabe ein Angriffsvektor sein kann.
    Gewöhnliche Daten wie Tickets oder Dokumente können nun zum Sicherheitsrisiko werden.
  • Auch wenn es wenig realistisch erscheinen mag, muss man sich solcher Angriffsvektoren unbedingt bewusst sein.
    Viele mächtige Hacks begannen mit einem einfachen Ausgangspunkt.

• Diese Angriffe bewegen sich auf dem Niveau von allzu grundlegendem Sicherheitswissen.
  Man könnte sie schon dadurch verhindern, dass man den Code vor dem Deployment in Produktion überprüft.
  Wenn man gar keine Ahnung hat, wird man ohnehin unsicheren Code deployen.

  • Der Kernpunkt ist nicht bloß das Scheitern bei der Code-Generierung, sondern dass das Modell für Jailbreak-Angriffe anfälliger ist.
    Offene Modelle sind gut zugänglich, aber zu glauben, man könne das mit post-training verhindern, ist ein Irrtum.
  • Die Haltung „Code-Review reicht aus“ ist gefährlich.
    Beim zweiten Angriff ging es nicht um das Deployment von Code, sondern um eine Situation, in der ein LLM einen Reddit-Kommentar liest und sofort ausführt.
    Schon die nachlässige Haltung gegenüber solchen Problemen schafft eine noch größere Sicherheitsbedrohung.

• Es klingt merkwürdig zu sagen, dass ein lokales LLM angegriffen werden kann.
  Wenn das System bereits kompromittiert ist, könnte man doch größeren Schaden anrichten, als nur das LLM zu täuschen.

  • Ein LLM unterscheidet nicht zwischen Befehlen und Daten.
    Das heißt, ein Angreifer kann über Dateneingaben Prompt-Injektionen einschleusen.
    Wenn das LLM ein Agent mit Berechtigungen zur Befehlsausführung ist, wird daraus unmittelbar eine Remote-Code-Execution-Schwachstelle.
  • Wenn man ein LLM zur Klassifizierung von Kundendaten oder zur Verarbeitung von E-Mails einsetzt, kann dieses Risiko durchaus real sein.
  • Selbst lokale Modelle sind in der Praxis oft mit Wrappern mit Internetzugang verbunden, zum Beispiel OpenCode oder Claude Code.
  • Das ähnelt einer Unternehmens-Sicherheitslogik wie: „Was wäre, wenn ein Angreifer das VPN durchbricht und sich mit Admin-Rechten anmeldet?“
    In so einer Situation ist ohnehin schon alles vorbei.

• Dieser Text wirkt, als wäre er von einem Vertriebsteam von Anthropic oder OpenAI geschrieben worden.
  In der Praxis werden lokale Modelle selten als Agenten zur Codeausführung verwendet; ihre Stärke liegt meist eher bei Datentransformation oder NLP-Aufgaben.
  Wenn ich mit einem Agno agent ein lokales Modell verwende, lasse ich den erzeugten Code vor der Ausführung immer zuerst ausgeben und schotte ihn in einer lokalen Sandbox ab.
  Ich halte browserartige Agenten wie Atlas oder Comet eher für das größere Risiko.

• Das Open-Source-Modell hat sich so verhalten, wie es im Prompt stand, während das Closed-Source-Modell das ignoriert hat.
  Mit anderen Worten: Beim Alignment-Test ist eher das geschlossene Modell durchgefallen.

• Der Ausdruck lethal trifecta klingt zwar gut, beschreibt das tatsächliche Risiko aber nicht besonders treffend.
  Realistisch gesehen reicht schon die Fähigkeit zur externen Kommunikation aus, um ausreichend gefährlich zu sein.
  Das LLM selbst ist ein nicht verifizierbarer Black-Box-Datenklumpen, dem man nur schwer vertrauen kann.
  Für kleine Startups mag das in Ordnung sein, aber an einem Ort wie Coinbase würde ich Zugangsbeschränkungen zweimal überdenken.

• Es geht hier um das Sicherheitsparadox der Ausführung nicht verifizierten Codes.
  Wenn man lokal Schadsoftware oder unbestätigten Code ausführt, sollte man zuerst den Grund dafür noch einmal überdenken.

  • Diese Schwachstelle entsteht, wenn eine AI nicht vertrauenswürdige Daten, die sie im Internet gelesen hat, unverändert verarbeitet.
    LLMs interpretieren Anweisungen in natürlicher Sprache wie Code, wodurch die Grenze zwischen Code und Daten unscharf wird.

• Wenn man die Schlussfolgerungsfähigkeit eines LLMs als Sicherheitsgrenze betrachtet, hat man bereits ein großes Problem.
  Ein solcher Ansatz ist grundsätzlich eine Fehlkonstruktion.

• Dass Injektionen auftreten können, wenn man nicht auf Eingaben achtet, ist allzu offensichtlich.
  In jedem System können Eingaben immer ein Angriffsvektor sein.
  Alle Daten, die in ein LLM eingehen, müssen unbedingt validiert werden.

  • Ich frage mich, wie ein Angreifer solche Prompts einschleusen kann, um tatsächlichen Produktionscode zu beeinflussen.
    Läuft das vielleicht über etwas wie Cross-Site-Angriffe im Browser?