Amazon Q Extension-Fehler leakte AWS-Zugangsdaten beim Öffnen von Repos

Jeder Backend-Lead, der einem Junior schon einmal gesagt hat, er solle „einfach das Repo klonen und sich umsehen", sollte hier kurz innehalten. Eine Sicherheitslücke in der Amazon Q Developer Extension ermöglichte es einer Workspace-Konfigurationsdatei, beliebige Befehle auszuführen, sobald ein Entwickler ein feindseliges Repository öffnete. Kein Prompt, keine Warnung, keine Zustimmung. Nur Code-Ausführung innerhalb derselben Shell, die Ihre AWS-Zugangsdaten enthält.

Was ist passiert

Wiz-Forscher haben CVE-2026-12957 offengelegt, eine Sicherheitslücke in der Amazon Q Developer Extension für Visual Studio Code, die automatisch Befehle aus Workspace-Konfigurationsdateien ausführte. Wie SC Media berichtete, reichte es aus, ein kompromittiertes Repository zu öffnen, um die Kette auszulösen. Die Extension parste die Konfiguration, führte alles aus, was der Angreifer eingebettet hatte, und der Entwickler sah niemals einen Bestätigungsdialog.

Der Explosionsradius war die lokale Workstation – was in der Praxis aktive Cloud-Zugangsdaten, API-Keys und alles andere bedeutet, was ein arbeitender Entwickler in seiner Umgebung aufbewahrt. Wiz identifizierte drei plausible Angriffsvektoren: gefälschte Coding-Tests, die während Interview-Prozessen verschickt werden, typosquattete Open-Source-Pakete, die als Abhängigkeiten eingebunden werden, und schädliche Pull Requests gegen legitime Projekte. Jeder davon nutzt dieselbe Vertrauensannahme: Ein Entwickler klont, öffnet, prüft.

AWS wurde am 20. April benachrichtigt und lieferte am 12. Mai einen Patch. Das sind etwa drei Wochen Reaktionszeit des Herstellers bei einem Credential-Exfiltration-Fehler – vertretbar, aber nicht beeindruckend. AWS wies darauf hin, dass der Language Server für die meisten Nutzer automatisch aktualisiert wird. Die noch gefährdete Gruppe besteht heute hauptsächlich aus Teams, die gepinnte oder air-gapped IDE-Setups betreiben. Dieselbe Fehlerklasse betraf die Extension in Visual Studio Code, JetBrains, Eclipse und Visual Studio – es handelte sich also nicht um eine einzelne IDE-Eigenheit, sondern um ein gemeinsames Backend-Verhalten mit breiter Reichweite.

Die Offenlegung vermerkte außerdem, dass ähnliche Schwachstellen in anderen KI-Coding-Tools aufgetaucht sind – der Teil, der Plattform-Leads beunruhigen sollte.

Technische Analyse

Der Mechanismus ist erschreckend einfach. Moderne IDE-Extensions lesen Workspace-Konfigurationsdateien beim Laden eines Projekts: Task-Definitionen, Run-Targets, Language-Server-Hinweise und Projektmetadaten. Diese Dateien sind versionskontrolliert, was bedeutet: Wer das Repo besitzt, besitzt die Konfiguration. Wenn eine Extension diese Werte als ausführbare Anweisungen statt als deklarative Daten behandelt, entsteht ein Remote-Code-Execution-Primitiv, das als Produktivitätsfunktion getarnt ist.

Bei CVE-2026-12957 verarbeitete die Amazon Q Developer Extension Workspace-Konfigurationsinhalte und handelte auf Basis eingebetteter Befehle, ohne den Nutzer zu fragen. Die Vertrauensgrenze war am falschen Ort gezogen. Die Extension vertraute implizit jeder Datei innerhalb eines Ordners, den der Nutzer zu öffnen wählte – dasselbe Bedrohungsmodell wie das Doppelklicken auf einen E-Mail-Anhang aus dem Jahr 2003. Den CVE-Eintrag können Sie über den MITRE-Katalog überprüfen, während sich Fixes verbreiten.

Aus Sicht eines Angreifers schreibt sich der Ablauf von selbst. Man richtet ein Repository ein, das wie eine legitime Take-Home-Aufgabe für eine Senior-Go-Stelle aussieht. Die Nutzlast wird in die Workspace-Konfiguration eingebettet. Man wartet, bis ein Kandidat klont und öffnet. Die Nutzlast läuft, erntet `~/.aws/credentials`, Umgebungsvariablen und alle gecachten Session-Tokens und sendet sie an einen vom Angreifer kontrollierten Endpunkt. Der Entwickler sieht ein normal aussehendes Projekt. Wenn jemand den Datenabfluss bemerkt, werden mit den Zugangsdaten bereits EC2-Instanzen erstellt oder S3 geleert.

Der typosquattete Paket-Vektor ist schlimmer, weil er skaliert. Eine einzige schädliche Abhängigkeit, die in ein populäres Template-Repo gezogen wird, verschafft dem Angreifer einen stetigen Strom von Opfern, die die Datei nie geprüft haben. Der schädliche PR-Vektor zielt direkt auf Maintainer ab, also auf die Accounts mit den höchsten Privilegien in einer Organisation. Bei Produktionsvorfällen mit kompromittierten Entwickler-Workstations, die ich erlebt habe, liegt die Ursache fast immer darin, dass ein Tool still Eingaben ausführte, die der Entwickler für inert hielt.

Meine Einschätzung: Dies ist die KI-Coding-Assistenten-Generation derselben Fehlerklasse, die vor einem Jahrzehnt Editor-Plugins betraf – und das Fix-Muster hat sich nicht geändert. Behandeln Sie Repo-gelieferte Konfigurationen als nicht vertrauenswürdige Eingaben, stellen Sie Ausführung hinter explizite Zustimmung und isolieren Sie den Language Server von Credential-tragenden Scopes.

Wer betroffen ist

Drei Gruppen sind gefährdet, in absteigender Reihenfolge des Schadens.

Erstens: Teams, die gepinnte IDE- oder Extension-Versionen aus Compliance- oder Reproduzierbarkeitsgründen betreiben. AWS sagt, der Language Server aktualisiert sich für die meisten Nutzer automatisch, aber „die meisten" leistet in diesem Satz viel Arbeit. Regulierte iGaming-Betreiber in Malta und Gibraltar frieren Entwickler-Tooling oft ein, um Change-Control-Auditoren zu erfüllen. Fintechs unter DORA-Scope machen dasselbe. Diese Teams müssen jetzt bestätigen, dass ihre gepinnten Versionen den Patch vom 12. Mai enthalten oder schnell aktualisieren.

Zweitens: Organisationen, die langlebige AWS-Zugriffsschlüssel auf Entwickler-Laptops verwenden. Wenn eine Workstation zwischen der Einführung des Fehlers und dem Patch kompromittiert wurde, sollten die darauf befindlichen Zugangsdaten als verbrannt gelten. Rotation ist keine Option. Teams, mit denen ich gearbeitet habe und die nach ähnlichen Vorfällen auf Rotation verzichteten, stellten Monate später fest, dass ein vergessener IAM-Benutzer still Crypto-Miner in us-east-2 betrieb.

Drittens: Engineering-Organisationen, die externe Coding-Assessments durchführen. Der Fake-Coding-Test-Vektor zielt direkt auf Ihre Einstellungs-Pipeline. Jeder Kandidat, der in dem betroffenen Zeitfenster ein Take-Home geöffnet hat, ist ein potenzieller Gefahrenpunkt – ebenso jeder Interviewer, der die Einreichung des Kandidaten geöffnet hat. Das wirkt in beide Richtungen.

Die unbequeme Erkenntnis: Diese Fehlerklasse wird sich wiederholen. KI-Coding-Assistenten beeilen sich, agentische Funktionen hinzuzufügen, was per Definition bedeutet, Dinge im Namen des Nutzers auszuführen. Jede neue Funktion ist ein weiterer Entscheidungspunkt, an dem ein Hersteller zwischen Reibung und Sicherheit wählen muss. Der Markt belohnt derzeit Reibungsreduzierung. Erwarten Sie weitere CVEs in dieser Form für Copilot, Cursor, Cody und was auch immer nächstes Quartal erscheint. Die Offenlegung weist ausdrücklich darauf hin, dass ähnliche Schwachstellen bereits in anderen KI-Coding-Tools aufgetaucht sind.

Maßnahmenplan für Sicherheitsteams

Konkrete Maßnahmen für diese Woche, nach Priorität geordnet.

Bestätigen Sie, dass die Amazon Q Developer Extension auf jeder IDE in Ihrer Flotte aktualisiert ist: Visual Studio Code, JetBrains, Eclipse und Visual Studio. Vertrauen Sie dem Auto-Update-Versprechen nicht, bis Sie installierte Versionen gegen das Post-12.-Mai-Release geprüft haben. MDM-verwaltete Laptops machen das zu einer Einzeilen-Abfrage. BYOD-Umgebungen benötigen eine klare Benachrichtigung.

Rotieren Sie alle AWS-Zugriffsschlüssel, Session-Tokens und API-Keys von Drittanbietern, die zwischen dem 20. April und dem 12. Mai auf Entwickler-Workstations vorhanden waren – oder früher, wenn Sie bei der Pre-Disclosure-Ausnutzung auf der sicheren Seite sein wollen. Wenn Sie 2026 noch langlebige IAM-User-Keys an Entwickler vergeben, ist dies der Vorfall, der Sie zu kurzlebigen Zugangsdaten über IAM Identity Center oder ähnlichem bewegen sollte.

Prüfen Sie Ihren Einstellungsprozess. Jeder Take-Home-Coding-Test-Workflow, bei dem ein externes Repository in einer primären Entwicklungsumgebung geöffnet wird, muss in eine Wegwerf-VM, einen Devcontainer oder eine Cloud-Sandbox verlagert werden. Das ist eine günstige Absicherung und schließt den Fake-Test-Vektor dauerhaft.

Fügen Sie das IDE-Extension-Inventar zu Ihrem Asset-Management hinzu. Die meisten Sicherheitsteams verfolgen OS-Patches und Browser-Versionen, haben aber null Sichtbarkeit darauf, welche Extensions Entwickler betreiben. Diese Lücke ist jetzt ein bekannter Credential-Exfiltration-Pfad. Gleichen Sie Erkenntnisse mit dem CISA KEV-Katalog ab, wenn Ausnutzungsberichte auftauchen.

Schreiben Sie schließlich eine einseitige interne Richtlinie: Kein KI-Coding-Assistent wird auf einer Workstation installiert, die Produktions-Zugangsdaten enthält – Punkt. Entwickler können Assistenten in isolierten Umgebungen betreiben. Der Komfortverlust ist real. Die Alternative ist schlimmer.

Wichtigste Erkenntnisse

• CVE-2026-12957 ermöglichte es der Amazon Q Developer Extension, automatisch Befehle aus Workspace-Konfigurationsdateien auszuführen und AWS-Zugangsdaten beim Öffnen des Repos preiszugeben.
• AWS patchte am 12. Mai nach der Wiz-Offenlegung am 20. April, aber Shops mit gepinnten Versionen bleiben gefährdet, bis sie das Update verifizieren.
• Der Fehler betraf Visual Studio Code, JetBrains, Eclipse und Visual Studio und ist damit ein IDE-übergreifendes Backend-Problem, kein einzelner Editor-Bug.
• Gefälschte Coding-Tests, typosquattete Pakete und schädliche Pull Requests sind die drei von Wiz identifizierten aktiven Angriffsvektoren.
• Rotieren Sie entwicklerseitig gehaltene Cloud-Zugangsdaten, isolieren Sie externe Repos in Sandboxes und inventarisieren Sie IDE-Extensions, bevor das nächste KI-Assistenten-CVE eintrifft.