CVE-2026-18953: AWS' Transform MCP Server hatte keine Schreibgrenze

Amazon veröffentlichte am 5. August 2026 das Sicherheitsbulletin 2026-075-AWS für CVE-2026-18953, einen Path-Traversal im get_resource-Tool von awslabs.aws-transform-mcp-server, dem Open-Source-Model-Context-Protocol-Server, der auf dem eigenen Rechner eines Entwicklers läuft, damit ein KI-Assistent AWS-Transform-Jobs ausführen und deren Artefakte abrufen kann. Die Versionen 0.1.0 bis 0.1.4 schränkten Pfadnamen nicht ausreichend ein, und der savePath-Parameter konnte Dateien außerhalb des vorgesehenen Arbeitsverzeichnisses schreiben – was der GitHub-Advisory im Repository von Amazon mit „zu lokaler Codeausführung führen könnte“ angibt. Amazon bewertete es mit 8,6 (Hoch). Die Korrektur ist Version 0.1.5, und es gibt keine serverseitige oder ausschließlich konfigurationsbasierte Problemumgehung, weil der anfällige Codepfad in der Standardkonfiguration vorhanden ist. Keine öffentliche Quelle hat dokumentiert, dass jemand dies ausgenutzt hat. Der vollständige Datensatz mit seinen Schweregrad- und Konfidenzbewertungen befindet sich im Orca AI Incident Archive, zusammen mit den MCP- und Agent-Runtime-Vorfällen, die unter demselben Monat abgelegt wurden.

Ein MCP-Server, der dort schreibt, wo der Entwickler arbeitet

„Model Context Protocol-Server sind die Ebene, die einem Assistenten aufrufbare Tools bereitstellt, und dieser ist bewusst lokal. Amazons Bulletin beschreibt ihn als ‚einen Open-Source-MCP-Server, der lokal auf dem Rechner eines Entwicklers läuft und KI-gestützten Assistenten die Interaktion mit AWS Transform ermöglicht, um Code-Transformationsjobs auszuführen und deren Artefakte abzurufen.‘ In seiner Paketbeschreibung auf dem Python Package Index heißt es, dass er den Transform-Lebenszyklus über 19 Tools verfügbar macht und Transformations-Workspaces, Jobs, Konnektoren, Human-in-the-Loop-Aufgaben, Artefakte und Chat verwaltet sowie Mainframe-Modernisierung, VMware-Migration, .NET-Modernisierung und benutzerdefinierte Code-Transformationen abdeckt.“

Genau diese Platzierung ist es, die die Schwachstelle relevant macht. Ein Server auf der eigenen Infrastruktur eines Anbieters, der einen Dateinamen falsch behandelt, beschädigt den Speicher des Anbieters. Dieser hier lief als der Entwickler, im Home-Verzeichnis des Entwicklers, neben dessen Shell-Konfiguration und SSH-Schlüsseln, und die von Amazon beschriebene Auswirkung ist kein beschädigter Download, sondern „lokale Codeausführung“. Jede der CVE zugeordnete Bewertung stimmt in einem Punkt überein: Der Angriffsvektor ist lokal, nicht netzwerkbasiert.

Das im Advisory genannte Tool ist dasjenige, das ein Job-Artefakt auf die Festplatte herunterlädt. get_resource erwartet einen savePath, der angibt, wo die Datei abgelegt werden soll. Der Fehler besteht darin, dass nichts diesen Pfad daran hinderte, einen anderen Ort anzugeben.

Wie schlimm – und nach wessen Rechnung?

An dieses CVE sind drei Bewertungen geknüpft, und sie stimmen nicht überein. Amazon, das das CVE als Nummerierungsstelle vergeben hat, bewertet es mit 8,6 High auf CVSS v3.1 mit dem Vektor CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — lokal, geringe Komplexität, keine Berechtigungen erforderlich, Benutzerinteraktion erforderlich, Scope geändert, hohe Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit. Der Eintrag von NIST in der National Vulnerability Database trägt eine eigene primäre v3.1-Bewertung von 8,8 auf einem anderen Vektor, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: geringe Berechtigungen erforderlich, keine Benutzerinteraktion. Beide liegen im High-Bereich. Die Uneinigkeit betrifft die Voraussetzungen — ob der Akteur bereits einen Einstiegspunkt benötigt und ob ein Mensch überzeugt werden muss — nicht, wie schlimm das Ergebnis ist.

Die CVSS-v4.0-Bewertung von Amazon für dieselbe CVE ist 6,3, Mittel, auf Basis von CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Lesen Sie die Impact-Metriken: nichts am verwundbaren System selbst, alles hoch am nachfolgenden System. Das ist die Form einer Traversierung, die aus der eigenen Grenze eines Tools ausbricht — der Schaden entsteht an dem, was das Tool erreichen kann, deshalb landet er in der Subsystem-Spalte, und das verwundbare System erzielt null Punkte.

Die CISA-Anreicherung der CVE vom 6. August 2026 verzeichnet eine SSVC-Entscheidung mit Exploitation: none, Automatable: no, Technical Impact: total. Der NVD-Datensatz wurde zuletzt am 23. Oktober 2026 geändert und führt weiterhin sowohl die 8.6 als auch die 8.8 nebeneinander auf. Keines der beiden Dokumente betrachtet das andere als falsch.

Was der anfällige Code tat und was 0.1.5 geändert hat

Amazons Beschreibung des Mechanismus ist ein Satz und sorgfältig formuliert: Das Tool „habe Pfadnamen nicht ausreichend eingeschränkt“, was „einem kontextabhängigen Akteur“ ermöglichen könnte, „über den Parameter savePath beliebige Dateien außerhalb des vorgesehenen Arbeitsverzeichnisses zu schreiben“. Der Sicherheitshinweis definiert den Akteur nicht, sagt nicht, was den Schreibvorgang auslöst, und beschreibt nicht, wie ein erfolgreicher Exploit aussieht. Er sagt nur, dass das Ergebnis „zur lokalen Codeausführung führen könnte“.

Die detaillierteste öffentliche Darstellung des Mechanismus ist nicht die von Amazon. Es ist ein kleines Proof-of-Concept-Repository, ronamosa/CVE-2026-18953, veröffentlicht auf GitHub am 8. August 2026 unter Apache-2.0 – zwei Commits, keine Stars und keine Forks zum Zeitpunkt des Verfassens –, das wörtliche Kopien der verwundbaren und gepatchten file_validation.py enthält und beide mit denselben Eingaben ausführt.

Seine Lesart von 0.1.4 ist diese: validate_write_path() ermittelte savePath mit realpath und expanduser, wies eine kurze Sperrliste von Orten zurück (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) und entfernte Verzeichnisbestandteile aus dem übergebenen Dateinamen. Es hat den aufgelösten Pfad nie auf ein Basis- oder Arbeitsverzeichnis beschränkt. Eine Blocklist sensibler Dateinamen – .bashrc, .zshrc, authorized_keys, id_rsa – wurde bei Lesezugriffen durchgesetzt, bei Schreibzugriffen jedoch nicht.

Das Repository zeigt drei Schreibvorgänge, die dies ermöglicht: einen absoluten Pfad, der überhaupt keine Traversierung benötigt, eine relative ../../-Umgehung und einen Dotfile-Namen, den der Lesepfad abgelehnt hätte. Alle drei landen in einem temporären Verzeichnis, das das Skript erstellt, und seine Beispielausgabe zeigt dropped_by_absolute_path.sh, dropped_by_traversal.sh und eine .bashrc unter einem Köder-Home-Verzeichnis; das echte Home-Verzeichnis wird nie berührt. Version 0.1.5 ergänzt die fehlende Grenze: ein Basisverzeichnis, das aus $AWS_TRANSFORM_MCP_WRITE_DIR oder dem Startarbeitsverzeichnis des Servers übernommen wird, unterhalb dessen jeder aufgelöste Schreibvorgang liegen muss, plus die Dateinamen-Blockliste, die auf den endgültigen aufgelösten Schreibpfad angewendet wird. Der korrigierte Validator meldet „Write path must be within the working directory“ bei allen drei.

Keines dieser Details steht in dem Sicherheitshinweis, und das Repository behauptet nicht, dass es von dort stammt. Betrachten Sie die Denylist, die Prüfung auf schreibgeschützte Dateinamen und die Korrektur des Basisverzeichnisses als Rekonstruktion aus dem Quellcode, nicht als zweiten offiziellen Befund. Was das Repository über den Sicherheitshinweis hinaus ergänzt, ist eine Darstellung davon, wer den Pfad liefern kann: Weil es die Aufgabe des Servers ist, Job- und Task-Inhalte in den Kontext eines Assistenten zu ziehen, muss die Partei, die savePath auswählt, nicht die Person an der Tastatur sein. Ein Assistent, der durch nicht vertrauenswürdige Inhalte gesteuert wird, die er über dasselbe Tool abgerufen hat, kann diese Entscheidung treffen. Das ist das Argument des Repositorys aus dem Code und dem Design des Tools, keine Behauptung von Amazon; Amazons undefinierter „kontextabhängiger Akteur“ ist damit vereinbar und geht nicht darüber hinaus.

Sieben Wochen zwischen dem Patch und dem Bulletin

Die Korrektur kam nicht mit der Ankündigung. Die Release-Historie des Python Package Index – Erstanbieter-Metadaten aus der Registry, über die das Paket ausgeliefert wird – datiert 0.1.4 auf den 20. Mai 2026 und 0.1.5 auf den 17. Juni 2026, sieben Wochen bevor Bulletin 2026-075 am 5. August veröffentlicht wurde. Auf dem Index gibt es überhaupt keine 0.1.0-Datei; das früheste veröffentlichte Artefakt innerhalb des betroffenen Bereichs ist 0.1.1, hochgeladen am 9. Mai 2026. Ein Entwickler, der vom Index installierte, konnte daher nur zwischen dem 9. Mai und dem 17. Juni einen verwundbaren Build erhalten, und wer Releases verfolgte, war Mitte Juni bereits auf gepatchtem Code.

Amazon gibt nicht an, wann es von dem Problem erfuhr, wann der Bericht einging oder warum das Release, das es schloss, veröffentlicht wurde. Die einzige im Datensatz genannte Person ist Drew Raines, der sowohl im Bulletin als auch in der GitHub-Advisory „für die Zusammenarbeit an diesem Problem im Rahmen des koordinierten Offenlegungsprozesses für Probleme“ gedankt wird. GHSA-66mr-jr63-2jgw wurde am 5. August 2026 im Repository awslabs/mcp von Amazon veröffentlicht, am selben Tag wie das Bulletin; der CVE-Datensatz wurde um 13:44 UTC reserviert und um 19:33 UTC desselben Tages veröffentlicht.

Damit steht das Datum der Korrektur fest, der Grund dafür nicht. Eine gepatchte Version, die sieben Wochen vor dem Sicherheitshinweis in der Registry steht, passt zu einer stillen Korrektur mit anschließender koordinierter Offenlegung – aber das ist eine Schlussfolgerung aus zwei Zeitstempeln, und keines der beiden Dokumente sagt das.

Was die Aktenlage belegt – und was nicht

Das Archiv bewertet diesen Eintrag mit A – gut dokumentiert, Primärquellen stimmen überein – und kennzeichnet ihn nicht als strittig. Es führt ihn als Forschungsdatensatz, als eine Schwachstellenfeststellung statt eines Deployment-Vorfalls, ohne dokumentierten Schaden in der realen Welt. Die Bewertung bezieht sich auf die Qualität der Dokumentation, und angesichts der geprüften Belege hält sie stand: Das Bulletin, der GitHub-Advisory und der CVE-Eintrag sind drei von Amazon veröffentlichte Dokumente, die bei Produkt, Versionen, Fix und Anerkennung übereinstimmen.

• Bestätigt. Amazon veröffentlichte am 5. August 2026 das Bulletin 2026-075-AWS zu CVE-2026-18953, einem CWE-22-Path-Traversal in der get_resource zugehörigen savePath-Verarbeitung in awslabs.aws-transform-mcp-server 0.1.0 bis 0.1.4, behoben in 0.1.5, ohne serverseitigen oder rein konfigurationsbasierten Workaround, da der anfällige Pfad in der Standardkonfiguration liegt.

• Festgestellt. Die Bewertungen und ihre Abweichung: 8,6 High von Amazon als CVE-Nummerierungsstelle, 8,8 High von NIST als primärer NVD-Score, 6,3 Medium nach CVSS v4.0 und die SSVC-Entscheidung von CISA vom 6. August, dass keine Ausnutzung und kein automatisierbarer Pfad beobachtet worden waren.

• Festgestellt. Die Veröffentlichungsdaten auf dem Python Package Index und die Danksagung an Drew Raines für die koordinierte Offenlegung.

• Aus dem Quellcode von einem Dritten abgeleitet. Die Deny-List, die schreibgeschützte Dateinamen-Blockliste, das fehlende Basisverzeichnis und die _ALLOWED_WRITE_BASE-Korrektur stammen alle aus dem ronamosa-Proof-of-Concept-Repository, dessen mitgelieferte Kopien der beiden Validator-Versionen jeder diffen kann.

• Aus Zeitstempeln und Design abgeleitet. Dass 0.1.5 ein bewusstes Sicherheits-Release war und dass ein durch nicht vertrauenswürdige Inhalte gesteuerter Assistent den feindlichen Pfad bereitstellen könnte. Amazon sagt weder das eine noch das andere.

• Nicht nachgewiesen. Jegliche Ausnutzung in freier Wildbahn. Die CISA-Angabe „Exploitation: none“ ist auf den 6. August datiert, zwei Tage bevor der öffentliche Proof-of-Concept erschien, daher bezieht sie sich auf diesen Zeitpunkt und nicht auf irgendetwas danach. Es wurden weder eine Zahl betroffener Nutzer noch eine Kundenbenachrichtigung oder Telemetrie veröffentlicht.

• Nicht belegt. Unabhängige Berichterstattung. Kein Mainstream-Medium scheint über diese CVE berichtet zu haben. Der öffentliche Datensatz besteht aus Amazons drei Dokumenten, den Anreicherungen dieser Dokumente durch NIST und CISA, Tracker-Seiten, die den Datensatz wiedergeben, und dem einen kleinen, oben beschriebenen Proof-of-Concept-Repository.

Was sich geändert hat und was zu prüfen ist

Amazons Abhilfe ist ein Versionssprung und sonst nichts: Aktualisieren Sie auf 0.1.5 oder später, und „stellen Sie sicher, dass jeglicher geforkte oder abgeleitete Code gepatcht wird, um die neuen Korrekturen zu übernehmen.“ Der zweite Satzteil ist derjenige, der mitwandert. Der Server ist Open Source, und ein Fork, der den Validator 0.1.4 eingebunden hat, erbt die Schwachstelle, ohne den Sicherheitshinweis zu erben; das Bulletin bittet Betreiber abgeleiteten Codes, die Änderung darin nachzuziehen, was heißt, dass die Upstream-Veröffentlichung keine Kopie erreicht, die jemand anderes wartet.

Das Proof-of-Concept-Repository schlägt etwas vor, was der Sicherheitshinweis ablehnt. Betreiber, die nicht sofort aktualisieren können, sollten den Server – so heißt es dort – mit einem auf ein dediziertes leeres Verzeichnis gesetzten Arbeitsverzeichnis betreiben und jede Datei, in die er schreiben kann, als kompromittiert behandeln. Die Position von Amazon ist strenger: Es gibt überhaupt keine serverseitige oder rein konfigurationsbasierte Problemumgehung. Auch nach Darstellung des Repositories selbst ist dieser Vorschlag dürftig, da der anfällige Code Schreibvorgänge von vornherein nie auf das Arbeitsverzeichnis beschränkt hat. Wo die beiden voneinander abweichen, gilt die Anweisung des Herstellers, ausschließlich zu aktualisieren.

Das Nützliche an diesem Datensatz ist nicht seine Bewertung. Es ist seine Form: ein lokaler MCP-Server, ein Artefakt-Download mit einem vom Aufrufer angegebenen Ziel und keine Grenze zwischen den beiden. Die Prüfung, die zählt, ist nicht das Datum des Bulletins, sondern die gepinnte Version — 0.1.5 oder später, und dieselbe Änderung, die in jeden Fork übernommen wurde, der den Validator kopiert hat.