01 · Contexto
Qué está ocurriendo
El 23 de octubre, AWS publicó dos vulnerabilidades de Multi Model Server, herramienta abierta para servir modelos de aprendizaje automático. El repositorio estaba archivado desde el 20 de noviembre de 2025. El boletín identifica problemas en la extracción de archivos de modelos y en sus descargas, con posibles escrituras fuera del directorio previsto y solicitudes hacia destinos no esperados. La interfaz de gestión no requiere autenticación.
AWS indica que todas las versiones publicadas, hasta la 1.1.11, están afectadas y que no existe ni se planifica una versión corregida. Recomienda dejar de usar MMS y migrar a una solución mantenida. La restricción temporal de la interfaz de gestión depende de la configuración: no siempre puede separarse del servicio de inferencia. No se trata, por tanto, de un producto que haya terminado su soporte esta semana.
02 · Impacto
Por qué importa
Análisis editorial: la diferencia respecto de una alerta habitual es que esperar una actualización no resuelve el problema. Un servicio puede seguir respondiendo correctamente y, al mismo tiempo, haber perdido una ruta sostenible de mantenimiento. Esto afecta también a imágenes de contenedor, demostraciones y componentes incorporados indirectamente en otra aplicación. El inventario debería identificar el software realmente ejecutado, no solo el nombre comercial del sistema. Una medida de red puede reducir quién alcanza un componente, pero no demuestra que el componente sea seguro ni que sus entradas sean confiables. La respuesta necesita un responsable de migración, una fecha y pruebas que acrediten la continuidad del servicio sustituto.
03 · Recomendaciones
Qué conviene hacer
- Buscar MMS en repositorios, imágenes, manifiestos y entornos de inferencia propios autorizados. Registrar versión, origen, dueño del servicio y exposición. No asumir que una dependencia dejó de utilizarse porque su repositorio fue archivado; comprobar qué procesos y artefactos siguen activos.
- Priorizar instalaciones accesibles desde redes no confiables. Evaluar las medidas temporales descritas por AWS según la topología real, sin aplicarlas a ciegas. Mantener solo los accesos indispensables y documentar el riesgo restante. Evitar presentar una restricción de conectividad como cierre definitivo del hallazgo.
- Preparar una sustitución soportada con criterios de aceptación: compatibilidad de modelos, resultados esperados, latencia, consumo, autenticación y operación. Probar cargas representativas y fallas antes de transferir tráfico. Conservar una estrategia de recuperación que no dependa indefinidamente del componente vulnerable.
- Revisar además el proceso de aceptación de dependencias. Definir quién detecta el fin de soporte y cómo se programa el reemplazo antes de una emergencia. Cerrar la actividad con evidencia del retiro de MMS, no solamente con la instalación de una herramienta nueva en paralelo.