Du hast dem Workspace vertraut, nicht den Servern

Ein Entwickler, der ein Repo klont, um ein Infrastrukturmodul auszuprobieren, betrachtet das nicht als Gewährung von Zugriff auf irgendetwas. Klonen ist inert: Es schreibt Dateien auf die Festplatte, und nichts läuft. Die Ermessensentscheidung kommt einen Schritt später, wenn du den Ordner in deinem Editor öffnest und der Assistent fragt, ob er ihm vertrauen soll. Diese Abfrage liest sich wie das vertraute „Vertraust du den Autoren der Dateien in diesem Ordner“-Gate, das jede IDE zeigt, und du klickst auf Ja, so wie du es schon tausendmal getan hast, denn die Alternative ist ein Assistent, der deinen Code nicht lesen kann. Dieses bestimmte Ja tat mehr, als nur den Assistenten lesen zu lassen. In Amazon Q startete es vor dem Fix außerdem alle Server, die das Repository in die .amazonq/mcp.json geschrieben hatte, und diese Server kamen in deiner Shell hoch, mit deiner aktiven Cloud-Sitzung bereits in ihrer Umgebung.

Wir haben dieselbe Form Anfang dieses Monats beschrieben, als der Miasma-Wurm Projektkonfiguration in 73 von Microsofts eigenen Repositorys pflanzte und die Payload beim Öffnen des Ordners feuerte. Bei dieser Geschichte ging es darum, dass eine vertrauenswürdige Quelle die Angriffsfläche war. Diese hier ist enger gefasst und unangenehmer: kein Wurm, kein kompromittierter Maintainer, nichts, worauf man zeigen könnte, außer dem Assistenten. Der Fehler lag darin, wie Amazon Q eine gewöhnliche Projektkonfigurationsdatei las und bei deinem einzigen Vertrauensklick entschied, langlebige Prozesse zu starten, die das Sensibelste auf deinem Laptop trugen.

Was CVE-2026-12957 tatsächlich tat.

Am 26. Juni 2026 veröffentlichte Wiz Research CVE-2026-12957, eine Schwachstelle hoher Schwere (CVSS 8.5) in den Language Servers for AWS, der Engine, die Amazon Q Developer in VS Code, JetBrains, Eclipse und Visual Studio antreibt. Wiz meldete sie Amazon am 20. April, Amazon lieferte am 12. Mai einen Fix aus, und die Details wurden am 26. Juni öffentlich. Es gibt keine Anzeichen, dass sie in freier Wildbahn ausgenutzt wurde. Die Mechanik, heruntergebrochen:

• Amazon Q liest .amazonq/mcp.json aus einem Workspace, den du öffnest: eine projektbezogene Datei, die Model-Context-Protocol-Server deklariert, die der Assistent nutzen soll.
• Beim Öffnen des Ordners startete Q die MCP-Server, die diese Datei deklarierte, ohne einen separaten Zustimmungsschritt für die Server selbst. Ein Repository, das du geklont hast, konnte dem Assistenten also eine Serverdefinition vorlegen und sie ausführen lassen.
• Die gestarteten Prozesse erbten die vollständige Umgebung des Entwicklers, in Wiz' Worten „AWS-Schlüssel, Cloud-CLI-Tokens, API-Geheimnisse und SSH-Agent-Sockets“. Ein MCP-Server ist nur ein Befehl, den Q startet, und dieser Befehl kam mit allem hoch, was deine eigene Shell hätte.
• Eine Serverdefinition kann auf jeden beliebigen Befehl zeigen, sodass die Datei auf das Ausführen beliebigen Codes beim Öffnen des Ordners hinausläuft: Er läuft als du, mit deinen bereits geladenen Cloud-Anmeldedaten, in dem Moment, in dem du dem Workspace vertraust.

Die Offenlegung trägt eine echte Meinungsverschiedenheit über Zustimmung in sich, und das ist der ganze Sinn dieses Beitrags. Amazons Position: „Der Nutzer muss dem Workspace vertrauen, wenn er dazu aufgefordert wird.“ Es gibt ein Gate, und du klickst dich hindurch. Wiz' Befund: Vor dem Fix gab es keinen separaten Zustimmungsschritt für die MCP-Server selbst. Beides trifft zu, und das Versagen lebt in der Lücke dazwischen. Eine grobe, vertraute Vertrauensentscheidung — dasselbe Ja/Nein, das du einem Ordner gibst, damit der Editor ihn indizieren kann — autorisierte eine viel größere Gewährung: das Starten von Hintergrundservern, die deine aktive Sitzung trugen. Du hast eine Frage über das Lesen von Dateien beantwortet. Amazon Q gab den Klick aus für das Ausführen von Servern als du.

Amazon hat es in Language Servers 1.69.0 behoben (Clients: VS Code 2.20+, JetBrains 4.3+, Eclipse 2.7.4+, Visual Studio 1.94.0.0+), die fehlende Zustimmung pro Server hinzugefügt und einen verwandten Symlink-Prüf-Bypass gepatcht, CVE-2026-12958. Aktualisiere Amazon Q. Schau dann über den Patch hinaus auf den Teil, den er stehen lässt: Das Öffnen eines Repositorys konnte deine aktive Cloud-Sitzung in einen Prozess legen, den das Repository ausgewählt hat.

Dasselbe Repo, geöffnet in Bromure Agentic Coding.

Bromure Agentic Coding führt deinen Coding-Agenten, Amazon Q inklusive, in einer Linux-VM pro Profil aus: eigener Kernel, eigenes Dateisystem, eigener Netzwerk-Stack, auf Apples Virtualization-Framework. Ein Profil ist ein zusammenhängender Arbeitsbereich: dieser Kunde, dieser Dienst, dieses Open-Source-Modul, das du zur Bewertung geklont hast. Du klonst das Repository in dieses Profil und öffnest es dort. Das verwundbare Verhalten reproduziert sich genau so, wie Wiz es beschrieben hat: Du klickst auf Diesem Workspace vertrauen, Q liest .amazonq/mcp.json und startet die Server, die die Datei deklariert. Der Start feuert, und Code nach Wahl des Repositorys läuft.

Er läuft im Gast. Der MCP-Server kommt innerhalb der VM hoch und erbt die Umgebung der VM, und die Umgebung der VM hält deine Cloud-Sitzung nicht. Bromure liefert den Gast mit Stubs aus: gefälschte Werte, die für aws, gcloud, az, kubectl, git und alles andere, das einen Authorization-Header oder ein AWS_ACCESS_KEY_ID liest, echt aussehen. Ein Proxy auf deinem Mac sitzt vor jeder Verbindung, die die Sandbox verlässt, erkennt den Stub und tauscht ihn auf der Leitung gegen das echte Geheimnis aus, während die Anfrage abgeht; die Sandbox, die den Schlüssel hielt geht den Mechanismus durch. Der echte AWS-Schlüssel, das echte Cloud-CLI-Token, das echte API-Geheimnis berühren nie eine Datei, eine Umgebungsvariable oder eine Speicherseite, die die VM lesen kann.

Gehen wir also die Vererbung des CVE durch diese Grenze. Der gestartete Server liest $AWS_ACCESS_KEY_ID und findet einen Stub. Er liest ~/.aws und findet ein Stub-Profil. Er durchsucht die Umgebung nach den Cloud-Tokens und den API-Geheimnissen und findet Platzhalter. Der Server läuft wie geschrieben bis zum Ende durch und erbt eine Box, die deine Schlüssel nie hielt. Was CVE-2026-12957 zu einem Anmeldedaten-Diebstahl-Bug machte, ist die Umgebungsvererbung beim Start, und Bromure bricht sie nicht. Es lässt die geerbte Umgebung wertlos zurück.

„Diesem Workspace vertrauen“ war die falsche Frage.

Dieses CVE ist mehr wert als eine Patch-Notiz, und zwar wegen der Zustimmungslücke, und die Lücke ist ein Granularitätsproblem. Die Vertrauensabfrage stellte eine einzige breite Frage, vertraust du diesem Ordner, und ein einziges Ja musste sowohl das harmlose abdecken, das du meintest (den Assistenten meinen Code lesen lassen), als auch das gefährliche, von dem du nicht wusstest, dass es daran hing (Hintergrundserver mit meiner Cloud-Sitzung starten). Das kannst du nicht gut beantworten. Niemand kann das, denn die Frage verschmilzt zwei Gewährungen, die nichts miteinander zu tun haben, und zeigt dir nur die unschuldige.

Bromure verlangt nicht von dir, in dieser Ermessensentscheidung besser zu werden. Es nimmt die Entscheidung aus dem Pfad. Der Vertrauensklick innerhalb eines Profils lässt den Assistenten weiterhin seine Arbeit tun, und er kann immer noch keinen Prozess starten, der deine echte Cloud-Sitzung hält, weil diese Sitzung nicht in der VM ist, um geerbt zu werden. Sie lebt auf dem Host, hinter dem Broker, erreichbar nur als gestubbte Anfrage, die der Proxy auf der Leitung ausfüllt und protokolliert. Die gefährliche Hälfte der Gewährung ist weg. Du hast sie nicht zurückgehalten; es gab dort nichts zu gewähren, weil die Grenze unterhalb des Agenten sitzt, wo die Vertrauensabfrage sie nicht verschieben kann.

Die andere gefährliche Hälfte ist ein gestarteter Server, der destruktiv wird statt nur neugierig, und der trifft auf Guardrails. Bromure liest die Operation, nicht nur die Verbindung: Ein aws s3 ls ist ein Lesevorgang, ein aws s3 rm ist ein Schreibvorgang; ein git fetch ist ein Lesevorgang, ein git push ist ein Schreibvorgang. Stelle die Cloud-Anmeldedaten eines Profils auf bei Schreibvorgang nachfragen, und in dem Moment, in dem der Code nach einem zustandsändernden Aufruf greift, etwa einem DELETE, einem Terminate* oder einem Force-Push, stoppt Bromure ihn auf der Leitung und blendet auf deinem Mac eine Abfrage ein, die das Verb, das Ziel und das Profil benennt. Lesevorgänge unterbrechen dich nie. Die Mutation ist es, die pausiert, genauso wie „der Agent hat die Produktionsdatenbank gelöscht“ aufhört, eine Postmortem zu sein und zu einem Dialogfeld wird, das du ablehnst.

Was die Trace zeigt.

Jedes Team stellt am Morgen, nachdem so etwas einschlägt, dieselbe Frage: Habe ich dieses Repo geöffnet, und was hat es ausgeführt? Auf einem normalen Laptop ist die ehrliche Antwort ein Achselzucken. Der MCP-Server, den Q startete, war ein Kindprozess in deiner Sitzung, und was auch immer er las und wohin auch immer er telefonierte, er tat es als du, ohne Aufzeichnung, die ihn von deiner eigenen Arbeit trennt.

Innerhalb von Bromure sitzt der Agent in einer VM, und jedes ausgehende Byte geht durch den Host-Proxy, sodass der Start und seine Aufrufe sichtbar bleiben, selbst wenn der Agent sie nicht sehen kann. Der Host zeichnet auf, wie der MCP-Server hochkommt, die Befehle, die er ausführte, die Anmeldedaten, die er den Broker auszufüllen bat, und jede Verbindung, die er versuchte, in dieselbe Sitzungs-Trace wie alles andere, was der Agent tat, geschrieben unterhalb des Agenten, wo der gestartete Code nicht hineingreifen kann, um sie zu bearbeiten. „Hat der Server dieses Repos mein Konto berührt“ hört auf, eine Vermutung zu sein, die du Wochen später aus CloudTrail rekonstruierst, und wird zu einer Zeile, die du liest: Der Broker reichte einen Stub heraus, die Anfrage hatte einen Namen, das Ziel wurde protokolliert. Für ein Unternehmen ist das der Unterschied zwischen wir haben Amazon Q gepatcht und wir können zeigen, was jedes Repo, das unsere Entwickler geöffnet haben, getan hat, und die Audit-Haltung ist genau die, auf die unsere Enterprise-Arbeit immer wieder zurückkommt.

Wo dich das nicht rettet.

Der nächste Workspace ist bereits irgendwo geklont.

Die Lehre aus dem Red-Hat-Scope war, dass der Herausgeber keine Verteidigung ist. Die Lehre aus den Microsoft-Repos war, dass es das Repository auch nicht ist, und dass das Öffnen eines Ordners genügt, um Code auszuführen. Amazon Q fügt die nächste Zeile hinzu: Die Vertrauensabfrage ist ebenfalls keine Verteidigung. Die Frage, die sie dir stellt, vertraust du diesem Ordner, ist nicht die Frage, deren Antwort zählt, nämlich sollte dieser Ordner Server starten dürfen, die meine Cloud-Sitzung tragen. Die zweite wurde dir nie gezeigt, und du hättest sie nicht gut beantworten können, wenn es so gewesen wäre.

Das behebst du nicht, indem du die Abfrage sorgfältiger liest, denn die Abfrage war die falsche Abfrage. Du behebst es, indem du die Dinge so anordnest, dass „welcher Workspace ist das“ aufhört, die Frage zu sein, an der deine Cloud-Schlüssel hängen; warum ein Coding-Agent keine Sandbox ist ist die längere Version dieses Arguments. Bromure Agentic Coding ist die Konfiguration, in der der Agent das Repo in einer VM pro Profil öffnet, die echten Anmeldedaten auf dem Host hinter einem Broker bleiben, jeder Schreibvorgang, den der Agent macht, eine Abfrage passieren muss, und jeder Server, den er startet, in eine Trace geschrieben wird, die er nicht bearbeiten kann. Das Schlimmste, was eine vergiftete mcp.json tun kann, ist, eine Box zu erben, die deine Schlüssel nie hielt. Es ist kostenlos, Open Source und ab heute verfügbar.