Amazon Web Services veröffentlichte am 10. September 2026 Korrekturen für zwei zusammenhängende Schwachstellen in seinen KI-gestützten Security-Agent-Werkzeugen. CVE-2026-87912 betrifft das Security-Agent-Plugin in Amazon aws-agents-for-devsecops vor Version 1.1.0. CVE-2026-87913 betrifft den AWS Security Agent MCP-Server vor Version 0.2.0.
Laut AWS beruhen beide Lücken auf einer fehlenden Eigentumsprüfung für einen S3-Bucket, dessen Name aus einer öffentlich bekannten AWS-Konto-ID abgeleitet wird. Ein entfernter Angreifer, der den erwarteten Bucket-Namen zuerst registrierte, könnte ein privates Quellarchiv erhalten, das zum Scannen übermittelt wird. AWS warnt, dass ein solches Archiv Zugangsdaten und den Zustand der Infrastruktur enthalten kann.
Die Abhilfe ist eindeutig: Betroffene Komponenten aktualisieren und danach prüfen, ob der Scan-Eingabe-Bucket tatsächlich dem erwarteten AWS-Konto gehört. Ein Upgrade holt keinen Bucket-Namen zurück, den bereits ein Dritter registriert hat. Öffentliche CVE-Einträge bestätigen unabhängig die betroffenen Versionen, das Offenlegungsdatum und den CVSS-Wert 5,9. Öffentliche Belege für aktive Ausnutzung oder eine Zahl betroffener Nutzer gibt es jedoch nicht.
So entsteht der Expositionspfad
Für Sicherheitsscans werden Quellcode und Konfiguration häufig in ein Archiv gepackt und an einen Speicherort übertragen, den der Scanner erreichen kann. Die verwundbaren Komponenten verwendeten ein vorhersehbares Namensmuster für den Bucket. Sie prüften nicht ausreichend, ob der so ermittelte Bucket dem Konto gehörte, das den Scan gestartet hatte.
Damit entsteht eine falsche Eigentumsgrenze. Der Agent kann zum Scannen privaten Codes berechtigt sein, während das Ziel des Archivs nicht zum Speichern berechtigt ist. Repositories enthalten oft Bereitstellungsdateien, Umgebungsreferenzen, Geheimnisse und Infrastrukturdefinitionen. Ein falsches Ziel kann daher aus einem defensiven Ablauf einen Datenabfluss machen.
Betroffen sind sowohl ein Plugin als auch ein MCP-Server. MCP erleichtert Agenten den Aufruf von Sicherheitswerkzeugen, ersetzt aber keine Autorisierung auf Dienstebene und keine Prüfung des Ressourceneigentums.
Der Patch ist nötig, reicht aber nicht
AWS nennt Version 1.1.0 als korrigierte Ausgabe des Plugins aws-agents-for-devsecops und Version 0.2.0 für den Security Agent MCP-Server. Forks und abgeleitete Implementierungen benötigen die entsprechenden Änderungen ebenfalls.
Administratoren dürfen nach dem Paket-Update nicht aufhören. AWS verlangt die Prüfung des Eigentümers des Scan-Eingabe-Buckets mit dem Muster aus security-agent-scans, Konto und Region. Kontrolliert bereits ein Dritter diesen Namen, hebt die neue Version die frühere Registrierung nicht auf.
Eine kontrollierte Reaktion umfasst deshalb mindestens vier Schritte:
- Alle Installationen und Forks beider Komponenten ermitteln.
- Installierte Version und genaue Paketquelle bestätigen.
- Eigentümer, Richtlinie und Zugriffshistorie jedes Scan-Buckets prüfen.
- Feststellen, ob sensible Archive außerhalb des vorgesehenen Kontos gespeichert wurden.
Ist eine Offenlegung plausibel, sollten Teams betroffene Zugangsdaten rotieren, Zugriffsprotokolle untersuchen und im Archiv referenzierte Folgesysteme prüfen. Diese Schritte hängen von lokalen Belegen ab. Das AWS-Bulletin behauptet nicht, dass jede verwundbare Installation Daten verloren hat.
Was Teams für Agentensicherheit lernen sollten
Die Schwachstelle zeigt, warum die Prüfung eines Tool-Aufrufs nicht bei einer syntaktisch gültigen Anfrage enden darf. Ein Sicherheitsagent kann den richtigen Vorgang wählen und sensible Inhalte trotzdem an die falsche Ressource senden. Laufzeitkontrollen müssen Identität, Eigentum, Umfang und erwartete Wirkung an der Ressourcengrenze prüfen.
Bei Schreibvorgängen in Speicher sollte der Aktionsrahmen Zielkonto, Region, Bucket-Kennung, Objektpfad, Verschlüsselungsanforderungen und Aufbewahrungsregel enthalten. Vor der Ausführung sollte der aufgelöste Eigentümer mit dem genehmigten Eigentümer verglichen werden. Danach ist zu bestätigen, dass das Archiv ausschließlich am vorgesehenen Ort angekommen ist.
Maetras Leitfaden zu Kontrollen gegen Prompt Injection für KI-Agenten erläutert, warum Werkzeugnutzung bei nicht vertrauenswürdigen Eingaben begrenzt werden muss. Die Checkliste für das Inventar von KI-Agenten hilft, betroffene Agenten, Repositories, Werkzeuge und Verantwortliche zu finden.
Aufzubewahrende Nachweise
Teams sollten Paketversionen, Bereitstellungsorte, Ergebnisse der Eigentumsprüfung, Richtlinien, Zugriffsprotokolle, Objekthistorien der Archive, Nachweise zur Rotation von Zugangsdaten und Vorfallentscheidungen sichern. Enthält ein Fork das verwundbare Muster, sollten der korrigierende Commit und Tests dokumentiert werden, die bei einem Eigentumskonflikt sicher abbrechen.
Eine Auditakte muss zwischen vorhandener Schwachstelle, Ausnutzbarkeit, vermuteter Offenlegung und bestätigtem Zugriff unterscheiden. Wer diese Zustände gleichsetzt, erzeugt entweder falsche Sicherheit oder unnötige Eskalation.
Der Leitfaden für Nachweise in KI-Audits zeigt, wie technische Feststellungen mit Verantwortlichen, Entscheidungen und Belegen der Behebung verknüpft werden.
Maetra-Analyse
Diese Lücken liegen an der Schnittstelle von KI-Sicherheit und gewöhnlicher Cloud-Autorisierung. Der Fehler bestand nicht darin, dass der Agent eine bösartige Aufgabe auswählte. Ein vertrauenswürdiger Ablauf übermittelte vielmehr ein wertvolles Archiv, ohne zuvor den Ressourceneigentümer entscheidend zu prüfen.
Die dauerhafte Lösung geht über zwei Paket-Updates hinaus. Betreiber von Sicherheitsagenten sollten jede externe Wirkung inventarisieren, sie an eine verifizierte Ressourcenidentität binden und Belege für den erreichten Sollzustand aufbewahren. Vor erweiterten Agentenrechten gehören auch Kollisionen vorhersehbarer Namen, kontoübergreifende Ressourcen und veraltete Infrastrukturannahmen in die Tests.