Para: pessoas e organizações que desenvolvem ou administram repositórios no GitHub, e quem usa o GitHub Actions ou credenciais de nuvem (incluindo federação OIDC). Este artigo se baseia em publicações públicas das empresas de segurança que investigaram e em um comunicado de um provedor relacionado. Não trata dos passos do ataque.
続報待ち：この記事は公式発表に合わせて更新します
- Quem é afetado
pessoas e organizações que desenvolvem ou administram repositórios no GitHub, e quem usa o GitHub Actions ou credenciais de nuvem (incluindo federação OIDC).
- Confirmado até agoraVer a tabela ↓
- Cerca de 4.800 contas abusadas
- Pull requests de sondagem a 61.764 repositórios
- Repositórios com alterações maliciosas
Mais 3
- O código malicioso foi executado e credenciais foram enviadas
- Roubo de segredos e credenciais de nuvem
- Contaminação de pacotes publicados
Apontado como possivelmente afetado
- Persistência na nuvem (configurações que sobrevivem à rotação)
- Ainda não confirmado
- Número final de contas e repositórios afetados (as empresas que investigam contam de formas diferentes)
- Como os tokens foram roubados inicialmente (não estabelecido para a campanha como um todo, exceto o caso do provedor de nuvem)
- Uma declaração oficial do GitHub (não informada na verificação de 14 de novembro)
Mais 2
- Relação com uma campanha separada de outubro do mesmo ator (as empresas A e C não afirmam que seja um único ator)
- Conclusão da revogação de tokens do provedor de nuvem (o provedor acrescentou que ela parou no meio)
- O que fazer agoraVer os passos ↓
- Verifique se há pull requests, branches e execuções do Actions que você não reconheça
- Revogue os tokens, autorizações e sessões da conta comprometida
- Se alterações maliciosas podem ter sido executadas, rotacione todos os segredos e permissões de nuvem que esse repositório podia ler
Mais 3
- Verifique na nuvem as alterações que sobrevivem a uma rotação
- Faça um inventário dos seus tokens e apps de terceiros
- Verifique se seus próprios apps não expõem a pasta de controle de versão
- Onde verificar (fonte)Todas as fontes ↓
- GitHub, «Changelog» e «Security» (blog oficial e changelog; sem entrada sobre isso; consultado em 14 de novembro)
- Última verificação
- em 14 de novembro de 2026
Próximos avisos e o que verificamos
As publicações das empresas que investigam saíram todas em 12 de novembro e devem ser lidas como sujeitas a revisão. Em 14 de novembro, o blog, o changelog e o histórico de status do GitHub não mostravam nenhuma entrada sobre isso.
O que donos de repositórios e desenvolvedores devem fazer hoje
Verifique se há pull requests, branches e execuções do Actions que você não reconheça
Em cada repositório em que sua conta pode escrever (incluindo organizações em que você é colaborador), verifique estas três coisas desde 10 de novembro. Segundo a empresa A, dos 61.839 pull requests de sondagem, 10.431 foram para repositórios que a conta não possui, alcançados por acesso de colaborador ou de organização.
- Pull requests que nem você nem um colega abriu. Mesmo que o título pareça inofensivo (como uma atualização de documentação), o mesmo padrão em muitos repositórios é um sinal de alerta
- Branches de curta duração que você não reconheça, ou sinais de que branches foram criados e excluídos
- Histórico de execuções do Actions com execuções que você não reconheça ou lacunas nos números de execução. As empresas A e C escrevem que o atacante exclui execuções e logs em cerca de um minuto, então uma lacuna na numeração é uma pista. Verifique também o log de auditoria da organização
Se encontrar algum desses sinais, continue abaixo. A empresa A escreve que uma conta com um pull request de sondagem deve ser tratada como comprometida mesmo que a etapa posterior não tenha sido executada.
Revogue os tokens, autorizações e sessões da conta comprometida
Esta ordem segue a orientação das empresas B e C.
- Revogue tokens de acesso pessoal, autorizações a apps de terceiros (apps OAuth e apps do GitHub), chaves SSH e sessões ativas, e recrie apenas o necessário
- Ative a autenticação em dois fatores. Um token já roubado funciona sem ela, então primeiro é preciso revogar o token (opinião deste site)
- Feche o pull request de sondagem e exclua os branches que você não reconheça. Antes de excluir, anote sob qual conta foram criados
Se alterações maliciosas podem ter sido executadas, rotacione todos os segredos e permissões de nuvem que esse repositório podia ler
As empresas A e B escrevem que, se a alteração maliciosa foi executada, todos os segredos e funções de nuvem disponíveis para esse workflow devem ser tratados como roubados.
- Reemita os segredos e variáveis do Actions (nível de repositório, de ambiente e de organização), tokens de publicação (incluindo os de pacotes) e chaves de deploy, e invalide os antigos
- Se você usa OIDC para acessar uma conta de nuvem, inclua essa permissão de nuvem (próximo passo)
- Se você compilou em uma máquina de desenvolvimento um repositório que pode ter recebido uma alteração maliciosa, rotacione também as credenciais que essa máquina podia ler (chaves SSH, credenciais de nuvem, tokens de publicação de pacotes etc.). As empresas B e C relatam alterações que rodam na instalação de pacotes
- Se você publicou pacotes desde 10 de novembro, verifique se as versões publicadas não contêm a alteração maliciosa; se contiverem, retire-as e publique de novo a partir de um estado limpo
Verifique na nuvem as alterações que sobrevivem a uma rotação
Como alterações que sobrevivem à rotação de segredos, a empresa A lista a reescrita de uma política de confiança de função da AWS e a adição de credenciais federadas do Azure (a empresa B também aponta chaves de acesso da AWS deixadas para trás). Verifique essas duas áreas tanto nos logs de auditoria quanto nas configurações atuais.
- AWS: chaves de acesso recém-criadas e alterações em políticas de confiança de funções (se a confiança foi ampliada para contas ou condições não pretendidas)
- Azure (Entra ID): credenciais federadas adicionadas a aplicativos que apontam de volta a um repositório
Separadamente, como verificação de escalonamento de privilégios com credenciais roubadas, veja também o Google Cloud (uso incomum de contas de serviço ou chamadas de emissão de tokens) e o Vault ou Kubernetes (logins OIDC do GitHub que você não reconheça).
Mesmo que não encontre nada, verifique se suas condições de confiança OIDC estão restritas ao repositório, ao branch e ao ambiente (veja «O que revisar» abaixo).
Faça um inventário dos seus tokens e apps de terceiros
Nas configurações do GitHub, liste o seguinte e remova o que for desnecessário ou desconhecido.
- Tokens de acesso pessoal: exclua os não usados; nos demais, limite repositórios, permissões e validade
- Apps OAuth e apps do GitHub que você autorizou, incluindo os conectados para hospedagem ou deploy de CI. Remova a autorização dos que não usa mais
- Chaves SSH e chaves de deploy: remova as não usadas e as sem responsável
- Permissões de contas de bots e automação: verifique se alguma pode contornar as regras de branches protegidos
Segundo o comunicado do provedor de nuvem, é preciso reconectar o app desse provedor. Se você o usa, siga as instruções do provedor.
Verifique se seus próprios apps não expõem a pasta de controle de versão
O mesmo provedor explica que alguns apps implantados pelo GitHub publicaram todo o diretório de build, e por isso um token deixado ali podia ser obtido. Verifique se a URL pública do seu app não serve o conteúdo da pasta de controle de versão (.git). Se servir, exclua-a da imagem, reimplante e rotacione as credenciais que ela continha. Verifique também se sua plataforma de deploy usa um mecanismo semelhante.
O que aconteceu (segundo as empresas que investigam e o provedor relacionado)
O que segue se baseia em publicações públicas das empresas de segurança A, B e C (todas de 12 de novembro de 2026) e em um comunicado de um provedor de nuvem (tomado conhecimento na noite de 12 de novembro, adendo em 13 de novembro). São relatos das próprias partes e dos investigadores, e o GitHub não os confirmou. Os horários são UTC, salvo indicação em contrário.
10 nov., por volta das 12:45
Segundo a empresa A, o atacante começou a operar, com tokens roubados, nos repositórios em que cada token podia escrever. Em cada repositório, enviou primeiro um pull request de sondagem, depois fez uma alteração maliciosa, a reverteu em cerca de um minuto e excluiu a execução e os logs. A empresa B também situa a primeira alteração maliciosa às 12:46.11 nov., 15:00
Fim da janela dos 61.839 pull requests de sondagem contados pela empresa A.12 nov., 04:36
Fim da janela dos 8.093 repositórios públicos com alterações maliciosas contados pela empresa B.12 nov., 07:40
Momento em que a empresa C contou mais de 63.000 pull requests de sondagem. As empresas A, B e C publicaram seus textos no mesmo dia.12 nov., 22:00 (fuso horário não informado)
Um provedor de nuvem publicou um comunicado dizendo que tomou conhecimento (em 12 de novembro; sem horário) de que tokens emitidos ao seu app do GitHub haviam sido usados por uma parte não autorizada em repositórios de clientes (comunicado do provedor).13 nov., 15:54
O provedor acrescentou que a revogação de todos os tokens de usuário parou no meio e que o GitHub está investigando (comunicado do provedor).
Token roubado válido
Um pull request de sondagem testa se é possível escrever
↓→
Alteração maliciosa
Coleta segredos de CI e credenciais de nuvem e os envia para fora
↓→
Apagando rastros
Reverte a alteração, exclui execuções e logs; configurações podem permanecer na nuvem
Números por fonte (não os some)
| Fonte (papel) | O que foi contado | Número | Observação |
|---|---|---|---|
| Empresa A (primeira a relatar) | Contas que enviaram / repositórios que receberam pull requests de sondagem | 4.837 contas / 61.764 repositórios | Cerca de 92% ainda estão abertos (o denominador são os 10.431 PRs enviados a repositórios que a conta não possui) |
| Empresa A | Repositórios em que o código malicioso foi executado e credenciais foram enviadas | Pelo menos 1.835 (1.806 em outro trecho) | Dois números dentro do texto; diz que o número pode ser um piso |
| Empresa A | Contas que podem publicar pacotes | Pelo menos 50 | Direitos de publicação em npm, Go, PyPI, Packagist e crates, segundo seu entendimento |
| Empresa B | Repositórios públicos com alterações maliciosas (10 nov. 12:46 a 12 nov. 04:36) | 8.093 | Não é o número em que foi executado. O detalhamento soma 8.096; a diferença não é explicada |
| Empresa B | Pull requests de sondagem | 61.879 PRs / 4.833 contas / 61.734 repositórios | Não incluídos nos 8.093 |
| Empresa C | Pull requests de sondagem (em 12 nov., 07:40) | Mais de 63.000 | Cerca de 90% abertos. 173 deles (19 contas) vieram de tokens emitidos ao app do GitHub de um provedor de nuvem |
| Provedor de nuvem (seu próprio comunicado) | Pull requests de sondagem encontrados em contas de clientes afetados | Mais de 250 | Diz que um pequeno número de clientes foi afetado |
A empresa B escreve que seus números vêm da busca do GitHub, que cobre apenas os branches padrão de repositórios públicos, então o total real provavelmente é maior.
- O que foi roubado
- Segredos e variáveis do GitHub Actions, tokens de workflow, credenciais de nuvem (AWS, Azure, Google Cloud) e credenciais de desenvolvedores e de serviços de IA (empresa A)
- Causa (relato dos investigadores)
- Abuso de tokens roubados válidos, não uma falha do GitHub Actions (empresa C). Os commits aparecem com os nomes dos usuários reais, sem assinatura, o que aponta para tokens roubados (inferência da empresa B)
- Como os tokens foram obtidos
- Não estabelecido para a campanha como um todo. Para a parte que veio pelo app do provedor de nuvem, a empresa C também diz que não conseguiu estabelecer como os tokens foram obtidos e que não tem evidências de violação da infraestrutura do provedor
- Relato do provedor de nuvem
- Sua infraestrutura não foi violada. Nos deploys baseados no GitHub, um token foi deixado em um arquivo de configuração no diretório de build, e alguns apps publicaram todo o diretório, então ele podia ser obtido. Um pequeno número de clientes foi afetado e contatado individualmente. Começou a revogar todos os tokens de usuário emitidos ao app e mudou o processo de deploy. Diz que deploys pela sua ferramenta de linha de comando, seus tokens de API e apps em execução não são afetados
- Impacto em pacotes
- A empresa B examinou 218 pacotes de npm, Go e Packagist cujos repositórios de origem receberam alterações maliciosas. Existiram versões maliciosas em três pacotes (um do Packagist, dois do Go), cinco versões no total na sua lista; não encontrou outras. PyPI e outros não foram verificados. A empresa A também vê o objetivo do atacante nos segredos de CI, e a contaminação de pacotes como efeito colateral da publicação automatizada
- Relação com uma campanha separada de outubro
- A empresa A diz que contas atingidas por uma campanha de outubro tinham mais chance de ser atingidas nesta, mas as avalia como operações separadas de atores diferentes. A empresa C também diz que a sobreposição não prova um único ator (tokens roubados são compartilhados e vendidos)
- Declaração oficial do GitHub
- Não informada (blog, changelog e histórico de status consultados em 14 de novembro de 2026)
O que se sabe e o que não se sabe
Estado em 14 de novembro de 2026. Atualizaremos a coluna de status quando houver novidades.
| Item | O que foi publicado | Status |
|---|---|---|
| Cerca de 4.800 contas abusadas | Tokens roubados válidos usados para enviar pull requests de sondagem | Confirmado (empresas A e B) |
| Pull requests de sondagem a 61.764 repositórios | Um número diferente de se houve alterações depois | Confirmado (empresa A; a empresa B conta 61.734) |
| Repositórios com alterações maliciosas | 8.093 repositórios públicos | Confirmado (empresa B; apenas repositórios públicos e branches padrão) |
| O código malicioso foi executado e credenciais foram enviadas | Pelo menos 1.835 repositórios | Confirmado (empresa A; dá também 1.806) |
| Roubo de segredos e credenciais de nuvem | Nos repositórios em que foi executado | Confirmado (empresas A e B) |
| Persistência na nuvem (configurações que sobrevivem à rotação) | Reescrita de uma política de confiança de função da AWS e adição de credenciais federadas do Azure (empresa A); a empresa B aponta também chaves de acesso da AWS deixadas para trás | Possível (empresas A e B) |
| Exploração de uma falha do GitHub Actions | Não foi usada | Não incluído (empresa C) |
| Contaminação de pacotes publicados | Três pacotes (um do Packagist, dois do Go), cinco versões no total (outros não encontrados) | Confirmado (empresa B; PyPI e outros não verificados) |
| Violação da infraestrutura do provedor de nuvem | Sem evidências (empresa C); o provedor nega violação | Não confirmado (empresa C, o provedor) |
| Como os tokens foram roubados inicialmente | Explicado para parte dos tokens do app do provedor de nuvem; desconhecido no geral | Em investigação |
| Ligação com uma campanha separada de outubro | A empresa A vê operações separadas; a empresa C não afirma que seja uma | Em investigação |
| Declaração oficial do GitHub | Nenhuma encontrada | Não informada |
| Uma lista confirmada de organizações afetadas | Não publicada | Não informada |
Como ler isto: os números contam coisas diferentes e mudaram em dois dias
Os 1.835 da empresa A são uma estimativa de execuções, os 8.093 da empresa B são repositórios públicos com alterações maliciosas, e os 63.000 da empresa C são pull requests de sondagem. Não são a mesma coisa. Muitos repositórios que receberam apenas um pull request de sondagem podem não ter sofrido alterações nem roubo. Porém, segundo a empresa A, uma conta que enviou um pull request de sondagem deve ser tratada como comprometida mesmo que nenhuma alteração tenha se seguido.
O que pode acontecer quando tokens roubados válidos são usados
O que segue é geral e não significa que isso aconteceu aqui. O que as empresas que investigam relatam que aconteceu está em «O que aconteceu» acima.
Se um token é válido, o atacante pode escrever como um usuário legítimo. Não há fraqueza em um recurso do GitHub a explorar, e uma atualização de software não o impede. Se uma conta com acesso de escrita pode modificar um workflow de CI, os segredos e permissões de nuvem que esse workflow pode ler passam a ser alvo juntos. Se a confiança OIDC com uma conta de nuvem é frouxa (qualquer branch ou workflow pode entrar), credenciais temporárias podem ser emitidas mesmo sem um segredo armazenado. Se sua conta é colaboradora em outra organização, o dano se estende além do que você possui.
O que revisar em CI e nas permissões de nuvem
Esta seção não é uma avaliação das partes afetadas. Com base nos relatos dos investigadores, concentra-se no que verificar na sua própria configuração como opinião deste site.
Não mantenha tokens amplos nem de longa duração
Aqui foram usados tokens roubados válidos. Limite os tokens de acesso pessoal a repositórios e permissões específicos, dê-lhes vida curta e exclua-os quando não forem mais usados (use o tipo de permissões granulares). Autorize apps de terceiros apenas no escopo de que precisam (opinião deste site).
Restrinja as permissões dos workflows e as condições para entrar na nuvem
Deixe a permissão padrão dos workflows como somente leitura e conceda escrita apenas onde necessário. Restrinja a confiança OIDC da nuvem ao repositório, ao branch e ao ambiente, para que nem todo workflow possa entrar. Colocar aprovadores nos segredos de ambiente faz com que um workflow reescrito não possa simplesmente ler os segredos de produção (opinião deste site).
Corrija a proteção de branches com revisões obrigatórias
A empresa A escreve que o código inclui um mecanismo feito para contornar a proteção de branches. Não confie apenas nos nomes das verificações: exija revisões de aprovação dos responsáveis pelo código e não permita exceções para contas de bots (opinião deste site).
Detecte lacunas nos números de execução e alterações de configuração na nuvem
Neste caso, execuções e logs foram excluídos e as lacunas na numeração foram a pista. Mantenha o log de auditoria da organização e configure alertas para alterações em workflows e para criação de chaves de acesso na nuvem, mudanças em políticas de confiança e federação de identidade adicionada. A empresa C também recomenda limitar o tráfego de saída do CI a uma lista de permitidos.
Não guarde segredos no repositório
À parte os segredos de CI, as credenciais no histórico do código vão junto com o token roubado de qualquer pessoa que consiga lê-las. Para detectá-las antes do commit, veja Como impedir segredos antes do commit com o gitleaks; para a ordem de revogação, veja 540.000 credenciais expostas no GitHub continuam válidas.
Fontes (registros públicos)
Os fatos deste artigo vêm das informações públicas abaixo. O GitHub não tem declaração oficial sobre isso (consultado em 14 de novembro). Detalhes dos passos do ataque não são tratados.
- GitHub, «Changelog» e «Security» (blog oficial e changelog; sem entrada sobre isso; consultado em 14 de novembro) — github.blog / github.blog
- GitHub Status (histórico oficial de incidentes; sem entrada sobre isso; consultado em 14 de novembro) — githubstatus.com
- Comunicado de um provedor de nuvem, «Security: GitHub tokens exposed by apps deployed from GitHub» (fórum oficial da comunidade; tomado conhecimento em 12 de novembro, adendo em 13 de novembro; consultado em 14 de novembro) — community.fly.io
- Empresa A (empresa de segurança; primeira a relatar), «wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories» (12 de novembro de 2026; consultado em 14 de novembro) — aikido.dev
- Empresa B (empresa de segurança), «wfx: GitHub Actions Credential Stealer Hits 8,000 Repos» (12 de novembro de 2026; consultado em 14 de novembro) — safedep.io
- Empresa C (empresa de segurança), «WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks» (12 de novembro de 2026; consultado em 14 de novembro) — stepsecurity.io
- Imprensa: BleepingComputer, «Hackers compromise 4,800 GitHub accounts to steal cloud credentials» (consultado em novembro; cobertura do texto da empresa A) — bleepingcomputer.com
Histórico de atualizações
2026-11-14: Primeira versão. Com base nas publicações públicas de três empresas de segurança (todas de 12 de novembro) e no comunicado de um provedor de nuvem. O GitHub não tem declaração oficial. Onde os relatos da imprensa divergem, a publicação original de cada parte é tratada como fonte primária. Atualizaremos quando mais for publicado.
Leia em seguida
- Credenciais publicadas que continuam válidas porque não são revogadas: 540.000 credenciais expostas no GitHub continuam válidas
- Outro caso em que o desenvolvimento baseado no GitHub foi alvo: O ataque à cadeia de suprimentos do TanStack e do Nx
- Ordem de revogação e danos por meio de pacotes: Como se defender de ataques à cadeia de suprimentos do npm
- Protegendo sua conta: Autenticação em dois fatores do GitHub / Noções básicas de variáveis de ambiente e chaves de API
- Incidentes que ocorrem com credenciais legítimas: Os vazamentos de 2026 acontecem com credenciais legítimas
- Outros incidentes de 2026: Vazamentos de dados e ciberataques de 2026