LLM-Vergiftung: Angriffe und Abwehrmaßnahmen

Lisa Ernst · 16.10.2025 · Technik · 5 min

Ich stolperte erstmals über das Thema, als ein Team demonstrierte, wie wenige manipulierte Texte genügen, um ein Sprachmodell verlässlich aufs Glatteis zu führen (Anthropic). Seither frage ich: Wie genau wird ein System vergiftet, wo liegen die echten Risiken – und was könnt ihr praktisch tun? Dieser Überblick bündelt aktuelle Befunde, Beispiele und Gegenmaßnahmen aus seriösen Quellen (OWASP).

Quelle: Eigene Darstellung

Einführung

Mit LLM-Poisoning ist das gezielte Einschleusen manipulierter Inhalte in Trainings-, Fine-Tuning-, Retrieval- oder Tool-Daten gemeint, um Modelle zu schwächen, zu verzerren oder versteckte Befehle einzubauen (Backdoors) (OWASP). Eine Backdoor heißt: Ein harmlos wirkender Trigger wie <SUDO> löst beim Modell eine abweichende, vom Angreifer gewünschte Reaktion aus (Anthropic). Neben klassischer Trainingsdaten-Vergiftung gehört auch die Vergiftung von Wissensquellen in RAG-Systemen sowie von Tool-Beschreibungen und Modellartefakten zur weiteren Familie, etwa wenn ein böswilliger Tool-Text das Modell zu unerwünschten Aktionen drängt (Microsoft Developer Blog). NIST ordnet das als „Poisoning“-Klasse in der KI-Sicherheits-Taxonomie ein und nennt u. a. Datenhärtung und Forensik als Gegenmaßnahmen (NIST).

2023 zeigte „PoisonGPT“, dass ein verändertes Open-Source-Modell auf einer populären Plattform unauffällig Falschinformationen verbreiten kann; die Forschenden manipulierten GPT-J-6B und luden es als scheinbar legitimes Modell hoch (Mithril Security Blog).

Quelle: lakera.ai

Der vierstufige Prozess der LLM-Lieferkettenvergiftung durch PoisonGPT.

Im Februar/März 2024 berichteten Sicherheitsfirmen und Medien von mindestens rund 100 bösartigen Modellen auf Hugging Face, die beim Laden Code ausführen konnten; Ursache war u. a. die riskante Nutzung von Pickle-Dateien (JFrog Blog) (BleepingComputer) (Ars Technica) (CSOonline).

Anfang 2024 meldete Protect AI, man habe seit August 2023 insgesamt 3.354 Modelle mit bösartigem Code gefunden und brachte mit „Guardian“ einen Scandienst an den Start (Axios).

2025 vertiefte sich das Bild: Anthropic, UK AI Security Institute und Alan Turing Institute zeigten experimentell, dass bereits etwa 250 passend präparierte Dokumente ein Modell zuverlässig „verlernen“ lassen – also ein Triggerwort mit sinnfreiem Output verknüpfen –, und zwar über verschiedene Modellgrößen hinweg (Anthropic) (Alan Turing Institute Blog).

Parallel wuchsen Abwehrkapazitäten in der Lieferkette: Hugging Face berichtet 2025 über Millionen gescannter Modellversionen und hunderttausende gemeldete „unsafe/suspicious“-Issues durch Partner-Scanner (Hugging Face Blog). Microsoft veröffentlichte 2025 konkrete Schutzmuster gegen indirekte Prompt-Injection in Anwendungen und Tool-Protokollen (Microsoft Security Response Center Blog).

Analyse der Bedrohung

Warum das alles? Angreifer verfolgen drei Hauptlinien: erstens Verfügbarkeit stören (DoS durch Verlernen), zweitens Integrität untergraben (gezielte Falschinformationen, Bias), drittens verdeckte Fähigkeiten einschleusen (Backdoors für Datenabfluss oder Tool-Missbrauch) (OWASP). Plattformdynamiken verstärken die Lage: Offene Modellhubs und offene Daten erleichtern Innovation – aber auch das Einschleusen manipulierter Artefakte, zumal viele Workflows Modelle oder Datensätze automatisiert übernehmen (JFrog Blog) (ACM Digital Library). In Apps mit Webzugriff oder RAG genügt es, Köderdokumente mit versteckten Anweisungen zu platzieren; die LLM-Anwendung übernimmt sie später gutgläubig (Microsoft Developer Blog). Aus Sicht der Verteidiger lautet die Lehre: Defense-in-Depth auf Daten-, Modell- und Anwendungsebene statt alleiniger „Model Safety“-Hoffnung (Microsoft Security Blog).

Kurzer, nüchterner Überblick zu Prompt-Injection-Risiken und warum klassische Sicherheitsgrenzen hier nicht reichen.

Belegt: Es gibt reale Funde bösartiger Modelle in öffentlichen Repositorien; mehrere dutzend bis hundert Fälle wurden 2024 dokumentiert, teils mit Codeausführung beim Laden (JFrog Blog) (BleepingComputer) (Ars Technica).

Belegt: Kleine Giftmengen können reichen. Kontrollierte Studien zeigen, dass wenige hundert präparierte Beispiele robuste Fehlverknüpfungen erzeugen können (Anthropic) (Alan Turing Institute Blog).

Belegt: Prompt-Injection und Tool-Poisoning sind realistische Bedrohungen in agentischen LLM-Apps; Hersteller veröffentlichen konkrete Mitigations (Microsoft Developer Blog) (Microsoft Security Response Center Blog).

Unklar: Wie verbreitet Backdoors in proprietären, nicht offengelegten Trainingskorpora sind, lässt sich aus öffentlichen Quellen nicht verlässlich quantifizieren; hier fehlen unabhängige Audits und reproduzierbare Messungen (NIST).

Falsch/Irreführend: „Poisoning geht nur, wenn Angreifer große Teile der Trainingsdaten kontrollieren.“ Studien zeigen das Gegenteil: schon sehr kleine, gezielte Poisons können starken Effekt haben (Anthropic). Ebenso falsch: „Das betrifft nur Open Source.“ Prompt-Injection und Datenvergiftung zielen auf den Anwendungskontext und die Supply Chain – unabhängig vom Lizenzmodell (OWASP) (Microsoft Security Blog).

Gegenmaßnahmen und Reaktionen

Hugging Face kooperiert seit 2024/2025 mit Sicherheitsanbietern, scannt Millionen Modellversionen und meldet hunderttausende verdächtige Findings; zugleich mahnt die Community zu sorgfältiger Artefaktprüfung und zu sicheren Serialisierungsformaten jenseits von Pickle (Hugging Face Blog) (JFrog Blog). Microsoft veröffentlicht Verteidigungsmuster gegen indirekte Prompt-Injection und betont „Defense-in-Depth“ über Modellgrenzen hinaus (Microsoft Security Response Center Blog) (Microsoft Security Blog). NIST systematisiert Angriffsarten und Gegenmaßnahmen im öffentlichen Leitfaden (NIST). OWASP führt Trainingsdatenvergiftung und Supply-Chain-Risiken prominent im LLM-Top-10-Ranking (OWASP).

Quelle: securiti.ai

Eine LLM-Firewall als Schutzmechanismus gegen schädliche Ausgaben.

Praktisch bedeutet das: Prüft Herkunft, Integrität und Ladepfade eurer Modelle und Daten konsequent. Nutzt Scans und Signaturen für Artefakte, bevorzugt sichere Formate (z. B. safetensors statt ungeprüfter Pickles), und isoliert Ladeprozesse technisch (JFrog Blog) (Hugging Face Blog). Begrenzt den Einfluss ungetesteter Quellen in RAG, setzt Input- und Output-Filter sowie strikte Tool-Policies um, besonders bei Agenten und Automationen (Microsoft Developer Blog) (Microsoft Security Blog). Orientiert euch an OWASP LLM Top 10 und NIST-Empfehlungen; führt PoC-Tests mit bekannten Poisoning- und Injection-Mustern durch und dokumentiert Abwehrmaßnahmen (OWASP) (NIST).

Kurze, verständliche Erklärung zu Datenvergiftung, nützlich als Einstieg für Teams.

Ausblick

Wie lassen sich Backdoors in großen, proprietären Trainingsmengen zuverlässig erkennen, ohne die Daten komplett offenzulegen? Hier fehlen standardisierte Auditverfahren und unabhängige Testsuiten (NIST). Wie robust sind heutige Mitigations gegen adaptives, mehrstufiges Poisoning in RAG- und Agenten-Setups? Die Forschung berichtet fortlaufend über neue Angriffspfade; aktuelle Arbeiten zu skalierten Prompt-Attacken und RAG-Poisoning unterstreichen den Handlungsbedarf (OpenReview) (arXiv).

LLM-Poisoning ist kein Randthema, sondern eine Querschnittsgefahr über Daten, Modelle, Tools und Anwendungen. Die gute Nachricht: Mit sauberer Herkunftskontrolle, sicheren Ladepfaden, RAG-Hygiene, Defense-in-Depth und laufenden Tests lässt sich das Risiko deutlich senken (OWASP) (NIST) (Microsoft Developer Blog). Wer heute die Kette härtet, spart morgen Vorfälle – und behält die Gestaltungshoheit über die eigenen KI-Systeme (Hugging Face Blog) (Anthropic).