Scan de segurança autônomo encontra token de admin exposto no Baseten

O que aconteceu

A Strix, empresa que desenvolve um agente autônomo de hacking para testes de penetração, avaliou a infraestrutura da Baseten - provedora de inferência avaliada em US$ 13 bilhões - antes de adotá-la como fornecedora. Sem credenciais ou código-fonte, apontando o Strix apenas para o domínio *.baseten.co, o agente encontrou em cerca de 25 minutos um token GitHub pessoal ativo, com permissões de administrador, exposto publicamente.

Como a falha foi encontrada

O Strix começou com reconhecimento convencional: enumerou hosts, vasculhou logs de certificados e mapeou a superfície externa. Localizou um registro Harbor em gcp-us-east4-zlw.registry.baseten.co com um projeto público. Sem qualquer autenticação, era possível listar repositórios, obter tokens de pull anônimos e baixar manifests e blobs de imagens, incluindo a imagem baseten/baseten-app.

Em vez de parar no relatório de exposição, o agente avaliou o impacto real. Extraiu a imagem e encontrou primeiro um par de chaves AWS, que testou com uma chamada read-only sts:GetCallerIdentity; a resposta InvalidClientTokenId mostrou que estava morta. Continuando, executou o TruffleHog nas camadas e inspecionou diretamente a config da imagem: um token GitHub pessoal estava gravado em history[].created_by, o campo que registra os comandos de build. Um RUN havia expandido o valor de GITHUB_TOKEN diretamente no comando.

Uma requisição read-only a GET /user no GitHub confirmou que o token era válido e pertencia à conta basetenbot.

Escopo do acesso

O token tinha escopo repo e a conta pertencia à organização basetenlabs. Com ele era possível obter acesso admin e push ao repositório principal de produto da Baseten, ao repositório GitOps que controla os clusters e ao tap do Homebrew, além de leitura e escrita em outros repositórios privados, incluindo repositórios específicos de clientes. A Strix não clonou o repositório de clientes, não fez push nem alterou configurações; parou assim que teve evidência suficiente e escreveu o e-mail de disclosure.

A causa raiz

O histórico de build estava datado: o passo com o token rodou em 3 de março de 2023, e o token ainda funcionava em julho de 2026. O erro é conhecido: um build precisava buscar dependências privadas no GitHub, então alguém passou o token como build argument. O Docker pode registrar esse argumento na metadados e no histórico da imagem - neste caso, gravou o valor real do token. O Docker até documenta explicitamente esse risco. Há um segundo problema no padrão: git config --global grava a URL autenticada no arquivo de configuração do Git, persistindo a credencial mesmo se a entrada do token mudar.

Resposta da Baseten e cronologia

A Baseten respondeu rápido e profissionalmente. Em 13 de julho, à noite, a Strix reportou o token ativo, o projeto Harbor público e as permissões. Na manhã de 14 de julho, a Baseten tornou o projeto privado; a Strix sinalizou que o token ainda funcionava. Às 16h34 do mesmo dia, a equipe de segurança da Baseten confirmou o problema como crítico, informou que havia tornado o projeto privado e rotacionado o token, e pediu a exclusão segura das imagens baixadas. Em 17 de julho, a Baseten encerrou os achados restantes, incluindo duas vulnerabilidades de severidade menor do mesmo scan. Em setembro, a Strix avisou da intenção de divulgar publicamente. A empresa ainda enviou camisetas e moletom como agradecimento.

Recomendações e conclusão

A Strix recomenda a quem usa containers e GitHub: verificar o que pode ser baixado sem login, incluindo tags antigas e projetos esquecidos; ler o histórico de build com docker history --no-trunc ou inspecionar os campos history[].created_by da config; remover segredos de build arguments em favor de secret mounts do BuildKit e autenticação temporária; limitar permissões e prazo de validade de tokens de build, já que buscar uma dependência não exige admin nos repositórios de produto e deploy; e revogar tokens antigos, porque mudar o Dockerfile não corrige imagens já baixadas.

O argumento central da empresa é que ataques com IA estão avançando e que a única defesa é atacar constantemente os próprios sistemas antes dos agressores. Se um agente consegue achar um token admin vivo em uma imagem antiga em 25 minutos, é melhor que um agente seu o encontre primeiro.