En 2026, una empresa de seguridad evaluó Baseten, una plataforma de IA valorada en 13 mil millones de dólares. En solo 25 minutos, obtuvieron acceso de administrador a sus repositorios internos de código central. Este proceso de intrusión casi sin obstáculos no utilizó ni una sola vulnerabilidad de software de principio a fin.
Revisar historiales de imágenes públicas para robar permisos máximos del sistema
Strix es una empresa de seguridad que desarrolla agentes de penetración autónomos. Antes de decidir transferir los datos, realizaron un escaneo de rutina sin credenciales a Baseten. El punto de partida del reconocimiento fue un registro de imágenes de contenedores, algo similar a un contenedor de carga para paquetes de software. Un proyecto dentro del registro era completamente público. Cualquiera podía listar archivos sin contraseña e incluso solicitar un token anónimo para descargar datos.
El defecto fatal quedó impreso en un registro llamado “historial de compilación”. Cuando Docker empaqueta software, graba cada comando de compilación en el historial, como un recibo con marca de tiempo. Un comando de configuración mostró una variable llamada GITHUB_TOKEN directamente en texto sin formato.
Los desarrolladores usaron este token como sustituto de contraseña, con la intención de facilitar el proceso de extracción de código para el sistema. La documentación oficial advierte explícitamente que los parámetros de compilación quedarán registrados. Sin embargo, por conveniencia, los ingenieros escribieron la variable directamente en el comando. Los estándares de seguridad cedieron ante la velocidad de desarrollo y las líneas rojas conocidas de la industria se cruzaron con facilidad.
Imagen: El token en el historial de compilación de Docker y la información de la cuenta devuelta por GitHub. Fuente: Strix Post-mortem
Un token sin rotar durante tres años entrega la gestión del repositorio central
Siguiendo esta pista expuesta, Strix adquirió un token activo perteneciente a una organización interna de Baseten. Este token les otorgó acceso a siete repositorios internos. Tres de estas áreas de alto riesgo incluían permisos de administrador y la máxima autoridad para enviar código. Estos tres nodos formaban la cadena de suministro completa desde el desarrollo del código hasta la implementación para el cliente.
Una vez que el repositorio principal del producto se ve comprometido, los intrusos pueden inyectar silenciosamente lógica maliciosa en el código que ejecuta modelos de IA. El repositorio de GitOps es la autopista directa al entorno de producción; incluso contenía subdirectorios categorizados por nombres de clientes. Tomar el control de la cadena de herramientas de distribución equivale a abrir una puerta trasera en las computadoras de todos los desarrolladores que utilizan esa herramienta.
La marca de tiempo registrada se detuvo el 3 de marzo de 2023. Hasta su descubrimiento en julio de 2026, este token funcionó sin ningún tipo de impedimento. El poder destructivo de una credencial que sigue activa tres años después supera con creces al de un troyano cuidadosamente programado. Las empresas gastan fortunas en firewalls para bloquear ataques externos, pero hacen la vista gorda ante permisos internos que no se han actualizado en años.
Imagen: Alcance del token y organización a la que pertenece devuelto por GitHub. Fuente: Strix Post-mortem
Una lección de $13 mil millones que una verificación local podría haber evitado
Al recibir el informe, el equipo de seguridad de Baseten respondió rápidamente, rotando el token y bloqueando el proyecto público a la tarde siguiente. La compañía valorada en 13 mil millones de dólares demostró la decisión necesaria para evitar que el desastre se propagara. Las credenciales ya se habían filtrado en el historial de compilación. Modificar el archivo de compilación en ese momento no podía recuperar las imágenes descargadas. El único remedio era revocar el token en origen.
La causa directa del incidente fue que los ingenieros usaron el comando git config para escribir una URL con el token en la configuración global. La práctica habitual es usar una credencial encriptada montada temporalmente para la autenticación. Los tokens deben ser de “leer y quemar”, y nunca deben dejarse en discos duros ni en registros históricos.
Prevenir este nivel de filtración de credenciales solo requiere ejecutar un simple filtro de coincidencia de palabras clave localmente antes de que el código se lance a producción. Cuando faltan pasos de revisión obligatoria en el proceso de desarrollo, los errores básicos viajarán sin obstáculos directamente al entorno de producción.
El colapso de la defensa del sistema se origina en los hábitos diarios de los ingenieros
Las áreas donde los defensores bajan la guardia fácilmente suelen ser rincones históricos olvidados. Los equipos se centran en las aplicaciones principales y los repositorios de código más recientes, a menudo olvidando una imagen de contenedor que superó su período de mantenimiento hace mucho tiempo. Incluso si escanea los archivos de contenido de la imagen, omitir su historial de compilación permite que ese token letal siga suelto.
La intrusión explotó tres vulnerabilidades configuradas íntegramente por humanos: un repositorio de lectura pública, parámetros mal registrados y un token sin actualizar durante tres años. No hubo ninguna tecnología desconocida devastadora, solo puertas que los propios guardianes dejaron abiertas.
Los puntos débiles de seguridad en la cadena de suministro de IA a menudo se ocultan en la configuración y los hábitos de higiene más básicos de los ingenieros. La prueba empírica de tomar las cartas de triunfo de una empresa de 13 mil millones de dólares en 25 minutos establece la línea base de seguridad más clara: ni siquiera la protección del sistema más costosa puede reemplazar un comando de inspección omitido.
Enlaces de referencia:
- Strix Post-mortem
