Ein Entwickler klont ein Repository, öffnet den Ordner in VS Code – und kurz darauf läuft ein lokaler Prozess mit Zugriff auf seine Cloud-Session. Kein klassischer Exploit gegen einen Server, kein Phishing-Link, kein Makro. Die Schwachstelle CVE-2026-12957 in Amazon Q Developer zeigt eine neue Sicherheitsklasse: AI-Coding-Assistenten können Workspace-Dateien nicht nur lesen, sondern unter bestimmten Bedingungen in ausführbare Tool-Konfigurationen verwandeln.
Wiz Research hat den Fall Ende Juni 2026 veröffentlicht. Amazon hat die Schwachstelle behoben. Trotzdem ist der Befund größer als Amazon Q: Das Problem entsteht dort, wo AI-Tools das Model Context Protocol (MCP) automatisch aus Projektverzeichnissen laden und dabei die wichtigste Sicherheitsfrage überspringen – ob der Nutzer diesem Workspace überhaupt vertraut.
Das Praxisproblem
MCP ist für Agenten nützlich, weil es KI-Assistenten mit lokalen Tools verbindet: Datenbanken, Cloud-CLIs, Build-Systeme, Dateisysteme, interne APIs. Ein MCP-Server ist technisch jedoch ein Prozess. Wenn ein Coding-Assistent ihn startet, läuft Code auf der Entwickler-Maschine – oft mit denselben Umgebungsvariablen, Tokens und Netzwerkrechten wie die IDE selbst.
Genau hier lag laut Wiz die Schwachstelle. Amazon Q Developer konnte MCP-Konfigurationen aus Workspace-Dateien laden, konkret aus .amazonq/-Verzeichnissen innerhalb eines Projekts. Öffnete ein Entwickler ein präpariertes Repository in VS Code und war Amazon Q aktiv, konnte eine dort abgelegte Konfiguration automatisch ausgeführt werden. Der Entwickler musste dem einzelnen MCP-Server nicht explizit zustimmen.
Das ist gefährlich, weil Git-Repositories von außen kommen: aus Open-Source-Projekten, Pull Requests, Coding-Tests, Beispielprojekten, Support-Zips oder internen Mirrors. Eine Datei im Repository ist zunächst nur Datenmaterial. Wenn ein AI-Coding-Tool sie automatisch als ausführbare Tool-Konfiguration interpretiert, verschiebt sich die Vertrauensgrenze.
Wie der Angriff funktioniert
Die von Wiz beschriebene Angriffskette ist technisch überschaubar:
- Ein Angreifer erstellt ein Repository mit einer versteckten MCP-Konfiguration.
- Diese Konfiguration startet einen lokalen Befehl, etwa einen Prozess, der Umgebungsvariablen oder Cloud-Identitäten ausliest.
- Das Opfer klont das Repository und öffnet es in VS Code mit installiertem Amazon Q Developer.
- Amazon Q lädt die Workspace-Konfiguration und startet den MCP-Server ohne ausreichende Zustimmung.
- Der Prozess läuft im Kontext des Entwicklers – inklusive möglicher AWS-Session-Tokens.
Wiz demonstrierte unter anderem, dass sich über aws sts get-caller-identity die aktive AWS-Identität des Entwicklers auslesen ließ. In einer realen Umgebung wäre der nächste Schritt nicht nur Informationsgewinn. Ein Angreifer könnte versuchen, neue IAM-Zugänge anzulegen, Infrastruktur zu verändern, Secrets zu kopieren oder CI/CD-Pfade zu kompromittieren.
Wichtig ist die Einordnung: Das ist kein Remote-Angriff gegen beliebige Rechner im Internet. Der Entwickler muss ein bösartiges oder manipuliertes Projekt öffnen. In modernen Entwicklungsprozessen ist genau das aber Alltag – bei externen Pull Requests, Open-Source-Reviews, Lieferanten-Code, Bewerber-Tests oder Incident-Analysen.
Faktenlage und Zeitlinie
Die Details stammen aus dem Wiz-Research-Blogpost vom 26. Juni 2026; The Hacker News berichtete am selben Tag. Amazon bestätigte die Schwachstelle gegenüber Wiz und verwies auf Security Bulletin 2026-047-AWS.
Die veröffentlichte Timeline:
- 17. April 2026: Wiz entdeckt die Schwachstelle.
- 20. April 2026: Meldung an Amazon Security; Amazon bestätigt den Eingang.
- 12. Mai 2026: Fix per Language-Server-Update.
- 23. Juni 2026: CVE-2026-12957 wird zugewiesen.
- 26. Juni 2026: Öffentliche Offenlegung.
Betroffen waren Amazon-Q-Language-Server-Versionen vor 1.65.0. Nach dem Fix soll Amazon Q einen Consent-Dialog anzeigen, bevor MCP-Server aus Workspace-Konfigurationen geladen werden. Unternehmen sollten trotzdem prüfen, ob Auto-Updates in verwalteten Entwicklerumgebungen tatsächlich greifen. Gerade in Enterprise-Netzen sind Extension- und Language-Server-Updates häufig verzögert oder durch Proxies blockiert.
Warum das mehr ist als ein Amazon-Q-Bug
Der wichtigste Punkt im Wiz-Bericht ist die Systematik. Wiz verwies auf ähnliche Schwachstellen in anderen AI-Coding-Tools, darunter Claude Code, Cursor und Windsurf. Die konkreten CVEs, Versionen und Forscher unterscheiden sich; das Muster ist gleich: Workspace-Dateien werden von Agenten-Tools als Konfiguration für lokale Tool-Ausführung interpretiert, bevor eine robuste Trust-Entscheidung getroffen wurde.
Das erinnert an frühere Sicherheitslektionen aus Browsern, Office-Makros und CI/CD-Systemen. Sobald Daten aus einer fremden Quelle automatisch zu Aktionen werden, entsteht eine Angriffsfläche. Bei AI-Coding-Assistenten ist diese Grenze besonders heikel, weil Agenten gerade dafür gebaut sind, Werkzeuge aufzurufen, Dateien zu verändern und Prozesse zu starten.
MCP verschärft das Problem nicht, weil das Protokoll per se unsicher wäre, sondern weil seine Integration in Entwicklungswerkzeuge sehr mächtig ist. Ein MCP-Server kann harmlos sein – etwa ein lokaler Dokumentationsindex. Er kann aber auch Shell-Befehle, Cloud-CLIs oder interne Services erreichen. Die Sicherheitsfrage lautet daher nicht nur: „Ist die Konfiguration syntaktisch korrekt?“, sondern: „Wer kontrolliert diese Konfiguration, welche Rechte bekommt der gestartete Prozess, und hat der Nutzer zugestimmt?“
Was Unternehmen jetzt prüfen sollten
Amazon Q aktualisieren. Mindestziel ist der Amazon Q Language Server ab Version 1.65.0. Zusätzlich sollten Security-Teams prüfen, ob betroffene Entwickler-Images, VDI-Umgebungen oder Devcontainer alte Komponenten enthalten.
Workspace-Konfigurationen inventarisieren. Suchen Sie nach .amazonq/-Verzeichnissen und nach MCP-Konfigurationsdateien in Repositories. Nicht jede Datei ist bösartig, aber jede automatisch geladene Tool-Konfiguration gehört in ein Review.
Untrusted Repositories isolieren. Externe Repos sollten nicht in einer Umgebung geöffnet werden, die produktive Cloud-Credentials, langlebige Tokens oder Zugriff auf interne Netzwerke enthält. Für Reviews, Bewerber-Tasks und fremde PoCs sind Container, kurzlebige VMs oder separate Cloud-Identitäten sinnvoll.
Environment-Inheritance begrenzen. MCP-Server sollten nicht automatisch die komplette Umgebung der IDE erben. Besser ist eine Allowlist: Nur Variablen und Secrets, die ein konkretes Tool wirklich benötigt, werden weitergereicht. Alles andere bleibt außerhalb des Prozesses.
Consent-Modelle testen. Unternehmen sollten ihre AI-Coding-Tools praktisch prüfen: Was passiert beim Öffnen eines neuen Workspaces? Werden MCP-Server automatisch erkannt? Gibt es eine klare Zustimmung? Wird VS-Code-Workspace-Trust respektiert? Können Richtlinien zentral erzwungen werden?
Grenzen der Schwachstelle
CVE-2026-12957 ist kein Beweis dafür, dass alle Amazon-Q-Nutzer kompromittiert wurden. Die Ausnutzung setzt ein manipuliertes Projekt und eine passende Tool-Umgebung voraus. Auch der Schaden hängt stark davon ab, welche Credentials im Entwicklerkontext verfügbar sind.
Gerade diese Einschränkung ist aber der Grund, warum das Thema in Unternehmen ernst genommen werden sollte. Entwicklerumgebungen enthalten häufig genau die Berechtigungen, die Angreifer suchen: Cloud-Sessions, SSH-Schlüssel, Paketregistry-Tokens, GitHub-Zugänge, CI/CD-Secrets oder Zugriff auf interne Dokumentation. Ein lokaler Agentenprozess muss deshalb wie ein privilegierter Integrationspunkt behandelt werden, nicht wie ein Komfortfeature der IDE.
Fazit
CVE-2026-12957 ist ein Warnsignal für die nächste Phase der AI-Security. Coding-Agenten sind nicht nur Chatfenster neben dem Editor. Sie starten Tools, lesen Konfigurationen, erben Umgebungen und greifen auf Infrastruktur zu. Damit werden Projektdateien, die früher inert waren, zu potenziellen Auslösern für Code-Ausführung.
Amazon hat den konkreten Fehler behoben. Die Architekturfrage bleibt: AI-Coding-Tools müssen untrusted Workspace-Daten, Tool-Ausführung und Cloud-Credentials sauber voneinander trennen. Für Unternehmen heißt das: MCP und Agenten-Integrationen gehören in dieselbe Governance-Kategorie wie CI/CD-Pipelines, Browser-Erweiterungen und privilegierte Developer-Workstations.
