AWS corrige un fallo de audiencia OAuth en su servidor API MCP
CVE-2026-115413 afectaba AWS API MCP Server 1.3.0–<1.6.0 con HTTP y OAuth. AWS corrigió la validación en 1.6.0.
AWS corrigió CVE-2026-115413 en AWS API MCP Server, un servidor de Model Context Protocol (MCP) que permite a asistentes conectarse a servicios de AWS mediante comandos de AWS CLI. El fallo estaba en la comprobación de tokens OAuth cuando el servidor se configuraba con el transporte streamable HTTP: validaba firma, emisor y caducidad, pero no que el token estuviera destinado a esa aplicación concreta. La corrección está en la versión 1.6.0; el rango afectado comienza en 1.3.0 y termina antes de esa versión.
El campo que faltaba validar es la audience —la audiencia o destinatario del token, normalmente representada por la claim aud—. Un proveedor de identidad puede emitir tokens distintos dentro del mismo tenant para varias aplicaciones. Si el servidor acepta que un token emitido para una de ellas sirva también para otra, pierde una frontera entre clientes aunque la firma criptográfica sea correcta. Autenticidad no equivale a autorización para el destino adecuado; en esta vulnerabilidad, esa diferencia era el centro del problema.
-SecureCrew dice: revisar la firma y olvidarse del destinatario es como validar que la llave sea de verdad y no mirar qué puerta abre.-
El advisory de GitHub concreta una condición relevante: el despliegue debe usar streamable HTTP con autenticación OAuth, y quien llama al servidor debe tener un token emitido para otra aplicación del mismo tenant que pueda presentar al servicio. El caso descrito no es “cualquiera desde Internet, sin credenciales, entra en AWS”. Es un bypass de audiencia con un token válido, cuyo efecto depende además de que el servidor sea alcanzable por ese llamante y de los permisos que tenga la identidad configurada en el host.
Si la llamada llega a procesarse, el servidor puede ejecutar acciones contra AWS con las credenciales que el operador le asignó. El impacto queda limitado por esos permisos, así que un servidor con acceso de lectura a un bucket no equivale a uno que pueda administrar cuentas, crear roles o modificar redes. El riesgo práctico está en la combinación de un endpoint accesible, tokens cruzados entre aplicaciones y una política de IAM más amplia de lo necesario. AWS no afirma que haya explotación observada.
Versiones y corrección
AWS y el aviso de seguridad del repositorio sitúan el rango vulnerable en 1.3.0 hasta cualquier versión anterior a 1.6.0. La versión 1.6.0 corrige el fallo y exige configurar el destinatario esperado cuando se usa OAuth. Quienes mantienen un fork o una variante derivada deben comprobar si incorporaron la misma validación; actualizar el paquete oficial no modifica automáticamente el código copiado dentro de otro proyecto.
En el transporte OAuth, AWS recomienda configurar AUTH_AUDIENCE o AUTH_CLIENT_ID, según las claims que expida el proveedor de identidad. No son valores intercambiables en todos los proveedores: algunos tokens de acceso no incluyen una claim aud, y el advisory pone Amazon Cognito como ejemplo para el que puede corresponder validar el identificador del cliente. Hay que confirmar el formato del token real y la configuración de la aplicación, no copiar un valor de otra integración.
-SecureCrew dice: “mismo tenant” no quiere decir “misma aplicación”; si todo el vecindario comparte pase, el torno es decorativo.-
Quien no pueda actualizar de inmediato puede cambiar temporalmente al transporte stdio, que es la opción predeterminada del servidor y evita el camino de streamable HTTP afectado. Es una mitigación de configuración, no una reparación del código: hay que valorar si el proceso puede ejecutarse localmente y si el cambio encaja con la arquitectura de los clientes. Volver a exponer HTTP sin la validación corregida reabre la condición que AWS describe.
Qué comprobar en una integración
Empieza por inventariar las instancias que ejecutan el paquete y separar las que usan stdio de las que publican un endpoint HTTP con OAuth. El número de versión por sí solo no identifica la exposición: una versión afectada sin ese transporte y esa autenticación no cumple la condición descrita; una copia derivada puede mantener el defecto aunque el entorno principal se haya actualizado. Para cada endpoint, revisa quién puede alcanzarlo y qué aplicación puede obtener tokens del proveedor configurado.
Después de actualizar, valida que la audiencia o el identificador de cliente esperado coinciden con la aplicación correcta y prueba el flujo con tokens emitidos para clientes distintos, en un entorno de verificación controlado. Reduce también las políticas IAM del host al conjunto de acciones que el servidor realmente necesita. La corrección evita aceptar el token equivocado; los permisos mínimos reducen el daño si otro control falla. Son dos controles distintos, y conviene no usar uno como excusa para saltarse el otro.
-SecureCrew dice: los permisos de AWS no deberían ser la sorpresa que aparece después de arreglar OAuth; mejor que sean aburridos desde el principio.-
Diccionario de la Crew
MCP — Protocolo que permite a aplicaciones cliente conectarse con herramientas o fuentes externas.
OAuth — Protocolo de autorización que permite obtener y presentar tokens de acceso.
Audience (aud) — Destinatario previsto de un token; el servidor debe comprobar que coincide con la aplicación que recibe la petición.
stdio — Comunicación entre procesos mediante entrada y salida estándar, en vez de un endpoint de red.
