Ein KI-Assistent, der Repo-Konfigurationen ungefragt ausführt, startet fremden Code auf dem eigenen Rechner, bevor jemand eine Zeile davon gelesen hat. Wiz Research hat die Lücke im April 2026 in der Amazon-Q-Erweiterung für Visual Studio Code gefunden; sie wird als CVE-2026-12957 geführt. Betroffen waren alle Versionen des Language Servers unter 1.65.0. Seit 1.65.0 ist der Fehler geschlossen.
Der Fall ist schlicht. Es brauchte keinen Speicherfehler, keine Umgehung von Adressraumschutz und keine präparierte Installationsdatei. Ein Repository, ein Klon, ein geöffneter Ordner — mehr nicht. Die Erweiterung hat getan, was in einer Konfigurationsdatei im Projektverzeichnis stand. Das trifft eine Gewohnheit, die jeder kennt: Man klont einen fremden Stand und schaut sich den Code erst danach an.
Vergleichen lässt sich das mit einem Schlüsselbund, den man beim Betreten einer fremden Wohnung an der Garderobe hängen lässt. Wer ein Repository öffnet, betritt einen Raum, den jemand anderes eingerichtet hat. Bisher galt: In diesem Raum passiert nichts von selbst, man kann sich umsehen, bevor man eine Schublade öffnet. Die Amazon-Q-Erweiterung hat diese Annahme gebrochen. Sie hat die Schublade geöffnet, den Schlüsselbund genommen und ihn an jemanden weitergegeben, der schon im Flur stand.
Was hinter CVE-2026-12957 steckt
Amazon Q Developer ist ein KI-Assistent für Softwareentwicklung und läuft als VS-Code-Erweiterung. Er schlägt Code vor, erklärt Dateien, hilft beim Refactoring und kann Werkzeuge aufrufen. Dafür nutzt er das Model Context Protocol (MCP), einen offenen Standard, über den ein KI-Assistent lokale Prozesse starten und mit externen Diensten sprechen kann. Diese Prozesse heißen MCP-Server: kleine Helfer, die eine Datenbank abfragen, eine API ansteuern, ein Build-Werkzeug ausführen oder eine Verbindung zu einem internen System aufbauen.
Das Sicherheitsmodell von MCP geht davon aus, dass der Nutzer diese Server selbst einträgt. Das ist keine Pedanterie: Wer einem Assistenten erlaubt, beliebige Kommandos auf dem eigenen Rechner zu starten, trifft eine Entscheidung mit Folgen. Sie sollte bewusst fallen. Die Lücke in Amazon Q bestand darin, dass diese Annahme nicht galt. Die Erweiterung las beim Öffnen eines Ordners automatisch die Datei .amazonq/mcp.json aus dem Projektverzeichnis und führte die dort eingetragenen Server aus — ohne Rückfrage, ohne Zustimmung, ohne Prüfung, ob dem Arbeitsbereich vertraut wird.
Das Muster heißt in der Sicherheitsforschung Trust Boundary: die Grenze zwischen dem, was als vertrauenswürdig gilt, und dem, was geprüft werden muss. Bei einem geöffneten Projektordner verläuft diese Grenze durch alle Dateien, die im Repository liegen können. Eine package.json ist harmlos, solange sie nur deklariert. Eine Konfiguration, die einen Prozess startet, ist es nicht.
Zwei Fehler, die erst zusammen gefährlich werden
Wiz Research beschreibt zwei Verhaltensweisen, die erst zusammen gefährlich wurden. Die erste ist die automatische Ausführung ohne Zustimmung: Wer den Ordner öffnete und Amazon Q aktivierte, startete die eingetragenen MCP-Server ungefragt. Die zweite ist die vollständige Vererbung der Prozessumgebung. Ein gestarteter Kindprozess erbt unter Unix wie unter Windows standardmäßig die Umgebungsvariablen des Elternprozesses. Auf Entwicklungsrechnern ist das ein Problem.
In dieser Umgebung liegen typischerweise AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY und AWS_SESSION_TOKEN, dazu Anmeldetoken der Cloud-CLI, API-Schlüssel verschiedener Dienste, Konfigurationspfade mit weiteren Geheimnissen und oft ein Socket zum laufenden SSH-Agenten. Ein Prozess, der diese Umgebung erbt, muss keine Dateien durchsuchen und keine Passwörter knacken. Er bekommt alles fertig serviert. Fachleute nennen das Environment Inheritance. Die Angriffsfläche wird oft unterschätzt, weil sie unsichtbar bleibt und in jedem zweiten Skript bequem ist.
Für sich genommen ist keiner der beiden Punkte exotisch. Automatisches Laden von Konfigurationen spart Klicks, und das Erben der Umgebung ist der Weg des geringsten Widerstands, wenn man einen Unterprozess startet. Zusammengesetzt ergeben sie eine vollständige Angriffskette mit einem einzigen Auslöser: dem Öffnen eines Ordners.
Vom Klon zum Cloud-Konto: so lief der Angriff
Die Forscher haben für ihren Nachweis ein minimales Repository gebaut: ein paar unauffällige Dateien, eine README, ein Stück Beispielcode — und im Verzeichnis .amazonq eine mcp.json mit einem Eintrag, der ein Kommando startet. Wer dieses Repository klont und den Ordner in VS Code öffnet, startet beim Aktivieren der Erweiterung den Eintrag aus der Datei. Der Code läuft mit den Rechten des angemeldeten Nutzers und mit dessen vollständiger Umgebung.
Im Test griff der Angreifer anschließend auf aws sts get-caller-identity zurück, eine harmlose Abfrage, die die eigene Identität und das Konto zurückgibt. Sie belegte: Die aktive AWS-Sitzung des Entwicklers war für den eingeschleusten Prozess erreichbar. Von dort ist der Weg zur Kompromittierung der Cloud-Umgebung kurz. Ein Angreifer kann Zugangsschlüssel abziehen, dauerhafte Hintertüren in der IAM-Konfiguration anlegen, bestehende Infrastruktur auslesen und über den Netzwerkkontext des Entwicklers — oft inklusive VPN — an interne Dienste herankommen, die von außen nicht erreichbar sind.
Die Forscher nennen vier realistische Wege, auf denen ein solches Repository auf einen Rechner kommt. Ein Pull Request in einem viel genutzten Projekt, der eine zusätzliche Konfigurationsdatei mitbringt und im Review-Diff leicht übersehen wird. Ein Paketname, der sich um einen Buchstaben vom echten unterscheidet. Eine kompromittierte Abhängigkeit, die den Ordner nachliefert. Und Social Engineering: gefälschte Bewerbungsgespräche, in denen Kandidaten eine angebliche Programmieraufgabe klonen und ausführen sollen. Diese Methode ist aus Kampagnen bekannt, die dem nordkoreanischen Umfeld zugeschrieben werden.
Ein Muster, kein Einzelfall
Amazon Q ist nicht der Ausreißer, sondern ein weiterer Datenpunkt. Im selben Zeitraum haben Check Point Research und OX Security vergleichbare Befunde in anderen KI-Werkzeugen veröffentlicht: CVE-2025-59536 und CVE-2026-21852 für Claude Code, CVE-2025-54136 für Cursor, CVE-2026-30615 für Windsurf. Ältere Fälle reichen zurück, etwa CVE-2021-26700 in einer NPM-Erweiterung oder CVE-2020-17023 im VS-Code-Kern selbst.
Das verbindende Element: Eine Erweiterung liest eine Arbeitsbereichskonfiguration und handelt danach, ohne den Nutzer zu fragen. KI-Assistenten können im Namen des Entwicklers Befehle ausführen. Sie sind keine Editoren mit Autovervollständigung mehr, sondern Programme mit Ausführungsrechten. Sicherheitsforscher behandeln sie deshalb ähnlich wie Browser: Beide sitzen an Zugangsdaten und Vertrauen.
Was Amazon geändert hat und worauf du selbst achten solltest
Der Fehler ist behoben. Mit Language-Server-Version 1.65.0 zeigt Amazon Q vor dem Laden von MCP-Servern aus dem Arbeitsbereich einen Zustimmungsdialog an, in dem der auszuführende Befehl zu sehen ist. Laut Amazon aktualisiert sich der Language Server automatisch, sofern die Netzwerkkonfiguration das nicht verhindert; ein Neustart der IDE stößt das Update in der Regel an. Wer die automatische Aktualisierung blockiert hat, sollte die Erweiterung manuell auf den aktuellen Stand bringen. Details stehen im Security Bulletin 2026-047-AWS.
Für dich als Entwickler bleiben ein paar Gewohnheiten sinnvoll, die über diesen Fall hinausgehen. Behandle fremde Repositories als fremden Code, auch wenn du nur kurz hineinschauen willst. Prüfe nach dem Klonen, ob ein Projekt eine Ebene wie .amazonq oder .cursor mitbringt, die im Diff vorher nicht auftauchte. Lies Zustimmungsdialoge, statt sie wegzuklicken, und schau dir den Befehl an, der dort steht. Und wenn du MCP-Server selbst eingerichtet hast, gehe deine Konfigurationen einmal durch und wirf raus, was du nicht mehr brauchst.
Für Teams gilt das auch. Ein Rechner mit produktiven Cloud-Zugangsdaten ist kein guter Ort für unbeaufsichtigte Experimente mit fremden Repositories. Getrennte Konten, kurzlebige Sitzungstoken statt dauerhafter Schlüssel und eine Arbeitsumgebung ohne Zugriff auf Produktionssysteme begrenzen den Schaden. Least Privilege ist keine Formalie für Audits, sondern entscheidet, ob ein Vorfall peinlich bleibt oder Folgen hat.
Was das im Alltag mit KI-Coding-Tools bedeutet
Die Lehre des Falls steckt nicht in einer CVE-Nummer. Sie steckt in der Frage, wie viel Vertrauen ein Werkzeug bekommt, nur weil es bequem ist. VS Code hat dafür den Workspace Trust. Er legt fest, ob ein Ordner als vertrauenswürdig gilt und ob Erweiterungen darin Code ausführen dürfen. Erweiterungen, die diese Funktion umgehen, sparen einen Klick und verschieben das Risiko auf den Nutzer.
Dasselbe gilt für die Weitergabe der Umgebung an Unterprozesse. Ein MCP-Server, der eine Datenbank abfragt, braucht keine AWS-Schlüssel. Sauber ist eine minimale Umgebung pro Prozess: genau die Variablen, die für die Aufgabe nötig sind, und nichts darüber hinaus. Das ist mehr Arbeit bei der Implementierung, deshalb passiert es selten von allein. Wer Werkzeuge baut, die Prozesse starten, sollte dort anfangen.
Für den nächsten Klon eines fremden Repositories heißt das: kurz aufpassen, bevor die Erweiterung anspringt. Nicht aus Paranoia, sondern weil die Grenze zwischen Code und Konfiguration in modernen Entwicklungsumgebungen durchlässig ist. Ein KI-Assistent, der Arbeit abnimmt, nimmt auch Entscheidungen ab. Manche davon sollte man selbst treffen. Der Fix von Amazon schließt diese eine Lücke. Die Gewohnheit, einem fremden Ordner erst einmal zu misstrauen, schließt die nächsten.
Quelle: wiz.io
