Baseten expuso un token admin de GitHub durante 3 años

La historia en una linea

Un agente autonomo de pentesting llamado Strix encontro, en 25 minutos y sin credenciales, un token de GitHub con permisos de administrador sobre los repositorios internos de Baseten, una de las plataformas de inferencia de IA mas cotizadas del momento. El token llevaba mas de tres anos vigente: habia quedado atrapado en el historial de construccion de una imagen de Docker desde marzo de 2023 y seguia funcionando cuando se descubrio, en julio de 2026, segun cuenta la propia compania en su disclosure.

El detalle importa porque Baseten no es cualquier victima: en junio de 2026 cerro una Serie F de US$1.500M a valoracion de US$13.000M, reporta TechCrunch. Procesa mas de 1.000 millones de llamadas de inferencia al dia, opera en 87 clusters repartidos entre 18 proveedores de nube y crece a un ritmo de unas 20 veces interanual, segun Yahoo Finance. La pregunta ya no es si tu proveedor de infraestructura es serio, sino si reviso sus imagenes viejas.

Que hace exactamente Strix y por que importa

Strix es un agente autonomo de pentesting de la compania homonima que, en lugar de correr firmas, planifica y ejecuta un ataque completo: mapea la superficie, decide que probar, explota lo que funciona y encadena hallazgos en una ruta de ataque real con prueba de explotacion. El caso de Baseten lo ilustra en cinco pasos:

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Partio de *.baseten.co sin credenciales ni codigo fuente.
Descubrio un Harbor registry publico en gcp-us-east4-zlw.registry.baseten.co y vio que uno de sus proyectos estaba accesible sin autenticacion.
Bajo imagenes de contenedor publicas, incluido baseten/baseten-app, y ejecuto TruffleHog dentro.
Encontro un par de llaves AWS obsoletas (probaron y respondieron InvalidClientTokenId).
Inspecciono la configuracion de la imagen y, en history[].created_by, aparecio un GitHub PAT del usuario basetenbot con scope repo. Seguia valido.

Lo grave no es solo el token. Es lo que el token permitia: admin y push sobre basetenlabs/baseten (el codigo del producto principal), sobre basetenlabs/flux-cd (el repo GitOps que define el estado deseado de los clusters) y sobre basetenlabs/homebrew-tap (la forma en que el CLI llega a las maquinas de los desarrolladores). Ademas, acceso de lectura/escritura a repos privados por cliente, incluido uno llamado basetenlabs/fde con un directorio customers/ con subcarpetas por cliente, segun el reporte de Strix.

Como es que un token de 2023 sigue vivo en 2026

El bug es viejo y conocido, pero la pista que lo hace devastador es el como. El Dockerfile involucraba un patron asi:

ARG GITHUB_TOKEN
RUN GITHUB_TOKEN=${GITHUB_TOKEN} bash -c '
  if [[ "${GITHUB_TOKEN}" != "" ]]; then
    git config --global --add
    url."https://${GITHUB_TOKEN}@github.com/".insteadOf "[email protected]:";
  fi'

El autor necesitaba dependencias privadas, paso el token como ARG, git config --global lo escribio en la configuracion… y Docker registro esa expansion en los metadatos de la imagen. Limpiar el archivo de credenciales dentro del contenedor no sirve: la copia sigue viva en history[].created_by y se baja junto con la imagen. La documentacion oficial de Docker lo advierte. Tres anos y un cambio de estandares de seguridad despues, nadie lo reviso.

La leccion tecnica: aun con BuildKit secret mount y autenticacion temporal, hay que auditar las capas y el historial, y revocar tokens obsoletos. Cambiar el Dockerfile no arregla imagenes que ya se distribuyeron.

Por que esto es una leccion para cualquier startup tech

El caso Baseten no es excepcional, es symptomatico. Strix lo describe como el pan de cada dia de los pentests autonomos, y los datos del sector lo respaldan. Google Threat Intelligence Group informo este mes, via The Hacker News, que un actor financiero uso un framework multi-agente autonomo para comprometer miles de credenciales de terceros en menos de seis horas. Mas alla del incidente aislado, la conclusion operativa se repite: los sistemas autonomos ya encuentran lo que los escaneos manuales no encuentran, y lo encuentran rapido.

Para un founder de SaaS, fintech o healthtech hispanohablante hay tres mensajes:

El ataque no va contra tu aplicacion, va contra tu infraestructura vieja. El exploit estaba en una imagen de marzo de 2023. Si tu equipo rota credenciales pero no audita imagenes publicadas historicamente, tienes exactamente la misma ventana de tres anos abierta.
Los proveedores grandes no son automaticamente seguros. Baseten es una plataforma respaldada por IVP, CapitalG, Nvidia, Greylock y Spark Capital, y aun asi una imagen mal construida durante un fin de semana de 2023 sirvio como puerta de entrada durante 40 meses. El tamano del cheque no compra historico de imagenes.
El volumen del descubrimiento autonomo cambia la economia. Gartner, recogido por International Business Times, proyecta que el gasto mundial en seguridad de la informacion alcanzara aproximadamente US$240.000M en 2026, un 12,5% mas que en 2025. Los analistas consultados por ese medio esperan que el grueso vaya a vendors especializados (Palo Alto, CrowdStrike, Blackpanda) antes que a los hyperscalers. Para una startup que vende a enterprise, integrar evidencia continua de pentesting autonomo empieza a dejar de ser un nice-to-have y pasa a ser un requisito en RFP.

Como descubre Strix el fallo, en terminos utiles para tu equipo

Conviene entender el metodo porque sirve como checklist inverso: lo que el agente automatizo es lo que tu equipo de seguridad deberia correr como rutina.

Reconocimiento completo del dominio. Certificate logs, subdominios, registros publicos. Strix encontro el Harbor publico porque mapeo todo *.baseten.co, no solo los servicios que el equipo recordaba como publicos.
Prueba de acceso anonimo en registries. Muchos proyectos en Harbor quedan publicos por descuido. baseten/baseten-app estaba accesible sin token.
Lectura de configuracion de la imagen, no solo de capas. docker history --no-trunc y el campo history[].created_by exponen secretos aunque el archivo original este borrado.
Validacion de credenciales encontradas contra el proveedor real. Llamadas read-only a GitHub y AWS (sts:GetCallerIdentity) que devuelven 200 o InvalidClientTokenId deciden si el hallazgo es un secreto vivo o solo ruido.
Cadena de impacto. Un token sirve para algo solo si tiene scope. Strix enumero repos y permisos antes de reportar, lo que convierte un «encontre un token» en un «este token permite tomar el cluster de produccion».

Tu escaneo minimo equivalente, hoy:

Listar imagenes publicas en registries propios y de socios, incluyendo tags antiguas.
Correr docker history --no-trunc sobre cada imagen y revisar created_by en busca de tokens o llaves en linea de comandos.
Auditar los repositorios donde esos tokens tienen acceso: el 99% de las imagenes solo necesitan read sobre la dependencia especifica, no admin sobre toda la organizacion.
Forzar expiracion corta en cada GITHUB_TOKEN o equivalente (GitHub PAT con fecha, GitHub App con instalacion rotada).

La respuesta de Baseten y lo que aprendieron

Para ser justos, la respuesta fue solida. Segun la cronologia publicada por Strix:

13 de julio, 23:10: reporte inicial con el token vivo, el Harbor publico y los permisos.
14 de julio, manana: Baseten hizo privado el proyecto Harbor. Strix volvio a comprobar y reporto que el token seguia funcionando.
14 de julio, 16:34: confirmacion de Anton, del equipo de Seguridad de Baseten, como hallazgo critico y rotacion del token en curso.
14 de julio, 17:05: confirmacion de borrado de las imagenes descargadas y envio de dos hallazgos de severidad menor.
17 de julio: cierre de los hallazgos pendientes.
Septiembre: aviso previo a la disclosure publica y revision del borrador por parte de Baseten.

Como detalle anecdotico: Strix recibio playeras y sudaderas como agradecimiento por el bug critico. La coordinacion profesional es un buen ejemplo, pero no compensa el hecho de que un PAT con admin sobre infraestructura de produccion haya circulado abierto durante mas de tres anos.

Que significa esto para tu startup

Si construyes o vendes infraestructura (inferencia, hosting, datos, agentes), este caso redefine tu lista de compras para 2026. La seguridad de contenedor ya no es un checkbox de CI; es un activo de marca y un requisito de due diligence para vender a empresas medianas y grandes. Tres acciones concretas que puedes tomar esta semana:

Audita tu parque de imagenes, no solo tu pipeline actual. Descarga las tags de tus ultimos 24 meses en un entorno aislado, corre docker history --no-trunc y pasa cada created_by por un detector de secretos. Es trabajo tedioso, pero es trabajo que un agente autonomo puede hacer en horas.
Reescribe tus Dockerfiles con BuildKit secret mount y rotacion por build. Si hoy pasas tokens con ARG, tu imagen probablemente lleva rastros en el historial aunque creas que el codigo esta limpio. Vale la pena rehacer las imagenes criticas y republicarlas con tags nuevas.
Integra un pentest autonomo continuo como linea base antes de cerrar deals enterprise. Plataformas como Astra Security, NodeZero (Horizon3.ai), XBOW o la propia Strix ya ofrecen pruebas de explotacion con reproduccion, no solo alertas. The Next Web publico esta semana un ranking actualizado donde la mayoria arranca entre US$4.000 y US$8.000 por test, accesible para una SaaS en etapa Series A. Es una linea de presupuesto pequena comparada con el costo de un incidente de cadena de suministro.

Si tu startup depende de un proveedor como Baseten, Together, Fireworks, Replicate o un hyperscaler, la pregunta para tu CTO no es «confio en ellos», sino «cuando fue la ultima vez que audito sus imagenes y sus tokens». La confianza sin prueba ahora se audita en minutos.