CVE-2026-87913: AWS-MCP-S3-Datenleck

Ein vorhersehbarer Bucket konnte private Scanarchive in einem fremden Konto speichern. Aktualisieren Sie auf 0.2.0 und prüfen Sie den Eigentümer.^{[1], [2], [4]}

💡 Einfache Erklärung (ELI5)

Stellen Sie sich einen Kurier vor, der prüft, ob ein Gebäude unter einer Adresse existiert, aber nicht, wem es gehört. Eine andere Person kann die Adresse zuerst registrieren und das Paket erhalten. S3 muss den erwarteten Eigentümer bei Prüfung und Upload bestätigen.^{[2], [1]}

Kernkonzepte & Begriffe

MCP-Server: Lokaler Dienst mit Werkzeugen für KI-Assistenten; sie nutzen die Rechte des Serverprozesses.^[3]
S3-Bucket: Amazon-S3-Container mit globalem Namen; daraus geht das besitzende AWS-Konto nicht hervor.^{[2], [3]}
ExpectedBucketOwner: S3-Parameter, der vor der Operation die erwartete AWS-Konto-ID des Eigentümers bestätigen lässt.^{[2], [8], [9]}
CWE-283 und CWE-341: MITRE-Schwächen für ungeprüfte Eigentümerschaft und vorhersehbare Werte; der Hinweis ordnet beide zu.^{[8], [9]}

Framework-Zuordnungen

CWE-Referenz für die in diesem Leitfaden beschriebene Schwachstelle: CWE-283 CWE-341
OWASP GenAI 2025 — LLM06:2025 Übermäßige Autonomie

Ursachenanalyse

Der AWS-Security-Agent-MCP-Server leitet den Namen des Scan-Buckets aus AWS-Konto-ID und Region ab: security-agent-scans-<account-id>-<region>. Laut AWS und Maintainer prüfte die verwundbare Version nur, ob der Bucket existierte, nicht ob er dem Kundenkonto gehörte. S3-Namen sind global und Konto-IDs öffentlich. Ein Dritter, der den vorhersehbaren Namen zuerst registrierte, konnte das private hochgeladene Quellarchiv erhalten; es kann Code, Zugangsdaten und Infrastrukturzustand enthalten. Das ist eine fehlende Eigentümerprüfung für eine Cloud-Ressource und ein vorhersehbarer Name, keine Prompt-Injection im KI-Modell. Betroffen sind 0.1.0 bis 0.1.5; 0.2.0 ergänzt ExpectedBucketOwner für S3-Operationen und bricht bei fremdem Eigentümer ab. Ein Upgrade gibt einen bereits registrierten Namen nicht frei: Prüfen Sie den tatsächlichen Eigentümer und starten Sie keine Scans, wenn der Bucket einem Dritten gehört.

Der Bucket-Name beweist nicht die Eigentümerschaft

Grenze	Dokumentierte Bedingung	Maßnahme
Betroffene Versionen	awslabs.security-agent-mcp-server 0.1.0 bis 0.1.5 sind betroffen; 0.2.0 ergänzt die Eigentümerprüfung.	Auf Version 0.2.0 oder höher aktualisieren und die laufende Paketversion prüfen.
Vorhersehbarer Bucket-Name	Der Name des Scan-Buckets wird aus Konto-ID und Region abgeleitet; ein anderes AWS-Konto kann ihn registrieren.	Einen passenden Namen als Adresse behandeln, nicht als Eigentumsnachweis.
Kontoübergreifender Upload	Der verwundbare Server konnte den Bucket ohne Eigentümerprüfung anhand des Namens akzeptieren und ein privates Scan-Archiv hochladen.	Vor Scan oder Upload prüfen, ob der Bucket dem erwarteten Konto gehört.
Behobene Eigentumsgrenze	ExpectedBucketOwner veranlasst S3, den Eigentümer sowohl bei der Prüfung als auch beim Upload abzugleichen.	Aktualisieren, tatsächlichen Eigentümer prüfen und Scans bei fremdem Besitz stoppen; ein Upgrade überträgt den Bucket nicht.

Schritt-für-Schritt Angriffsablauf

Schritt 1

Ein Scan erhält Quellcode

Ein KI-Client fordert einen Scan an; der Server archiviert den Arbeitsbereich mit seiner AWS-Identität.^{[3], [2]}

Schritt 2

Das Ziel ist vorhersehbar

Der Name leitet sich aus Konto-ID und Region ab; IDs sind öffentlich und S3-Namen global.^{[1], [2]}

Schritt 3

Die Prüfung sieht nur die Existenz

Der Server akzeptierte den Bucket anhand des Namens, ohne das Kundeneigentum bestätigen zu lassen.^{[2], [1]}

Schritt 4

Das Archiv kann ein anderes Konto erreichen

Registrierte ein Dritter den Namen zuerst, konnte er das private Archiv mit möglichen sensiblen Daten erhalten.^{[2], [1]}

Quellcode: Verwundbar vs. Sicher

Der Code ist schematisch, keine wörtliche Kopie. Existenz genügt nicht: S3 muss das erwartete Eigentümerkonto bei Prüfung und Schreibvorgang vergleichen. Beziehen Sie es aus der authentifizierten AWS-Identität und brechen Sie bei Abweichungen ab. Prüfen Sie nach dem Upgrade den Eigentümer separat, denn es überträgt oder entsperrt keinen bereits registrierten Namen. AWS dokumentiert ExpectedBucketOwner für HeadBucket und PutObject: Bei einer Abweichung schlägt die Anfrage mit 403 fehl. Nutzen Sie dies als Fail-closed-Schutz, prüfen Sie Access-Denied-Fehler jedoch über einen autorisierten Eigentumsnachweis, bevor Sie auf einen fremden Bucket schließen.^{[2], [8], [9]}

Quelltextauszug: Aus dem Advisory abgeleitetes AWS-SDK-Beispiel; kein wörtlicher Quelldiff.

VERWUNDBARE IMPLEMENTIERUNG

# Vereinfachte verwundbare Form: Der Name wird geprüft, nicht aber der Eigentümer.
s3.head_bucket(Bucket=bucket_name)
s3.put_object(
    Bucket=bucket_name,
    Key=object_key,
    Body=archive_bytes,
)

GEHÄRTETER SICHERHEITS-PATCH

# Jede Operation an das erwartete Konto des Bucket-Eigentümers binden.
expected_owner = sts.get_caller_identity()["Account"]
s3.head_bucket(
    Bucket=bucket_name,
    ExpectedBucketOwner=expected_owner,
)
s3.put_object(
    Bucket=bucket_name,
    Key=object_key,
    Body=archive_bytes,
    ExpectedBucketOwner=expected_owner,
)

Checkliste für Engineering & Systemsicherheit

✓Aktualisieren Sie auf 0.2.0 oder neuer und prüfen Sie die Laufzeitversion samt Plugins, CI-Images und Forks.^{[2], [4]}
✓Prüfen Sie vor dem Scan, ob der Bucket dem erwarteten Konto gehört; ein gefundener Name beweist kein Eigentum.^{[1], [2]}
✓Übergeben Sie das erwartete Konto als ExpectedBucketOwner an jede S3-Operation, einschließlich Uploads.^{[8], [9]}
✓Brechen Sie bei Abweichungen ab. Gehört der Name einem Dritten, stoppen Sie Scans und kontaktieren AWS.^[1]
✓Erstellen Sie den Bucket wenn möglich vor der ersten Nutzung im Kundenkonto und setzen Sie minimale Rechte und Verschlüsselung ein.^{[3], [1]}
✓Prüfen Sie Scans aus betroffenen Versionen und wechseln Sie Zugangsdaten, falls Archive Geheimnisse enthalten konnten.^{[2], [1]}