prompt injections.de
News · Lagebild 2026

Coding-Agenten und RAG: der wachsende Angriffsweg 2026

· Gökhan Köse

Indirekte Prompt Injection hat 2026 ihren Schwerpunkt verschoben: vom Chatbot, der eine Webseite zusammenfasst, hin zu Werkzeugen, die Code lesen, Repositories bearbeiten und Wissensdatenbanken abfragen. Palo Alto Networks Unit 42 dokumentierte am 3. März 2026 zwölf Fälle web-basierter indirekter Prompt Injection in freier Wildbahn und 22 unterschiedliche Techniken zum Bau der Nutzlast — Angriffe, die nicht mehr im Labor stattfinden.1 Die Cloud Security Alliance berichtet in einer Forschungsnotiz vom 26. April 2026 unter Berufung auf Google-Telemetrie über einen relativen Anstieg schädlicher Injektions-Inhalte um 32 Prozent zwischen November 2025 und Februar 2026.2

Schaubild: Ein Agent mit Zugriff auf Browser, Mail, Kalender, Dateisystem, Shell und Code-Ausführung — jedes Werkzeug ein möglicher Angriffspfad.

Der Fall, der die Klasse definiert

Am 16. April 2026 veröffentlichten Aonan Guan sowie Zhengyu Liu und Gavin Zhong (Johns Hopkins University) eine Angriffskette, die gleich drei verbreitete Entwicklungs-Agenten betraf: Anthropics Claude Code Security Review, Googles Gemini CLI Action und den GitHub Copilot Agent. Die Anweisung stand in Feldern, die jeder Außenstehende bei einem öffentlichen Projekt füllen kann — Titel eines Pull Requests, Text eines Issues, HTML-Kommentar. Verarbeitete der Agent diese Inhalte im Rahmen seines automatisierten Laufs, gaben die Werkzeuge eigene Zugangsdaten preis: API-Schlüssel, Tokens und Umgebungsvariablen landeten in öffentlich sichtbaren Kommentaren beziehungsweise in den Protokollen der Build-Umgebung.3

Die Reaktionen der Hersteller unterscheiden sich deutlich. Anthropic stufte den Befund als kritisch ein und deaktivierte ein einzelnes Werkzeug; Google ergänzte Schutzanweisungen; GitHub verbuchte den Fall als bekannte architektonische Einschränkung.3 Für Betreiber ist das die eigentliche Nachricht: Die Klasse gilt bei den Herstellern nicht durchgängig als behebbarer Fehler. → Angriffsvektor Agenten · Werkzeuge, Function Calling und MCP

Das Repository als Eintrittspunkt

Mozillas Zero Day Investigative Network (0DIN) beschrieb am 25. Juni 2026 eine Kette, die ohne versteckten Text auskommt. Ein normal aussehendes Projekt enthält eine Installationsanleitung; ein Paket schlägt beim Start absichtlich mit einer hilfreich formulierten Fehlermeldung fehl; der Agent folgt dem naheliegenden Reparaturvorschlag und führt ein Setup-Skript aus, das seinen eigentlichen Befehl erst zur Laufzeit über einen DNS-Eintrag nachlädt. Im Test gegen Claude Code endete das in einer interaktiven Shell mit den Rechten der Entwicklerin oder des Entwicklers, samt Zugriff auf Umgebungsvariablen mit Schlüsseln.4

Der schädliche Teil steht dabei zu keinem Zeitpunkt im Repository — statische Analyse und Code-Review sehen ihn nicht. 0DIN empfiehlt, dass Agenten offenlegen, was ein Befehl tatsächlich ausführt, einschließlich der Inhalte nachgeladener Skripte, statt nur die Befehlszeile zu bewerten.4

Die Werkzeugbeschreibung als Kanal

Eine empirische Untersuchung vom 23. März 2026 prüfte sieben verbreitete MCP-Clients — Claude Desktop, Claude Code, Cursor, Cline, Continue, Gemini CLI und Langflow — auf Schutzmechanismen gegen Tool-Poisoning: statische Prüfung, Sichtbarkeit von Parametern, Erkennung von Injektionen, Warnungen, Sandboxing und Protokollierung. Das Ergebnis fiel uneinheitlich aus: Manche Clients bringen belastbare Schutzmechanismen mit, andere zeigen sich anfällig für Cross-Tool-Poisoning, versteckte Parameter und nicht autorisierte Werkzeugaufrufe.5 → Tool-Poisoning (MCP) · Vorfall: MCP-Tool-Poisoning

Warum RAG derselbe Weg ist

In einem RAG-System entscheidet nicht der Nutzer, welcher Fremdtext in den Kontext gelangt, sondern der Retriever. Präparierte Dokumente lassen sich gezielt auf die Nähe zu erwarteten Fragen optimieren, damit sie zuverlässig in den Treffern landen. Die technische Lage ist dieselbe wie beim Coding-Agenten: abgerufener Text steht neben der Systemanweisung, und das Modell kann beides nicht sicher trennen. → RAG-Vergiftung · RAG absichern

Was jetzt trägt

Die Empfehlungen der genannten Quellen decken sich in vier Punkten:245

  • Rechte der Agenten inventarisieren und beschneiden — zuerst dort, wo Zahlungen, Code-Ausführung oder Löschvorgänge möglich sind. Tokens in Build-Umgebungen gehören auf den kleinsten funktionierenden Umfang.
  • Menschliche Freigabe, bevor ein Agent committet, einen Pull Request öffnet oder Inhalte veröffentlicht, die er aus Fremddaten übernommen hat.
  • Fremdinhalte bereinigen: unsichtbarer Text, Kommentare und Nullbreiten-Zeichen raus, bevor der Text ins Kontextfenster gelangt.
  • Ausgangskanäle einschränken, etwa das Rendern von Bildern nur für freigegebene Domains.

Keine dieser Maßnahmen verhindert die Injektion. Sie begrenzen, was danach passiert — und genau das ist nach heutigem Stand die verfügbare Sicherheit. → Agenten absichern · Tödliche Trias

Quellen

  1. Unit 42, Palo Alto Networks: Fooling AI Agents: Web-Based Indirect Prompt Injection Observed in the Wild, 03.03.2026. https://unit42.paloaltonetworks.com/ai-agent-prompt-injection/ ↩
  2. Cloud Security Alliance: Indirect Prompt Injection Goes Operational, Forschungsnotiz, 26.04.2026. https://labs.cloudsecurityalliance.org/research/csa-research-note-indirect-prompt-injection-in-the-wild-2026/ ↩
  3. SecurityWeek: Claude Code, Gemini CLI, GitHub Copilot Agents Vulnerable to Prompt Injection via Comments, 16.04.2026. https://www.securityweek.com/claude-code-gemini-cli-github-copilot-agents-vulnerable-to-prompt-injection-via-comments/ ↩
  4. 0DIN (Mozilla Zero Day Investigative Network), Hall, Engelbrecht: Clone This Repo and I Own Your Machine, 25.06.2026. https://0din.ai/blog/clone-this-repo-and-i-own-your-machine ↩
  5. Huang, Huang, Milani Fard: Are AI-assisted Development Tools Immune to Prompt Injection?, arXiv:2603.21642, 23.03.2026. https://arxiv.org/abs/2603.21642 ↩

Im Zusammenhang