CVE-2026-18953 — PoC

Beliebiges Schreiben von Dateien in awslabs.aws-transform-mcp-server (AWS Transform MCP-Server) über den savePath-Parameter des get_resource-Tools.

Zusammenfassung

get_resource(resource="artifact" | "asset", ...) lädt eine Datei von einer präsignierten S3-URL herunter und speichert sie — wenn der Aufrufer savePath / fileName übergibt — über folgenden Ablauf auf der lokalen Festplatte:

tools/get_resource.py  ->  tool_utils.download_s3_content()
                        ->  file_validation.validate_write_path()

In <= 0.1.4 führt validate_write_path() nur Folgendes aus:

1. Löst save_path mit os.path.realpath(os.path.expanduser(...)) auf.
2. Lehnt eine kurze Deny-Liste von Verzeichnissen ab (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd).
3. Entfernt Verzeichnisbestandteile aus file_name mittels os.path.basename().

Es beschränkt das aufgelöste Verzeichnis nie auf ein Basis-/Arbeitsverzeichnis, und BLOCKED_FILENAMES (.bashrc, .zshrc, authorized_keys, id_rsa, …) wird nur bei Lesevorgängen durchgesetzt, nicht bei Schreibvorgängen. Daher kann jeder MCP-Client dieses Servers — einschließlich eines Agents, der indirekt per Prompt-Injection über nicht vertrauenswürdige Job-/Task-/Message-Inhalte manipuliert wurde, die er über genau dieses Tool abruft — savePath auf einen absoluten Pfad, einen ../..-Traversal oder einen sensiblen Dotfile-Namen setzen, und der Server schreibt dort vom Angreifer beeinflusste Bytes. Das ist eine File-Write-Primitive außerhalb des Verzeichnisses, auf das die Downloads nach Ansicht des Betreibers beschränkt sind; das Advisory merkt an, dass dies „zu lokaler Codeausführung führen könnte" (z. B. durch Überschreiben einer Shell-Startdatei).

0.1.5 behebt dies, indem ein explizit auf einer Allow-Liste geführtes Basisverzeichnis hinzugefügt wird (_ALLOWED_WRITE_BASE, übernommen aus $AWS_TRANSFORM_MCP_WRITE_DIR oder dem CWD des Servers beim Start), unter das jeder aufgelöste Schreibpfad fallen muss, und indem BLOCKED_FILENAMES zusätzlich auf den endgültig aufgelösten Schreibpfad angewendet wird.

Vollständiger Root-Cause-Diff: vendor/0.1.4-vulnerable/file_validation.py gegenüber vendor/0.1.5-fixed/file_validation.py (beide unverändert von PyPI / GitHub übernommen, Apache-2.0).

Wie ein realer Angriff aussieht

Ein MCP-Client (Q Developer, Kiro, Claude usw., der mit diesem Server verbunden ist) führt einen Tool-Call wie den folgenden aus:

{
  "name": "get_resource",
  "arguments": {
    "resource": "artifact",
    "workspaceId": "ws-...",
    "jobId": "job-...",
    "artifactId": "art-...",
    "savePath": "/Users/victim/Library/LaunchAgents",
    "fileName": "com.evil.persist.plist"
  }
}

oder, aus einem relativen Sandbox-Verzeichnis heraus:

{ "savePath": "../../../../../../Users/victim/.bashrc", "fileName": "x" }

Da das Tool resource="task"-Antworten als Inhalte beschreibt, die der Agent lesen und darauf reagieren soll, und resource="messages"-Inhalte aus Chat-/Job-Daten stammen, muss ein Workspace-Mitarbeiter (oder eine kompromittierte Upstream-Quelle für Jobs/Nachrichten) keinen Menschen dazu bringen, dies einzutippen — es genügt, einen bereits verbundenen Agenten so zu lenken, dass er get_resource mit einem bösartigen savePath aufruft. Zum Nachweis der Schwachstelle selbst sind keine echten AWS-Anmeldedaten erforderlich, da der Fehler vollständig in der lokalen Pfadbehandlung liegt, die vor und nach dem S3-Abruf erfolgt.

Ausführen des PoC

python3 poc.py

Keine Drittanbieter-Abhängigkeiten, kein AWS-Konto, kein Netzwerkzugriff auf AWS. Das Skript:

1. Übernimmt das echte, unveränderte file_validation.py aus 0.1.4 und 0.1.5+ (siehe vendor/).
2. Startet einen Wegwerf-HTTP-Server, der als Ersatz für die präsignierte S3-URL dient.
3. Bildet download_s3_content() mit exakt dem Kontrollfluss aus dem Upstream-tool_utils.py nach (nur httpx gegen stdlib-urllib ausgetauscht — null Abhängigkeiten, gleiche Logik) und ruft es exakt so auf, wie get_resource es tun würde.
4. Feuert drei bösartige savePath/fileName-Paare — Absolute-Pfad-Escape, relativer ../..-Traversal und ein nur bei Lesevorgängen blockierter Dotfile-Name — gegen den verwundbaren Validator und anschließend gegen den behobenen.

Alles geschieht in einem Wegwerf-Arbeitsverzeichnis per mkdtemp(); das echte $HOME wird niemals angefasst. Beispielausgabe:

=== Target: file_validation.py from 0.1.4-vulnerable ===
  -> Absolute path escape (no traversal needed at all)
     RESULT: VULNERABLE: wrote OUTSIDE sandbox -> .../outside_sandbox/dropped_by_absolute_path.sh
  -> Relative "../../.." traversal out of the sandbox dir
     RESULT: VULNERABLE: wrote OUTSIDE sandbox -> .../outside_sandbox/dropped_by_traversal.sh
  -> Sensitive dotfile name, written inside a decoy $HOME
     RESULT: VULNERABLE: wrote OUTSIDE sandbox -> .../outside_sandbox/decoy_home/.bashrc

=== Target: file_validation.py from 0.1.5-fixed ===
  -> Absolute path escape (no traversal needed at all)
     RESULT: BLOCKED (raised ValueError): Write path must be within the working directory (...)
  -> Relative "../../.." traversal out of the sandbox dir
     RESULT: BLOCKED (raised ValueError): ...
  -> Sensitive dotfile name, written inside a decoy $HOME
     RESULT: BLOCKED (raised ValueError): ...

Behebung

Führe ein Upgrade auf awslabs.aws-transform-mcp-server >= 0.1.5 durch. Für ältere Versionen gibt es keinen serverseitigen Workaround; das Advisory empfiehlt das Upgrade. Betreiber, die nicht sofort upgraden können, sollten den Server mit einem dedizierten, leeren Verzeichnis als CWD ausführen und jede Datei, in die er schreiben kann, als kompromittiert behandeln.

Repo-Struktur

README.md                              — this file
poc.py                                 — self-contained PoC driver
vendor/_loguru_shim.py                 — tiny stand-in for the `loguru` dep (test scaffolding only)
vendor/0.1.4-vulnerable/file_validation.py  — real vulnerable source, from PyPI sdist
vendor/0.1.5-fixed/file_validation.py       — real patched source, from github.com/awslabs/mcp@main