Outubro de 2026 ganhou nas redes sociais o apelido de "Black October". O rótulo não aparece nos alertas oficiais, mas a sequência de casos foi real: falhas críticas em PHP e GitLab, um pacote de IA contaminado no PyPI e vazamentos de variáveis de ambiente em plataformas de nuvem.Olhando caso a caso, um padrão se repete. Na maior parte dos incidentes, o atacante não precisou quebrar nada. Ele entrou com uma credencial válida: uma chave mestra esquecida em repositório público, um token sem escopo restrito, um app OAuth com consentimento amplo, um login sem segundo fator.

Outubro em quatro casos

Uma chave mestra que ficou cinco meses sem revogação

Uma master key do LiteLLM Agent Platform foi publicada por engano em um repositório público em 27 de maio de 2026 e nunca foi revogada. Em 10 de outubro, o atacante usou essa chave para extrair um token OAuth da GitHub CLI ligado à conta do dono da organização. O token não tinha escopo restrito e deu acesso de owner a todos os repositórios.

Onze dias depois, com tokens de dois engenheiros, o atacante disparou e aprovou a publicação da versão 1.107.0, que trazia um ladrão de credenciais e um backdoor. A regra que exigia aprovação de uma conta presa a um dispositivo físico tinha sido relaxada para permitir que quaisquer dois engenheiros aprovassem um release. O pacote ficou cerca de duas horas no PyPI.

1.900 contas e segredos que nunca foram rotacionados

A campanha GhostAction usou Personal Access Tokens roubados, muitos vindos de logs de infostealers, para inserir workflows maliciosos em repositórios do GitHub. Segundo a GitGuardian, cerca de 1.900 contas foram comprometidas, mais de 30 mil repositórios foram visados e o atacante tentou extrair 3.174 segredos de pipelines de CI.

Parte das vítimas já tinha sido atingida em ondas anteriores. A leitura dos pesquisadores é direta: os atacantes contam com segredos que não foram rotacionados.

Um app OAuth confiável em 173 tenants

O service principal do ConnectWise Cloud Backup, aplicação que os clientes autorizaram no Microsoft 365, foi usado para entrar em 173 tenants em pouco mais de duas horas, em 15 de outubro. O acesso herdava o consentimento dado ao app: e-mail, OneDrive, SharePoint e Teams. Em pelo menos um tenant, o app se adicionou à função de Global Administrator e criou novos client secrets para manter a porta aberta.

Um detalhe mostra por que NHI exige processo próprio: revogar as sessões dos usuários não encerra esse acesso, e tokens já emitidos seguem válidos por até 90 minutos depois que o app é desabilitado.

No Brasil, logins de um sistema crítico em repositório público

Em São Paulo, reportagem do UOL repercutida pelo Canaltech encontrou em um repositório público 181 logins e senhas de usuários do Smart Sampa, sistema que reúne mais de 58 mil câmeras. A exposição durou cerca de 11 meses, e o acesso testado pela reportagem não exigia autenticação em dois fatores.

A Prefeitura contesta que houvesse senhas no repositório e atribui o vazamento a um servidor, um entre mais de 7.500 agentes com acesso à plataforma, que foi afastado. As medidas anunciadas foram senhas individuais, autenticação em dois fatores e validação de novos acessos por código via SMS. Aqui a identidade é humana, mas a lição é a mesma: muitos acessos, credenciais circulando fora do sistema e nenhuma barreira além da senha.

O padrão: credencial válida, escopo amplo, ninguém olhando

Os casos não se limitam a esses quatro. No mesmo mês, a Zeabur informou que credenciais internas guardadas em texto puro foram usadas para ler mais de 3,2 milhões de registros de variáveis de ambiente, e a PingCAP relatou que credenciais roubadas de uma service account foram usadas por quase um mês para copiar código-fonte e registros de clientes. Em todos eles, quatro falhas de governança aparecem juntas.

Segredo sem dono. Chaves e tokens criados para um teste, uma integração ou um projeto ficam espalhados em repositórios, logs e variáveis de ambiente. Se ninguém responde por eles, ninguém percebe quando vazam.

Escopo maior que o propósito. Um token de automação que herda o acesso do dono da organização ou um app de backup com permissão de escrita no diretório transformam um vazamento pontual em comprometimento total. O excesso de privilégio não é o ataque, mas é o que define o tamanho do estrago.

Revogação que não acontece. Saber que uma credencial vazou não basta. A chave do LiteLLM ficou exposta por cinco meses sem ser revogada, e parte das vítimas do GhostAction foi atingida de novo por segredos que continuaram válidos.

Controle que vira exceção. Uma aprovação ligada a um dispositivo físico protege o release. Quando ela é flexibilizada por conveniência, dois tokens roubados passam a valer tanto quanto duas pessoas autorizadas.

Checklist pós-outubro: o que revisar nos próximos 30 dias

Use as perguntas abaixo como roteiro de revisão com as equipes de segurança, infraestrutura e desenvolvimento.

• Há varredura contínua de segredos em repositórios, logs e pipelines, incluindo o histórico do git?

• Toda chave, token e client secret tem dono, propósito e data de expiração registrados?

• Os tokens de automação têm escopo mínimo, ou algum herda o acesso de um administrador ou do dono da organização?

• Quando um segredo é exposto, existe procedimento de revogação e rotação com prazo definido e responsável?

• Os apps OAuth e service principals de terceiros são revisados com base nas permissões que receberam no consentimento?

• A inclusão de novas credenciais em service principals e novas atribuições de funções administrativas gera alerta?

• Etapas críticas, como a publicação de software, exigem uma aprovação que não possa ser feita apenas com tokens?

• Acessos humanos a sistemas sensíveis exigem MFA e passam por revisão periódica de quem ainda precisa deles?

Cada pergunta sem resposta confirmada é uma credencial que pode estar, neste momento, nas mãos de outra pessoa.

O autor desse artigo é Eduardo Maia, Diretor de Cybersecurity, Identity & AI da Protiviti Brasil.