KI sieht den Bug vor lauter Bäumen nicht : Kontextüberflutung als Angriffsvektor gegen KI-gestützte Code-Reviews

Katastrophale Kommentare

„Indirect Prompt Injection“ (IDPI) bezeichnet die Platzierung manipulativer Anweisungen in Daten, die ein Modell verarbeitet, ohne dass ein Nutzer diese Anweisungen autorisiert hat. Anders als bei direkter Prompt-Injection, bei der ein Anwender ein Modell über eine Chat-Schnittstelle explizit umzustimmen versucht, steckt die Manipulation hier in Web-Inhalten, E‑Mails oder Quellcode.

Für automatisierte Sicherheitsprüfungen ist das relevant, weil Kommentare, Docstrings und Variablennamen ein natürlicher Bestandteil des Inputs sind und sich nicht ohne Weiteres von legitimer Dokumentation unterscheiden lassen. Das OWASP führt Prompt-Injection seit zwei Ausgaben in Folge als höchstes Risiko in seinem Top-10-Katalog für Large-Language-Model-(LLM)-Anwendungen [2] – inzwischen ergänzt um einen eigenen Katalog für agentische Systeme künstlicher Intelligenz (KI) [3].

Sprachliche Täuschung: begrenzte Wirkung, schmales Zeitfenster

Eingebettete „Unbedenklichkeitserklärungen“ (sog. Notice-to-AI-Lures), die ein Modell von der Harmlosigkeit des Codes überzeugen sollen, erhöhen bei leistungsfähigen Modellen in der Regel den Verdacht. Ein Kommentarblock, der ausdrücklich betont, der folgende Code sei sicher und dürfe nicht als schädlich eingestuft werden, wirkt auf ein gut trainiertes Modell eher wie ein Warnsignal.

Diese Beobachtung gilt jedoch nur oberhalb einer bestimmten Schwelle: Bleibt der Anteil solcher Lures unter 1 % des gesamten Codes, sinkt die durchschnittliche Erkennungsrate über alle Modelle hinweg von einer Baseline von 67,3 % auf 53,3 %. Oberhalb von 25 % Kommentaranteil kehrt sich der Effekt um: Die Erkennung steigt auf 99 %, da die Menge an Unbedenklichkeitserklärungen selbst zum eindeutigen Erkennungsmerkmal wird.

Für Sicherheitsteams bedeutet das: Filter, die auf auffällige oder gehäufte Formulierungen setzen, greifen ins Leere, sobald ein Angreifer die Dosierung kennt und Lures sparsam und verteilt platziert.

Die Modellklasse entscheidet über die Anfälligkeit

Wie anfällig ein Modell für solche Manipulation ist, hängt stark von seiner Leistungsklasse ab. Kostenoptimierte Modelle lassen sich mit wenig Aufwand aus dem Tritt bringen: Bei einem der in der genannten Studie getesteten Modelle genügten 1–20 verteilte Kommentare, um die Erkennungsrate von 90 % auf 67 % zu senken. Leistungsstarke Modelle erweisen sich als deutlich robuster: Ein Frontier-Modell verschob sein Urteil selbst bei 1000 Kommentaren nur um wenige Prozentpunkte. Verlässlich und durchgängig ist dieses Bild jedoch nicht: Ein anderes kostenoptimiertes Modell performte konstant niedrig – ohne erkennbare Reaktion auf die Menge an Kommentaren.

Dennoch ist die Wahl des Modells damit keine reine Kostenfrage, sondern eine Sicherheitsentscheidung. Unternehmen, die für automatisierte Reviews aus Budgetgründen auf ein günstigeres Modell setzen, akzeptieren damit implizit eine höhere Bypass-Rate gegenüber genau der Angriffstechnik, welche die Prüfung eigentlich abwehren soll. Diese Entscheidung wird in der Praxis allerdings selten bewusst getroffen, da die Modellauswahl oft an anderer Stelle fällt: etwa nach Latenz oder Preis pro Anfrage, ohne dass die Sicherheitsimplikation überhaupt Teil der Abwägung ist.

Blinde Flecken und Fehlalarme

Ein zweiter, weniger offensichtlicher Effekt betrifft die Sprache der eingebetteten Kommentare: Modelle bewerten identischen Code nämlich offenbar unterschiedlich, je nachdem, in welcher Sprache er verfasst ist. Ein Modell stufte russische Kommentare deutlich häufiger als Hinweis auf Social-Engineering ein und hob die Erkennung um 14 %-Punkte an, andere reagierten ähnlich empfindlich auf chinesische oder arabische Kommentare, während Kommentare in selteneren Sprachen wie Estnisch die Erkennungsrate eher senkten.

Für die Praxis ist dieser Effekt in beide Richtungen problematisch: Einerseits lässt sich diese sprachabhängige Vertrauensverteilung gezielt ausnutzen, indem man Schadcode in einer Sprache kommentiert, der ein Modell stärker vertraut. Andererseits – und das trifft den Regelbetrieb häufiger – erzeugen internationale Codebasen und Open-Source-Abhängigkeiten mit fremdsprachigen Kommentaren aber auch Fehlalarme bei vollkommen legitimen Code. Eine Prüfinstanz, die je nach Kommentarsprache unterschiedlich urteilt, ist schwer kalibrierbar und untergräbt bei zu vielen Fehlalarmen die Akzeptanz der Entwicklerteams, die mit ihr arbeiten sollen.

Volumen schlägt Sprache

Der Effekt, der die anderen überlagert, hat mit Sprache jedoch nichts zu tun, sondern allein mit der Dateigröße: Unabhängig davon, ob überhaupt Täuschungsversuche enthalten sind, fällt die Erkennungsrate von nahezu 100 % bei Dateien unter 500 Kilobyte auf 12–18 % bei Dateien über 3 Megabyte. Große, legitim wirkende Programmbibliotheken, etwa vollständig SDK-Bundles, wirken dabei wie eine strukturelle Tarnung, in der wenige Zeilen Schadcode schlicht verschwinden.

Naheliegend wäre die Erklärung, der Code passe nicht mehr in das Kontextfenster des Modells. Sie greift jedoch zu kurz, da der Effekt auch dann auftritt, wenn der gesamte Code technisch verarbeitet wird – in den Tests bis zu 2,8 Megabyte. Das Problem liegt also nicht an der Kapazität, sondern an der Aufmerksamkeit: Wenige kritische Zeilen gehen in der Masse gutartigen Bibliothekscodes unter, selbst wenn das Modell sie theoretisch sehen könnte. Die Fähigkeit von KI-Modellen, große Kontextmengen aufzunehmen, garantiert also nicht, dass jede Stelle darin auch die nötige Gewichtung erhält!

Für Angreifer verändert das die Aufgabe grundlegend: Sie müssen ein Modell nicht mehr von der Harmlosigkeit ihres Codes überzeugen, keine Anweisungen verstecken und keine Erkennungslogik überlisten. Es genügt, den schädlichen Anteil klein genug im Verhältnis zur Gesamtmenge zu halten.

Diese Strategie ist nicht nur wirksamer als sprachliche Täuschung, sondern auch deutlich einfacher umzusetzen: Schadcode in eine populäre, umfangreiche Bibliothek einzubetten, ist technisch trivial, während ein überzeugender Täuschungstext Aufwand und ein gewisses Gespür für das jeweilige Modell erfordert. Der Weg des geringsten Widerstands führt damit nicht über die Sprache, sondern über das Volumen.

Funktionale Warnung als Waffe

Darüber hinaus existiert noch eine dritte Möglichkeit, eine KI-Code-Prüfung zu unterlaufen – und die kommt ganz ohne Täuschung aus: Bei extremer Kommentarsättigung, ab etwa 1000 eingebetteten Lures, gaben selbst leistungsstarke Modelle im Test kein auswertbares Urteil mehr ab, sondern lieferten fehlerhaft formatierte Antworten oder verweigerten schlicht die Bewertung.

Für eine Pipeline, die auf ein strukturiertes, binäres Freigabesignal wartet, ist das ein eigenständiges Risiko: Denn damit müssen Cyberkriminelle das Modell gar nicht zu einer falschen Entscheidung bewegen, wenn sie es stattdessen daran hindern können, einfach gar eine Wahl zu treffen.

Wichtig ist daher, wie die Pipeline mit einem ausbleibenden Urteil umgeht: Wertet sie den Fehler als technisches Problem und lässt den Code passieren, wird aus der Störung ein Einfallstor. Viele Organisationen haben für diesen Fall keine Regel. Ob ein gescheiterter Modellaufruf als Sicherheitsereignis behandelt oder als Zeile im Log abgelegt wird, entscheidet dann im Zweifel die Standardkonfiguration, nicht eine bewusste Sicherheitsabwägung.

Kombiniertes Betriebsrisiko

Für Unternehmen entsteht ein Risiko weniger aus einem einzelnen dieser Effekte als aus ihrem Zusammenspiel im Regelbetrieb. Ein Sprachmodell als alleinige Prüfinstanz konzentriert die Entscheidung darüber, ob Code als sicher gilt, auf eine Komponente, deren Schwächen bekannt sind und deren Verhalten von Modellversion und Anbieter abhängig ist. Was gestern zuverlässig erkannt wurde, kann nach einem Modellwechsel anders ausfallen, ohne dass sich an der Pipeline selbst etwas geändert hätte.

Hinzu kommt, dass die kritischste Größe – die Codemenge – im Alltag niemandem ins Auge fällt: Große Abhängigkeiten sind in modernen Projekten die Norm, nicht die Ausnahme, und niemand bewertet ein umfangreiches SDK-Bundle als verdächtig. Genau diese Selbstverständlichkeit macht es zum idealen Versteck! Der Angriff nutzt dann keine Schwachstelle im klassischen Sinn, sondern eine Eigenschaft, die im Betrieb als völlig unauffällig gilt.

Prekär wird die Lage durch zwei Entscheidungen, die nur selten als Sicherheitsentscheidungen wahrgenommen werden: Die Modellauswahl fällt oft nach Latenz und Kosten, obwohl gerade die günstigeren Modelle anfälliger sind. Und der Umgang mit Fehlerfällen – etwa einem nicht auswertbaren oder verweigerten Urteil – ist häufig überhaupt nicht definiert, sodass eine gescheiterte Prüfung im Zweifel als technisches Rauschen durchgeht. In beiden Fällen wird an einer Stelle über Sicherheit entschieden, an der niemand eine Sicherheitsentscheidung vermutet.

Belastbare Review-Ansätze

Aus den Befunden lassen sich konkrete, umsetzbare Maßnahmen für den Aufbau verlässlicherer Prüfprozesse ableiten: Der wirksamste Hebel liegt dabei vor der eigentlichen Prüfung. Entfernt man Kommentare und Dokumentationstext oder kennzeichnet sie zumindest getrennt, nimmt das sprachlichen Lures jegliche Angriffsfläche, ohne die Analyse des funktionalen Codes zu berühren. Im Zuge dessen lassen sich Variablennamen auf neutrale Bezeichner reduzieren, damit ein vertrauenserweckender Name die Bewertung nicht in eine Richtung zieht, die das tatsächliche Verhalten nicht deckt.

Der wichtigste Schritt betrifft jedoch die Dateigröße: Es empfiehlt sich, Drittanbieter- und Bibliothekscode getrennt vom eigenen Code zu prüfen – nicht in einem Durchlauf. Das verhindert, dass wenige Zeilen Schadcode in der gesamten Codemenge untergehen.

Auf der Ebene der Prüfung selbst zahlt sich Präzision aus: Gezielte Fragen nach konkreten Angriffsmustern, etwa nach Phishing- oder Proxy-Verhalten, lieferten in den Tests deutlich verlässlichere Ergebnisse als die allgemeine Frage, ob Code „schädlich“ sei. Ein Sprachmodell sollte dabei zudem nie die einzige Instanz bleiben! Erst die Kombination mit statischer Analyse und einer Verhaltensprüfung in der Sandbox stellt die Redundanz her, die eine mehrschichtige Sicherheitsarchitektur ausmacht – die Entscheidung durch ein LLM allein hebt diese Redundanz wiederum auf.

Ein dritter Punkt betrifft den laufenden Betrieb: Ein nicht-auswertbares oder verweigertes Urteil ist kein technisches Rauschen, sondern ein eigenständiges Alarmsignal und muss im Monitoring sichtbar sein. Eine Pipeline, die einen gescheiterten Modellaufruf stillschweigend passieren lässt, eröffnet die bereits beschriebene Lücke. Darüber hinaus entscheidet die Modellauswahl über das Schutzlevel: Für sicherheitskritische Prüfschritte zählt die Widerstandsfähigkeit gegenüber Prompt-Injection mehr als Antwortzeit oder Preis pro Anfrage.

Fazit

Solange Prüfpipelines Code als Ganzes und ohne Vorverarbeitung bewerten, ist Masse der zuverlässigste Weg, eine automatisierte Prüfung zu unterlaufen. Sprachliche Manipulation bleibt ein Angriffsvektor am Rande – der Umfang einer Datei hingegen ist ein zuverlässiger und beliebig wiederholbarer Weg, eine Prüfung zu kompromittieren.

Unternehmen, die KI-gestützte Code-Reviews produktiv einsetzen, sollten ihre Prüfarchitektur entsprechend ausrichten: Vorverarbeitung, Aufteilung nach Codeherkunft, mehrschichtige Validierung und ein Monitoring, das auch stille Ausfälle erfasst.

Max Imbiel ist Field CISO DACH bei Cloudflare, Mitglied des Cyber Security Committee bei Digitalswitzerland und Co-Moderator des Cybersecurity-Podcast Breach-FM.

Literatur

_{[1] Cloudforce One, Adversarial deception: a study of indirect prompt code injection, Threat-Report, April 2026, www.cloudflare.com/en-gb/cloudforce-one/research/adversarial-deception-a-study-of-indirect-prompt-code-injection/}

_{[2] Open Worldwide Application Security Project (OWASP), Top 10 for Large Language Model (LLM) Applications, Whitepaper, Version 2026, August 2026, https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/}

_{[3] Open Worldwide Application Security Project (OWASP), OWASP Top 10 for Agentic Applications for 2026,Whitepaper, Dezember 2025, https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/}