768 chaves vazadas da AWS ainda dão controle total

A Truffle Security revalidou, em 10 de agosto de 2026, um lote de 10.616 chaves de acesso da AWS encontradas expostas publicamente entre agosto de 2022 e agosto de 2026 — espalhadas por histórico de Git, datasets do Hugging Face, imagens Docker, registries de pacotes e logs de CI. O resultado: 88% delas ainda autenticam normalmente, e 768 pertencem a empresas com controle administrativo total sobre a conta na nuvem.

Escala do problema

O levantamento partiu de uma base bem maior: 431.875 achados públicos, deduplicados em 64.024 pares únicos de chaves AWS, ligados a 50.654 contas. Dessas, 10.625 (16,6%) são chaves root — a identidade máxima da conta, sem possibilidade de restrição de permissões.

Do subconjunto de 9.308 chaves ativas que puderam ser classificadas por vínculo, 817 estão associadas a empresas (nome real na conta ou domínio corporativo). Cruzando isso com o nível de privilégio, a Truffle Security chegou ao número central: 526 são chaves root e outras 242 são usuários IAM com a política AdministratorAccess. Somadas, 768 chaves dão controle irrestrito da conta AWS de uma empresa.

No topo da gravidade estão 130 chaves root ativas vinculadas a contas de gerenciamento de Organizations — a conta que comanda todas as demais dentro da organização. Comprometer uma dessas expõe todas as contas-membro de uma vez.

Hugging Face é a maior fonte isolada

Entre as origens mapeadas, o Hugging Face concentra 8.482 chaves únicas ainda ativas, espalhadas por 3.394 datasets públicos — o maior volume de qualquer fonte individual. Nesse grupo, 17,9% são chaves root, a proporção mais alta entre todas as origens analisadas. A explicação: datasets costumam ser cópias de repositórios de código reempacotadas para treinamento, e uma chave commitada uma única vez acaba tokenizada em corpora baixados por milhares de projetos.

Chaves de cinco anos, nunca rotacionadas

Para as 2.903 chaves em que foi possível consultar a data de criação, a idade mediana da chave ainda ativa é de 1.831 dias — cerca de cinco anos. A mais antiga tem 17,4 anos, quase a idade do próprio IAM. Apenas 13,7% (398 de 2.903) tinham qualquer chave mais nova associada ao mesmo usuário, sinal de rotação. As demais 86% nunca foram trocadas, substituídas ou desativadas.

A própria AWS já tinha detectado parte disso

Do total de 7.590 chaves de usuário IAM ativas analisadas, 929 (12%) já carregam a política AWSCompromisedKeyQuarantine, aplicada automaticamente pela AWS quando detecta exposição pública. Entre elas, 112 usam a versão antiga da política, descontinuada em 2023 — ou seja, foram sinalizadas há pelo menos três anos, os donos foram notificados, e as chaves continuam autenticando.

Questionada pelo BleepingComputer, a Amazon confirmou que notifica clientes sempre que toma conhecimento de chaves expostas e aplica políticas de quarentena para conter o risco sem interromper o ambiente do cliente, reforçando que a segurança da nuvem segue o modelo de responsabilidade compartilhada.

Outro dado exposto pela pesquisa: apenas 9,5% das 2.754 contas com Cost Explorer legível tinham algum alerta de orçamento configurado, com limite mediano de US$ 8. As contas legíveis somaram US$ 420.631 em gastos só em julho de 2026, com 50 delas ultrapassando US$ 1 mil e 9 passando de US$ 10 mil no mês — sem qualquer barreira automática de contenção.

Como reduzir a exposição

1. Elimine chaves de acesso root. Não há justificativa para uma chave root existir em 2026 — revise todas as contas, inclusive a pessoal esquecida desde 2019.
2. Liste as chaves IAM por idade com aws iam list-access-keys e aplique uma política de idade máxima para forçar rotação periódica.
3. Configure um alerta de orçamento, mesmo que baixo. Um limite de poucos dólares já sinaliza cryptomining ou uso indevido antes que a fatura explique.
4. Trate qualquer credencial commitada como comprometida. Apagar o arquivo depois não ajuda: 43% das chaves da amostra apareceram mais de uma vez em repositórios, datasets e imagens diferentes.
5. Monitore a política AWSCompromisedKeyQuarantine na conta. Se ela aparecer em um usuário, é a própria AWS avisando que aquela chave já é pública.

Perguntas frequentes

O que torna uma chave root da AWS mais perigosa que uma chave IAM comum?
A chave root representa a identidade da conta inteira e não pode ser restringida por políticas de permissão. Quem a possui pode encerrar a conta, alterar cobrança e acessar qualquer recurso, sem as barreiras que se aplicam a um usuário IAM.

Como uma chave da AWS vaza sem que a empresa perceba?
Os casos mapeados vieram de histórico de commits do Git, datasets públicos no Hugging Face, imagens Docker publicadas com credenciais embutidas e logs de CI acessíveis. Em muitos casos a chave nunca foi removida do histórico, mesmo depois de excluída do arquivo atual.

A AWS avisa quando detecta uma chave exposta?
Sim. A AWS aplica a política AWSCompromisedKeyQuarantine a chaves identificadas como públicas e notifica o titular da conta. A pesquisa mostra, porém, que parte dessas chaves continua ativa anos depois do aviso.

Um alerta de orçamento evita o prejuízo de uma chave vazada?
Não impede o vazamento, mas limita o estrago financeiro: cryptomining e uso indevido de recursos geram custo visível rapidamente, e um alerta de poucos dólares já é suficiente para sinalizar atividade fora do padrão antes de a fatura chegar alta.

Rotacionar a chave depois de um tempo já resolve o risco?
Reduz, mas não elimina: se a chave antiga já foi replicada em datasets ou imagens de terceiros, ela permanece exposta onde quer que tenha sido copiada. A rotação evita novos vazamentos a partir da chave atual, não remove cópias já distribuídas.

Conclusão

O levantamento da Truffle Security expõe um padrão recorrente em ambientes de nuvem: a chave vazada raramente é recente — o problema já existe há anos e segue sem tratamento porque ninguém revisita credenciais antigas. Para times de infraestrutura, o achado é um lembrete direto: auditar chaves root e IAM, configurar alertas de orçamento e assumir que toda credencial já commitada em algum momento deve ser tratada como pública, independentemente de quando isso aconteceu.