AWS publicó el 2 de octubre el boletín de seguridad de CVE-2026-104019, una vulnerabilidad de inyección de comandos en el script de arranque de SageMaker Spaces dentro de SageMaker Unified Studio. En determinadas condiciones, un miembro de un proyecto podía provocar ejecución de código en el Space de otro integrante mediante datos de conexión manipulados, según el boletín oficial de AWS.
El riesgo aumenta cuando está activo Trusted Identity Propagation
El script vulnerable valida las conexiones disponibles de SageMaker al arrancar un Space. Una sanitización insuficiente de determinados detalles de conexión podía permitir que un usuario con permisos de contributor o superiores ejecutara código en el entorno de otro miembro.
En proyectos con Trusted Identity Propagation habilitado, AWS advierte de que el impacto podía llegar al acceso a credenciales temporales del rol de ejecución de otra persona y, desde ahí, a llamadas a servicios compatibles con esa propagación de identidad.
Qué versiones están corregidas
AWS ha desplegado el arreglo en las ramas soportadas. Entre las versiones corregidas figuran 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 y 4.4.3. La rama 4.5.x no está afectada, mientras que varias ramas antiguas ya fuera de soporte permanecen vulnerables y no recibirán una versión corregida.
En SageMaker Unified Studio no es necesario seleccionar manualmente la versión parcheada: los Spaces adoptan el último parche de su rama en el siguiente arranque una vez que la imagen corregida está disponible.
AWS recomienda además comprobar la rama que utiliza cada Space antes de reiniciarlo. Las ramas ya fuera de soporte no reciben el arreglo, por lo que mantener un entorno antiguo exige migrarlo a una rama soportada en lugar de confiar únicamente en un reinicio. Esa distinción es importante para equipos que conservan notebooks o dependencias antiguas por compatibilidad.
No hay workaround: hay que reiniciar los Spaces afectados
AWS indica expresamente que no existe una mitigación alternativa equivalente. Las empresas deben reiniciar los Spaces de las ramas afectadas para que carguen la versión corregida y revisar si mantienen entornos basados en ramas fuera de soporte.
Qué debería revisar una empresa
Además del reinicio, conviene inventariar proyectos con Trusted Identity Propagation, revisar quién tiene permisos de contributor o superiores y comprobar registros de actividad inusual. Si una organización mantiene imágenes derivadas o entornos personalizados, debe confirmar que la corrección se ha incorporado también allí.
Como parte de la misma revisión de seguridad, conviene comprobar el Microsoft Digital Defense Report 2026, el parche crítico de GitLab, las passkeys en Microsoft Entra, la actualización de GitHub CodeQL, el sandbox local de Copilot y la criptografía poscuántica de Cloudflare.
Fotografía: Christina Morillo / Pexels.
