Amazon Kiro: Prompt-Injection-Lücke ermöglichte Datenexfiltration über Kiro Powers
Amazon Kiro, eine KI-gestützte agentische IDE, war bis Version 0.8.140 anfällig für Datenexfiltration per Prompt Injection über die Funktion Kiro Powers. Ein bösartiges Projekt genügte, um sensible lokale Daten unbemerkt nach außen zu senden. Der Fall zeigt ein grundsätzliches Trust-Boundary-Problem agentischer Coding-Tools.
Wer in seinem Unternehmen KI-gestützte Coding-Tools wie Amazon Kiro einsetzt, sollte den aktuellen Fall genau lesen: Sicherheitsforscher von Mindgard haben in der agentischen IDE Kiro eine Schwachstelle offengelegt, die es erlaubte, sensible lokale Daten unbemerkt aus einem Entwicklerrechner herauszuschleusen. Betroffen war Kiro in Version 0.7.45 unter Windows. Der Hersteller hat die Lücke inzwischen mit Version 0.8.140 geschlossen, aktuell ist Kiro bei Version 1.0.337 angelangt. Ein CVE-Identifier wurde für den Vorfall nicht vergeben.
Der Angriffsweg ist ungewöhnlich niedrigschwellig: Öffnet ein Nutzer ein präpariertes Projekt über den Menüpfad File > Open Workspace From File (nicht das einfache Öffnen eines Ordners) und schickt danach irgendeine, völlig harmlose Nachricht an den Kiro-Agenten, reicht das bereits aus. Eine explizite bösartige Eingabe durch den Nutzer ist nicht nötig. Gesichert ist, dass die Lücke gepatcht wurde und die Angriffsschwierigkeit von den Forschern als niedrig eingestuft wird. Unbestätigt beziehungsweise nicht öffentlich dokumentiert ist, ob die Schwachstelle vor der Offenlegung bereits aktiv ausgenutzt wurde. Dringend ist vor allem eines: das grundsätzliche Trust-Boundary-Problem, das dem Fall zugrunde liegt, betrifft nicht nur Kiro, sondern agentische Coding-Tools insgesamt.
Was ist Amazon Kiro und Kiro Powers
Amazon Kiro ist eine KI-gestützte agentische Entwicklungsumgebung (IDE), in der ein KI-Agent nicht nur Code vorschlägt, sondern eigenständig Aktionen im Projekt und auf dem System ausführt. Zentraler Baustein ist die Funktion Kiro Powers. Sie bündelt mehrere Komponenten, die dem Agenten Kontext und Handlungsfähigkeit geben:
- MCP-Server-Konfigurationen, über die der Agent externe Werkzeuge und Dienste anspricht
- Steering-Dateien, insbesondere die Datei POWER.md, die als eine Art Onboarding-Handbuch für den Agenten dient
- Hooks, die bestimmte Aktionen automatisch auslösen
- Kontextwissen, das der Agent projektübergreifend nutzt
Genau diese Bündelung aus Konfiguration, Anleitung und Automatisierung macht Kiro Powers laut den Forschern zu einem attraktiven Angriffsziel: Wer Inhalte in diese Struktur einschleusen kann, beeinflusst direkt das Verhalten des Agenten.
So funktioniert der Angriff
Der von Mindgard beschriebene Report, verfasst von Fergal Glynn, zeigt eine Kette aus mehreren Schritten, die am Ende zur Exfiltration von Daten führt:
- Der Nutzer öffnet ein bösartig präpariertes Projekt über File > Open Workspace From File
- Der Nutzer sendet eine beliebige Nachricht an den Kiro-Agenten, ohne selbst eine schädliche Eingabe zu formulieren
- Der Agent interpretiert Inhalte aus dem Repository, etwa in Dateinamen oder in Steering-Dateien wie POWER.md, nicht als reinen Kontext, sondern als Instruktion
- Der Agent liest daraufhin sensible lokale Daten aus
- Diese Daten werden vom Agenten in eine sicherheitsrelevante IDE-Konfigurationsdatei geschrieben
- Eine nachgelagerte IDE-Funktion greift auf diese Konfigurationsdatei zu und sendet die Daten per Netzwerkzugriff nach außen
Bemerkenswert ist, dass sich dieses Verhalten laut Mindgard sowohl in als vertrauenswürdig eingestuften als auch in nicht vertrauenswürdigen Workspaces reproduzieren ließ. Kiro unterschied also nicht zuverlässig danach, ob ein Projekt grundsätzlich als sicher markiert war.
Warum das ein strukturelles Problem ist
Der eigentliche Kern des Falls liegt nicht in einem einzelnen Programmierfehler, sondern in einer Designfrage, die viele agentische Coding-Tools derzeit teilen: Repository-Inhalte werden vom KI-Agenten gleichzeitig als Kontext und als potenzielle Instruktion behandelt. Eine Datei, ein Dateiname oder ein Kommentar, den ein Mensch als reine Information lesen würde, kann vom Agenten als Befehl interpretiert werden. Diese fehlende Trennung zwischen Daten und Steuerbefehlen ist ein klassisches Muster von Prompt-Injection-Schwachstellen, hier jedoch übertragen auf die Ebene von Entwicklungswerkzeugen mit weitreichenden lokalen Rechten.
Der Kiro-Fall reiht sich damit in eine wachsende Serie von Sicherheitsproblemen bei agentischen Coding-Tools ein. Je mehr Autonomie ein Agent im Namen des Entwicklers erhält, etwa Dateizugriff, Netzwerkzugriff oder das Ausführen von Kommandos, desto größer wird die Angriffsfläche, wenn Eingaben aus fremden Quellen nicht sauber von vertrauenswürdigen Anweisungen getrennt werden.
Versionsübersicht
| Status | Version | Plattform |
|---|---|---|
| Verwundbar | 0.7.45 | Windows |
| Fix ausgeliefert | 0.8.140 | Windows |
| Aktuelle Version zum Meldezeitpunkt | 1.0.337 | — |
Was Admins jetzt prüfen sollten
Auch wenn der konkrete Fehler bereits behoben ist, ergeben sich aus dem Vorfall mehrere konkrete Prüfpunkte für Unternehmen, die Kiro oder vergleichbare agentische IDEs einsetzen:
- Prüfen, ob im Unternehmen Kiro-Installationen mit einer Version älter als 0.8.140 im Einsatz sind, und diese zeitnah aktualisieren
- Aktuell eingesetzte Version regelmäßig gegen den jeweils neuesten Stand prüfen, da Kiro sich schnell weiterentwickelt
- Interne Richtlinie festlegen, dass Projekte nur über den regulären Ordner-Import geöffnet werden, sofern die Herkunft nicht zweifelsfrei geklärt ist
- Besondere Vorsicht beim Öffnen von Projekten über Workspace-Dateien aus externen Quellen, etwa aus geteilten Repositories oder Anhängen
- Steering-Dateien wie POWER.md sowie MCP-Server-Konfigurationen in fremden oder neu geklonten Projekten vor der ersten Nutzung durch den Agenten manuell sichten
- Netzwerkzugriffe, die von der IDE beziehungsweise dem KI-Agenten ausgehen, im Unternehmensnetzwerk beobachten und ungewöhnliche Verbindungen untersuchen
- Grundsätzlich klären, welche lokalen Daten und Zugänge ein KI-Agent im jeweiligen Tool überhaupt einsehen kann, und diesen Zugriff so weit wie möglich einschränken
- Mitarbeitende für das Grundmuster sensibilisieren, dass scheinbar harmloser Repository-Inhalt von einem Agenten als Befehl gelesen werden kann
Einordnung für Entwicklerteams
Für Entwicklerteams bedeutet dieser Fall vor allem, dass die Auswahl und Nutzung agentischer Coding-Tools nicht losgelöst von klassischen Sicherheitsüberlegungen betrachtet werden sollte. Ähnlich wie bei bösartigen Erweiterungen für klassische Editoren wird auch hier ein Entwicklerwerkzeug selbst zum Angriffsvektor, nur dass die Automatisierung durch den KI-Agenten die möglichen Auswirkungen vergrößert. Wer Kiro oder vergleichbare Tools produktiv einsetzt, sollte den Umgang mit fremden Projekten, Workspace-Dateien und automatisierten Agentenaktionen als festen Bestandteil der eigenen Sicherheitsrichtlinien behandeln, nicht als Randthema.
Passende Anleitungen auf S-EDV
- Bösartige VS-Code-Erweiterung: API- und SSH-Schlüssel prüfen
- KI-Agenten mit Konfliktzielen: Studie zu selbstreplizierender Malware
