01 · Contexto
Qué está ocurriendo
AWS publicó el 27 de octubre el aviso CVE-2026-115413 para AWS API MCP Server. Las versiones desde 1.3.0 y anteriores a 1.6.0 verificaban firma, emisor y vencimiento de tokens OAuth, pero omitían comprobar para qué aplicación se emitieron. Un token de otra aplicación del mismo tenant podía ser aceptado y permitir llamadas con las credenciales configuradas en el servidor.
La corrección está en la versión 1.6.0. AWS recomienda actualizar y configurar AUTH_AUDIENCE o, para proveedores cuyos tokens no incluyen audiencia, AUTH_CLIENT_ID. El boletín también ofrece el transporte stdio como alternativa temporal al transporte streamable-http cuando no se pueda actualizar inmediatamente. El aviso describe una vulnerabilidad; no demuestra que una instalación particular haya sido comprometida.
02 · Impacto
Por qué importa
Análisis: autenticar al emisor no responde por sí solo quién debe consumir una credencial. La audiencia delimita el servicio para el cual esa credencial es aceptable. Cuando se conectan agentes con herramientas capaces de actuar sobre infraestructura, confundir ambos controles puede trasladar permisos entre aplicaciones que deberían permanecer separadas. El riesgo efectivo depende además de la exposición del servidor, la configuración de identidad y los privilegios disponibles en el host. Una cuenta excesivamente poderosa amplifica el alcance de cualquier fallo de autorización. Por eso, el parche debe acompañarse de una revisión acotada del contexto operativo, sin asumir que todo servidor MCP utiliza este componente o este modo de autenticación.
03 · Recomendaciones
Qué conviene hacer
- Como recomendación, identifique las instancias reales del paquete afectado y su transporte antes de cambiar configuraciones. Revise las versiones desplegadas, incluyendo copias derivadas, y acuerde la actualización con el responsable del servicio. Defina el destinatario esperado desde la configuración legítima de la aplicación; no lo deduzca de un token recibido ni acepte cualquier valor para hacer pasar una prueba. Mantenga respaldo y un procedimiento de reversión compatible con el cambio.
- En un entorno autorizado, pruebe con identidades sintéticas que un token emitido para la aplicación correcta funciona y que uno destinado a otra aplicación es rechazado. Compruebe también vencimiento, emisor y permisos efectivos, sin registrar el token completo en evidencias. Reduzca las credenciales del host al alcance necesario y revise registros de acceso pertinentes. Cierre la intervención con versión, configuración validada y resultados reproducibles, distinguiendo corrección aplicada de investigación de un posible incidente.