Una empresa de seguridad que evaluaba a Baseten como proveedor de inferencia apuntó un agente de escaneo autónomo a los dominios de la compañía, sin credenciales y sin acceso al código fuente. Unos 25 minutos después tenía en la mano un token de GitHub válido con permisos de administrador sobre repositorios internos. Strix publicó la divulgación el 1 de septiembre, siete semanas después de que Baseten corrigiera el fallo.
Puntos clave
- La credencial quedó escrita en el historial de compilación de una imagen de contenedor el 3 de marzo de 2023 y seguía autenticando cuando se probó en julio de 2026.
- Tenía alcance repo, con permisos de administración y escritura sobre el repositorio principal de producto de Baseten, el repositorio de GitOps que gobierna sus clústeres y su tap de Homebrew.
- El equipo de seguridad de Baseten hizo privado el registro y rotó el token unas 17 horas después del aviso.
Cómo llegó hasta ahí un escaneo
La ejecución empezó con reconocimiento corriente: enumeración de hosts e inspección de registros de certificados. De ahí salió un registro de contenedores Harbor alojado en un subdominio de Baseten. Harbor agrupa las imágenes en proyectos, y uno de los proyectos de esa instancia era público. No hizo falta ningún token para listar sus repositorios, generar un permiso de descarga anónimo y bajarse manifiestos y blobs, entre ellos una imagen llamada baseten/baseten-app.
Un registro expuesto, por sí solo, no dice gran cosa: muchas empresas publican imágenes a propósito. La pregunta es qué contiene la imagen. El primer hallazgo, un par de claves de AWS, resultó inservible: una llamada de identidad en modo lectura devolvió un error de token inválido. El agente siguió adelante, descargó las capas, ejecutó el escáner de código abierto TruffleHog y después leyó la configuración de la imagen, no solo su sistema de archivos.
La credencial estaba en los metadatos, no en un archivo
El token aparecía en el campo created_by del historial de compilación, el registro del comando que generó cada capa. El paso en cuestión había expandido un argumento de compilación GITHUB_TOKEN directamente dentro de una línea RUN para poder descargar dependencias privadas por Git. Docker guarda ese historial en la configuración de la imagen, que se descarga junto con la imagen misma.
Este es el detalle que conviene retener: borrar un archivo con credenciales de una capa no sirve de nada si el historial de compilación conserva una copia. El patrón se agrava cuando la compilación además escribe una URL remota autenticada en la configuración global de Git, dejando una segunda copia.
Una petición de solo lectura a GitHub devolvió un 200 para una cuenta llamada basetenbot, con alcance repo y pertenencia a la organización basetenlabs. Las comprobaciones repositorio por repositorio arrojaron permisos de administración y escritura en tres repositorios, además de lectura y escritura en otros privados, incluidos algunos específicos de clientes. Strix afirma que se detuvo ahí: sin clonar, sin subir código y sin tocar configuraciones, y envió el correo de divulgación.
La respuesta fue rápida
La cronología del informe es inusualmente ajustada para un aviso de este tipo. Strix lo notificó a las 11:10 de la noche del 13 de julio. A la mañana siguiente el proyecto de Harbor ya era privado, aunque el token seguía activo. A las 16:34 del 14 de julio Baseten confirmó el problema como crítico, comunicó que había rotado el token y pidió a los investigadores que borraran de forma segura las imágenes descargadas, algo que estos confirmaron media hora más tarde. Los hallazgos restantes se cerraron el 17 de julio, y Baseten revisó un borrador del texto antes de su publicación.
Por qué las imágenes viejas siguen provocando esto
Baseten, valorada en 13.000 millones de dólares, no es una rezagada en herramientas ni en atención al problema: la propia divulgación señala que la compañía ya opera herramientas de seguridad con IA. El fallo consiste en que un artefacto de compilación de 2023 nunca se trató como parte de la superficie de ataque una vez que el código a su alrededor siguió evolucionando. Cambiar un Dockerfile no altera una imagen que alguien ya descargó, y por eso el paso que importa es revocar, no corregir.
La solución recomendada es un montaje de secretos de BuildKit, para que la credencial nunca persista, seguido de una inspección tanto de las capas como del historial. Es el mismo tipo de problema que reaparece una y otra vez en la cadena de suministro del software, donde una versión envenenada de un paquete con 245 millones de descargas estuvo disponible durante 86 minutos.
Hay una segunda historia aquí, y tiene que ver con quién lo encontró. Un agente de IA encadenó reconocimiento, enumeración del registro, una credencial sin salida, una búsqueda en metadatos y un mapeo de permisos sin que nadie le indicara que buscara Harbor ni un token. Esa capacidad no está reservada a los proveedores que investigan a Baseten antes de firmar un contrato.
Preguntas frecuentes
¿Se accedió a datos de clientes?
No. Strix afirma que verificó los permisos del token con peticiones de solo lectura a GitHub y se detuvo ahí, sin clonar los repositorios de clientes a los que tenía acceso, sin subir código y sin modificar ninguna configuración. Borró las imágenes de contenedor descargadas a petición de Baseten.
¿Cómo se expuso el token si los archivos estaban limpios?
Quedó registrado en el historial de compilación de la imagen, no en un archivo. Docker guarda en la configuración de la imagen el comando que creó cada capa, y esa compilación había interpolado el valor del token directamente en un comando RUN. Esa configuración se descarga junto con la imagen.
¿Cómo deberían manejarse las credenciales de compilación?
Con un montaje de secretos de BuildKit, que pone la credencial a disposición durante la compilación sin dejarla en la imagen ni en sus metadatos. Las imágenes existentes deben auditarse tanto en el contenido de sus capas como en su historial de compilación, y cualquier credencial hallada en una imagen publicada debe revocarse, no simplemente eliminarse.
