Der Freigabedialog erschien, er nannte die URL des Angreifers, und er zeigte die Daten, die dorthin unterwegs waren. Er kam an, nachdem der Schreibvorgang, um den er bat, längst auf der Platte gelandet war.

Sie klonen ein Repository, das Ihnen jemand geschickt hat, und setzen den Agenten darauf an. Eine Karte schiebt sich herein: Der Agent will eine Einstellung ändern, hier ist die Zeile, die er eingefügt hat, hier ist die URL. Sie nehmen sich vor, sie zu lesen. Zuerst klicken Sie aber ins Plugin-Panel, aus Neugier, was dieses Projekt so hereinzieht, und dieser Klick vollendet den Angriff.

Am 11. September veröffentlichte AWS das Security Bulletin 2026-111-AWS zu CVE-2026-89332 in Kiro, seiner agentischen IDE. Der CVE-Eintrag beschreibt sie in der flachen Sprache des Katalogs:

Die Einbindung von Funktionalität aus einer nicht vertrauenswürdigen Kontrollsphäre in die Kiro-Powers-Funktion der Amazon Kiro IDE vor Version 0.8.135 kann entfernten, nicht authentifizierten Akteuren erlauben, sensible Informationen von einer Entwickler-Workstation zu erlangen.

Der Eintrag bewertet sie mit 5,5 nach CVSS 3.1, AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N: hohe Auswirkung auf die Vertraulichkeit, keine auf Integrität oder Verfügbarkeit. Kiro 0.8.135 behebt das Problem, und AWS nennt keinen Workaround.

Powers, und die Datei, die sagt, woher sie kommen

Powers sind Kiros Plugin-Format: ein Bündel aus MCP-Tools, Skills und Referenzwissen in einem installierbaren Paket. MCP ist das Model Context Protocol, der Stecker, über den ein Coding-Agent externe Tools aufrufen und deren Ergebnisse lesen kann. Sie durchstöbern Powers über eine Registry innerhalb der IDE und klicken auf Installieren, genau wie Sie Erweiterungen durchstöbern würden.

Eine Einstellung benennt die Registry, die die IDE durchstöbert, und in einem nicht vertrauenswürdigen Workspace konnte der Kiro-Agent die Workspace-Einstellungsdatei schreiben. Ein präpariertes Repository nutzt das, um die URL der Powers-Registry auf einen Endpunkt zu richten, den der Angreifer betreibt. Kiro ruft diese URL ab, sobald Sie das Powers-Panel öffnen, und die Anfrage nimmt Workspace-Daten mit: in einem echten Projekt alles, was neben dem Code liegt, etwa der Inhalt von .env, Cloud-Zugriffsschlüssel, API-Tokens und Datenbank-URLs.

Kiro war schon einmal an dieser Stelle. Im Juli schrieb eine vergiftete Dokumentationsseite die Konfiguration um, die Kiros MCP-Server startet, ganz ohne Freigabeabfrage. AWS fügte die Abfrage hinzu, und das September-Bulletin hält fest, wie sich diese Abfrage verhielt.

Erst schreiben, dann fragen

Die Schilderung des Ablaufs im Bulletin ist der Teil, den man behalten sollte:

Kiro legte dem Nutzer die Änderung zur Freigabe vor und zeigte die eingefügten Daten und die URL, aber die Datei war bereits auf die Platte geschrieben, und wer das Powers-Panel öffnete, bevor er auf die Abfrage antwortete, löste die Anfrage trotzdem aus.

Der Dialog tat seine Arbeit als Dialog. Er zeigte die eingefügten Daten und die Ziel-URL, also alles, was ein Prüfer braucht, um die Änderung zu beurteilen. Die Datei lag auf der Platte, während die Frage noch offen war, also schilderte die Frage ein Ereignis, statt es zu steuern. Zwischen dem Schreibvorgang und Ihrer Antwort liegt ein Fenster, und darin bestimmt die Einstellung, was Kiro abruft. Ein Panel-Klick in diesem Fenster ist der ganze Angriff.

CVE-2026-89332 als Zeitachse, von links nach rechts, alles auf dem Rechner des Entwicklers. Das präparierte Repository bringt den Agenten dazu, die Workspace-Einstellungsdatei zu schreiben und die URL der Kiro-Powers-Registry auf einen Angreifer-Endpunkt umzubiegen. Die Einstellungsdatei landet auf der Platte, und erst danach erscheint die Freigabekarte und zeigt, wie sie soll, die eingefügte Zeile und die URL. Während die Karte auf eine Antwort wartet, ist die Einstellung bereits in Kraft: Wer das Powers-Panel öffnet, lässt Kiro die konfigurierte Registry abrufen, und Workspace-Daten verlassen mit der Anfrage den Rechner. Was der Entwickler danach auch klickt, es ist nichts mehr zurückzuhalten.

Eine Abfrage, gegen die man ein Rennen verlieren kann

Eine Freigabeabfrage steuert ein Ergebnis nur dann, wenn das Ergebnis auf Ihre Antwort wartet. Vollzieht man die Wirkung zuerst, wird aus der Abfrage eine Benachrichtigung mit Knöpfen daran, und wie gut sie Sie schützt, hängt davon ab, wie schnell Sie lesen und was Sie beim Lesen anklicken. Kiro schrieb zuerst und fragte danach, und genau diese Reihenfolge lässt eine agentische IDE flott wirken. Jedes Werkzeug, das einem Agenten ein Datei-Schreibwerkzeug in die Hand gibt und darüber eine Zustimmungsschicht schraubt, steht vor demselben Handel, und die Hersteller werden ihn weiter eingehen.

Der Versionssprung schließt diesen einen Fall. Was bleibt, ist, wo die Einstellung lebt und was sie erreichen kann, sobald sie sich ändert.

Wo dieser Schreibvorgang in einem Bromure-Workspace landet

Bromure Agentic Coding führt Coding-Agenten in einer hardwarevirtualisierten Linux-VM auf Ihrem Mac aus, mit den Sicherheitskontrollen auf der Host-Seite dieser Grenze. Dem Angriff bleiben vier Züge, sobald er einen Workspace erreicht, und auf jeden davon antwortet ein anderer Teil des Produkts.

Die Tool-Registry ist keine Datei, die der Gast schreiben kann. In Bromure definieren Sie MCP-Server einmal, im MCP-Bereich der App, auf dem Host. Die App übersetzt jede Definition in das native Konfigurationsformat des jeweils laufenden Agenten, ~/.claude.json für Claude Code, einen TOML-Block in ~/.codex/config.toml für Codex, die Benutzereinstellungsdatei für Grok Build, und injiziert sie beim Start in die VM. Das Handbuch nennt die Konsequenz: Einen Server hinzuzufügen, zu bearbeiten oder zu entfernen wirkt sich beim nächsten Start der Workspace-Sitzung aus, nicht live in einer laufenden Sitzung. Ein Agent, der die Tool-Konfiguration innerhalb der VM umschreibt, hat eine Kopie bearbeitet, auf einem Rechner, der nicht Ihrer ist, und diese Kopie wird erst bei einem Sitzungsstart zu einem lebenden Tool, der stattdessen die Definition des Hosts liest. Es öffnet sich kein Fenster, weil Änderung und Wirkung an verschiedenen Orten sitzen. Bei HTTP-MCP-Servern bleibt auch das Token host-seitig, unter einem Zugangsdatenfeld mit der Beschriftung never sent to VM, swapped by proxy.

Der Schreibvorgang landet in einer VM. Jeder Workspace besitzt seine eigene persistente Linux-VM mit eigenem Kernel, eigener Platte, eigener MAC-Adresse und eigenem Netzwerk-Namespace. Ein außer Kontrolle geratener Agentenprozess kann diese VM zerlegen und nur diese VM; Ihr Mac, Ihre anderen Workspaces und Ihre echten Dateien bleiben unberührt, abgesehen von den Ordnern, die Sie absichtlich freigegeben haben. Das präparierte Repository darf eine Einstellungsdatei auf einem Rechner ändern, der dazu da ist, geändert und notfalls gelöscht zu werden.

Die Anfrage muss nach draußen. Die Vite-Scanning-Geschichte von gestern hatte keinen ausgehenden Abschnitt zu blockieren. Diese hier hat einen: Die Exfiltration ist eine gewöhnliche Anfrage an einen Host nach Wahl des Angreifers, und genau dafür ist eine Egress-Firewall pro Workspace da. Guardrails legt ein geordnetes Regelwerk im pf-Stil über jede Verbindung, die die VM öffnet, nach Host, IP oder CIDR, Protokoll, Port und bis hinunter zu einzelnen HTTP-Verben im Web-Verkehr, sodass ein Workspace eine API lesen kann, in die er nicht schreiben darf. Bromure erzwingt das am virtuellen Switch und noch einmal im Proxy, wobei die Port-80- und Port-443-Ströme des Gasts in den Proxy umgeleitet werden, damit sich nichts innerhalb der VM der Inspektion entzieht. Regeländerungen erreichen laufende Sitzungen sofort. Ein Workspace, dessen Regeln Ihre Registry, Ihre Forge und Ihren Modellanbieter nennen, trägt keine Zeile, die attacker.example sagt.

Die Anfrage hätte Platzhalter getragen. Die Formulierung des Bulletins lautet „sensible Informationen von einer Entwickler-Workstation“, und in einem Bromure-Workspace sind diese Informationen Attrappen. Bromure ersetzt jedes Zugangsdatum, das Sie konfigurieren, innerhalb der VM durch eine strukturerhaltende Fälschung, abgeleitet aus dem echten Wert plus einem 32-Byte-Salt je Installation über HKDF-SHA256, und behält dabei die Form, die clientseitige Validierer erwarten: sk-ant-api03-brm-… für Anthropic, ghp_ plus 36 Zeichen für GitHub, glpat- plus 20 für GitLab, brm-k8s-… für Kubernetes, brm-db-… für ein Datenbankgeheimnis. Diese Fälschungen gehen in die Umgebungsvariablen und in ~/.git-credentials, ~/.docker/config.json, ~/.kube/config, ~/.aws/config und die MCP-Konfigurationen. Die echten Werte bleiben verschlüsselt auf dem Mac, und der Host-Proxy tauscht jeden einzelnen im letzten Moment auf die Leitung, begrenzt auf den Ziel-Host, zu dem er gehört.

Dasselbe präparierte Repository, auf zwei Rechnern geöffnet. Auf einer Entwickler-Workstation landet der Schreibvorgang auf dem echten Dateisystem, die Freigabekarte liefert sich ein Rennen mit dem Powers-Panel, die Anfrage geht an den Endpunkt des Angreifers und nimmt mit, was das Projekt hergibt, und die Behebung besteht darin, jedes erreichbare Zugangsdatum zu rotieren. In einem Bromure-Agentic-Coding-Workspace landet der Schreibvorgang auf einer VM-Platte, während der Host die maßgeblichen Tool-Definitionen hält und sie nur beim Start injiziert, die ausgehende Anfrage trifft am virtuellen Switch und noch einmal im Proxy auf die Egress-Regeln des Workspace, was dennoch hinausgeht, trägt strukturerhaltende Platzhalter, und ein Platzhalter, der an einen Host adressiert ist, für den er nicht geprägt wurde, wird mit HTTP 451 abgewiesen, während die VM auf der Stelle pausiert wird.

Der Stolperdraht, der an der Anfrage selbst auslöst

Die Platzhalter erledigen eine zweite Aufgabe. Jede Fälschung hat genau eine legitime Zielfamilie, den Host-Geltungsbereich, für den sie geprägt wurde, und eine Fälschung in einer Anfrage, die irgendwo anders hingeht, heißt deshalb, dass etwas innerhalb der VM ein Zugangsdatum vom Rechner fortschickt. Der Proxy scannt jede ausgehende Anfrage, Header und Body, mit einem Aho-Corasick-Automaten, billig genug, um auf allen zu laufen.

Bei einem Treffer weist der Proxy die Anfrage mit HTTP 451 ab und leitet kein einziges Byte weiter, dann pausiert er die VM. Eine Warnung bietet Shut down, Save for Investigation, was zuvor Platte, Home- und geteilte Ordner für die Forensik exportiert, oder Continue auf eigenes Risiko. Die Erkennung landet als rote Credential brokering-Zeile in der Security Timeline, und Bromure markiert den Workspace als kompromittiert, sodass Ihr nächster Start anbietet, die VM-Platte und den persistenten Home-Ordner zu löschen und dabei Ihre Tokens, Schlüssel und Einstellungen zu behalten. Sie schalten nichts ein. Der Detektor läuft standardmäßig.

Kiros Freigabekarte stellte eine Frage zu einer Datei, die sich bereits geändert hatte. Der Kompromittierungsdetektor fragt gar nichts: Er stoppt die Anfrage im Flug, friert den Rechner ein, der sie gesendet hat, und sagt es Ihnen danach. Bromures eigene Zustimmungsabfragen arbeiten in dieser Richtung. Im Ask-Modus hält der Prompt-Injection-Scanner die ausgehende Anfrage an, bevor auch nur ein Byte den Modell-Host erreicht, die Schreibdialoge von Guardrails halten den API-Aufruf auf, statt ihn zu melden, und wenn Sie einen Workspace aus der Ferne steuern, werden diese Abfragen auf dem Host gezeichnet, wo ein kompromittierter Gast sie weder sehen noch fälschen kann, und ein Timeout oder ein Wegklicken gilt als Ablehnung.

Nichts rotieren

Die Behebung von AWS läuft in zwei Schritten. Auf 0.8.135 aktualisieren, dann die Zugangsdaten rotieren, die in jedem Projekt vorhanden waren, das Sie mit einer älteren Version geöffnet haben. Der zweite Schritt kostet mehr als der erste, und er kostet auf eine besondere Weise: Sie können ihn nicht eingrenzen. Sie wissen nicht, welche Repositories präpariert waren oder welche Panel-Klicks in welches Fenster fielen, also rotieren Sie, was in Reichweite war, und authentifizieren das Werkzeug neu, das davon abhing.

Die Dokumentation von Bromure Agentic Coding formuliert denselben Gedanken andersherum: Weil nur die Fälschung abgeflossen ist, muss das echte Zugangsdatum nie rotiert werden. Halten Sie die maßgebliche Tool-Registry auf dem Host, führen Sie das nicht vertrauenswürdige Repository auf einem Rechner aus, den Sie wegwerfen können, und füllen Sie dessen Home-Verzeichnis mit Platzhaltern. Ein Rennen, das Sie verlieren, kostet Sie dann ein VM-Image.

Installieren Sie Bromure Agentic Coding, und lassen Sie das nächste Repository versuchen, eine Einstellung umzuschreiben.