CVE-2026-18953: El Transform MCP Server de AWS no tenía límite de escritura

Amazon publicó el boletín de seguridad 2026-075-AWS el 5 de agosto de 2026 para CVE-2026-18953, una vulnerabilidad de recorrido de rutas en la herramienta get_resource de awslabs.aws-transform-mcp-server, el servidor de código abierto Model Context Protocol que se ejecuta en la propia máquina del desarrollador para que un asistente de IA pueda controlar trabajos de AWS Transform y recuperar sus artefactos. Las versiones 0.1.0 a 0.1.4 no restringían adecuadamente los nombres de ruta, y el parámetro savePath podía escribir archivos fuera del directorio de trabajo previsto — lo que el aviso de GitHub en el repositorio de Amazon indica que «podría dar lugar a la ejecución de código local». Amazon le asignó 8,6, Alta. La corrección es la versión 0.1.5, y no existe ninguna solución alternativa solo del lado del servidor ni solo de configuración, porque la ruta de código vulnerable está presente en la configuración predeterminada. Ninguna fuente pública ha registrado que alguien la haya explotado. El registro completo, con sus calificaciones de gravedad y confianza, se encuentra en el Orca AI Incident Archive junto con los incidentes de MCP y de tiempo de ejecución de agentes registrados en el mismo mes.

Un servidor MCP que escribe donde trabaja el desarrollador

Los servidores del Model Context Protocol son la capa que proporciona herramientas invocables a un asistente, y este es deliberadamente local. El boletín de Amazon lo describe como «un servidor MCP de código abierto que se ejecuta localmente en la máquina de un desarrollador y permite que asistentes impulsados por IA interactúen con AWS Transform para ejecutar trabajos de transformación de código y recuperar sus artefactos». Su descripción de paquete en el Python Package Index indica que expone el ciclo de vida de Transform mediante 19 herramientas, gestionando espacios de trabajo de transformación, trabajos, conectores, tareas con intervención humana, artefactos y chat, y abarca la modernización de mainframes, la migración de VMware, la modernización de .NET y transformaciones de código personalizadas.

Esa ubicación es lo que hace que el fallo importe. Un servidor en la propia infraestructura de un proveedor que maneja mal un nombre de archivo corrompe el almacenamiento del proveedor. Este se ejecutaba como el desarrollador, en el directorio home del desarrollador, junto a su configuración de shell y sus claves SSH, y el impacto que describe Amazon no es una descarga corrupta, sino "ejecución de código local". Todas las puntuaciones asociadas al CVE coinciden en un punto: el vector de ataque es local, no de red.

La herramienta nombrada en el aviso es la que trae un artefacto de trabajo al disco. get_resource toma un savePath que indica dónde debería quedar el archivo. El fallo es que nada impedía que esa ruta apuntara a otro lugar.

¿Qué tan grave, y según la aritmética de quién?

Hay tres puntuaciones asociadas a este CVE y no coinciden. Amazon, que asignó el CVE como autoridad de numeración, la puntúa con 8,6 Alta en CVSS v3.1 con el vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — local, baja complejidad, no se requieren privilegios, se requiere interacción del usuario, alcance cambiado, alto impacto en la confidencialidad, integridad y disponibilidad. La entrada de NIST en la National Vulnerability Database contiene su propia puntuación primaria v3.1 de 8,8 en un vector diferente, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H: se requieren privilegios bajos, no se requiere interacción del usuario. Ambas se sitúan en la banda Alta. El desacuerdo tiene que ver con las precondiciones — si el actor ya necesita una posición establecida y si hay que persuadir a una persona — no con cuán grave es el resultado.

La puntuación CVSS v4.0 de Amazon para el mismo CVE es 6,3, Media, según 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. Lea las métricas de impacto: nada en el propio sistema vulnerable, todo alto en el sistema subsiguiente. Esa es la forma de un traversal que se sale de los límites de la propia herramienta: el daño se produce en todo aquello que la herramienta pueda alcanzar, por lo que queda en la columna del subsistema y el sistema vulnerable puntúa cero.

El enriquecimiento del CVE por parte de CISA, con fecha del 6 de agosto de 2026, registra una decisión SSVC de Explotación: ninguna, Automatizable: no, Impacto técnico: total. El registro de NVD se modificó por última vez el 23 de octubre de 2026 y aún presenta tanto el 8.6 como el 8.8 uno al lado del otro. Ninguno de los dos documentos considera incorrecto al otro.

Qué hacía el código vulnerable y qué cambió en 0.1.5

La descripción que hace Amazon del mecanismo es una sola frase y es cuidadosa: la herramienta «no restringía adecuadamente los nombres de ruta», lo que podría permitir que «un actor dependiente del contexto» «escribiera archivos arbitrarios fuera del directorio de trabajo previsto mediante el parámetro savePath». El aviso no define al actor, no dice qué desencadena la escritura y no describe cómo se ve un exploit exitoso. Solo dice que el resultado «podría dar lugar a ejecución de código local».

La descripción pública más detallada del mecanismo no es de Amazon. Es un pequeño repositorio de prueba de concepto, ronamosa/CVE-2026-18953, publicado en GitHub el 8 de agosto de 2026 bajo Apache-2.0 —dos commits, sin estrellas ni bifurcaciones en el momento de escribir esto— que incluye copias literales del file_validation.py vulnerable y parcheado, y somete ambos a las mismas entradas.

Su lectura de 0.1.4 es esta: validate_write_path() resolvía savePath con realpath y expanduser, rechazaba una breve lista de denegación de ubicaciones (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd), y eliminaba los componentes de directorio del nombre de archivo proporcionado. Nunca confinaba la ruta resuelta a ningún directorio base ni de trabajo. Una lista de bloqueo de nombres de archivo sensibles — .bashrc, .zshrc, authorized_keys, id_rsa — se aplicaba a las lecturas pero no a las escrituras.

El repositorio demuestra tres escrituras que esto permite: una ruta absoluta que no necesita recorrido alguno, un escape relativo ../../ y un nombre de dotfile que la ruta de lectura habría rechazado. Las tres terminan dentro de un directorio temporal que crea el script, y su salida de ejemplo muestra dropped_by_absolute_path.sh, dropped_by_traversal.sh y un .bashrc bajo un directorio home señuelo; nunca se toca el directorio home real. La versión 0.1.5 añade el límite que faltaba: un directorio base tomado de $AWS_TRANSFORM_MCP_WRITE_DIR o el directorio de trabajo de inicio del servidor, bajo el cual debe quedar toda escritura resuelta, además de la lista de bloqueo de nombres de archivo aplicada a la ruta de escritura resuelta final. El validador corregido lanza «La ruta de escritura debe estar dentro del directorio de trabajo» contra las tres.

Ninguno de esos detalles aparece en el aviso, y el repositorio no afirma que provinieran de allí. Considera la lista de denegación, la comprobación del nombre de archivo de solo lectura y la corrección del directorio base como una reconstrucción a partir del código fuente, no como un segundo hallazgo oficial. Lo que el repositorio sí añade más allá del aviso es una explicación de quién puede proporcionar la ruta: dado que la tarea del servidor es llevar contenido de trabajos y tareas al contexto de un asistente, la parte que elige savePath no tiene por qué ser la persona que está frente al teclado. Un asistente dirigido por contenido no confiable que obtuvo mediante la misma herramienta puede tomar la decisión. Ese es el argumento del repositorio basado en el código y en el diseño de la herramienta, no una afirmación de Amazon; el "actor dependiente del contexto" indefinido de Amazon es coherente con ello y no va más allá.

Siete semanas entre el parche y el boletín

La corrección no llegó con el anuncio. El historial de versiones del Python Package Index —metadatos de primera parte del registro a través del cual se distribuye el paquete— sitúa la 0.1.4 en el 20 de mayo de 2026 y la 0.1.5 en el 17 de junio de 2026, siete semanas antes de que se publicara el boletín 2026-075 el 5 de agosto. No hay ningún archivo 0.1.0 en el índice; el artefacto publicado más antiguo dentro del intervalo afectado es la 0.1.1, subida el 9 de mayo de 2026. Por lo tanto, un desarrollador que instalara desde el índice solo podría haber recibido una compilación vulnerable entre el 9 de mayo y el 17 de junio, y cualquiera que siguiera las versiones ya estaba usando código parcheado a mediados de junio.

Amazon no dice cuándo se enteró del problema, cuándo llegó el informe ni por qué se publicó la versión que lo resolvió. La única persona nombrada en el registro es Drew Raines, a quien se agradece tanto en el boletín como en el aviso de GitHub «por colaborar en este problema mediante el proceso coordinado de divulgación de problemas». GHSA-66mr-jr63-2jgw se publicó en el repositorio awslabs/mcp de Amazon el 5 de agosto de 2026, el mismo día que el boletín; el registro CVE se reservó a las 13:44 UTC y se publicó a las 19:33 UTC ese día.

Así que la fecha de la corrección está establecida, pero el motivo no. Una versión parcheada que lleva siete semanas en el registro antes del aviso encaja con una corrección discreta seguida de una divulgación coordinada — pero eso es una inferencia a partir de dos marcas de tiempo, y ninguno de los dos documentos lo afirma.

Lo que el expediente establece, y lo que no

El archivo califica esta entrada con A —bien documentada, las fuentes primarias coinciden— y no la marca como disputada. La registra como un registro de investigación, un hallazgo de vulnerabilidad en lugar de un incidente de despliegue, sin daños reales registrados. La calificación se refiere a la calidad de la documentación y, según la evidencia revisada, se mantiene: el boletín, el aviso de GitHub y el registro CVE son tres documentos publicados por Amazon que coinciden en el producto, las versiones, la corrección y el crédito.

• Confirmado. Amazon publicó el boletín 2026-075-AWS el 5 de agosto de 2026, que cubre CVE-2026-18953, un recorrido de ruta CWE-22 en el manejo de get_resource de savePath en awslabs.aws-transform-mcp-server 0.1.0 a 0.1.4, corregido en 0.1.5, sin solución alternativa del lado del servidor ni que consista únicamente en configuración, ya que la ruta vulnerable está en la configuración predeterminada.

• Establecido. Las puntuaciones y su divergencia: 8,6 Alto de Amazon como autoridad de numeración de CVE, 8,8 Alto de NIST como puntuación principal de NVD, 6,3 Medio en CVSS v4.0, y la decisión SSVC de CISA del 6 de agosto de que no se había observado explotación ni una ruta automatizable.

• Establecido. Las fechas de publicación en el Python Package Index y el reconocimiento a Drew Raines por la divulgación coordinada.

• Inferido del código fuente, por un tercero. La lista de denegación, la lista de bloqueo de nombres de archivo de solo lectura, la ausencia del directorio base y la corrección de _ALLOWED_WRITE_BASE provienen todas del repositorio de prueba de concepto de ronamosa, cuyas copias vendorizadas de las dos versiones del validador cualquiera puede comparar.

• Inferido a partir de las marcas de tiempo y el diseño. Que la 0.1.5 fue una versión de seguridad deliberada, y que un asistente guiado por contenido no confiable podría proporcionar la ruta hostil. Amazon no afirma ninguna de las dos cosas.

• No establecido.Cualquier explotación en el mundo real. La «Explotación: ninguna» de CISA está fechada el 6 de agosto, dos días antes de que apareciera la prueba de concepto pública, por lo que se refiere a ese momento y no a nada posterior. No se ha publicado ningún recuento de usuarios afectados, notificación a clientes ni telemetría.

• No establecido. Cobertura independiente. Ningún medio dominante parece haber cubierto este CVE. El registro público lo componen los tres documentos de Amazon, los enriquecimientos de NIST y CISA de estos, las páginas de seguimiento que reiteran el registro y el pequeño repositorio de prueba de concepto descrito anteriormente.

Qué cambió y qué comprobar

El remedio de Amazon es un aumento de versión y nada más: actualizar a 0.1.5 o posterior y «asegurarse de que cualquier código bifurcado o derivado esté parcheado para incorporar las nuevas correcciones». La segunda cláusula es la que trasciende. El servidor es de código abierto, y una bifurcación que incorporó el validador 0.1.4 como código vendorizado hereda el fallo sin heredar el aviso de seguridad; el boletín pide a los operadores de código derivado que trasladen el cambio a su código, lo que equivale a decir que la versión upstream no llega a una copia que mantiene otra persona.

El repositorio de prueba de concepto sugiere algo que el aviso se niega a sugerir. Los operadores que no pueden actualizar de inmediato, según este, deberían ejecutar el servidor con su directorio de trabajo configurado como un directorio vacío dedicado y tratar como comprometido cualquier archivo en el que este pueda escribir. La postura de Amazon es más estricta: no existe ninguna solución alternativa del lado del servidor ni que consista únicamente en configuración. Según el propio repositorio, esa sugerencia también es endeble, ya que el código vulnerable nunca limitó las escrituras al directorio de trabajo en primer lugar. Donde ambas partes discrepan, prevalece la instrucción del proveedor de actualizar únicamente.

Lo útil de este registro no es su puntuación. Es su forma: un servidor MCP local, una descarga de artefacto con un destino proporcionado por quien llama, y ningún límite entre ambos. La comprobación que importa no es la fecha del boletín, sino la versión fijada: 0.1.5 o posterior, y el mismo cambio incorporado en cualquier fork que haya copiado el validador.