Tronlar
Gamma
Verificación en dos pasos activada
Usuário com poucas negociações! Use sempre o saldo do ForoBeta!
Uma nova campanha de ataques contra o GitHub deixou os desenvolvedores em alerta.
Segundo uma investigação publicada em 12 de novembro de 2026 pela Aikido Security, os atacantes usaram as credenciais de 4.837 contas comprometidas para inserir código malicioso em repositórios aos quais tinham acesso.
Os pesquisadores detectaram tentativas de ataque em 61.764 repositórios, dos quais pelo menos 1.806 chegaram a executar código projetado para roubar credenciais.
O preocupante é que os atacantes não buscavam simplesmente modificar arquivos.
O objetivo deles era obter as chaves e segredos usados pelos sistemas de integração contínua (CI/CD), especialmente o GitHub Actions, para acessar depois outros serviços.
🔴 Como o ataque funcionava?
Os atacantes usavam contas do GitHub previamente comprometidas para verificar em quais repositórios podiam fazer alterações.
Primeiro criavam uma branch chamada
Quando encontravam um repositório com as permissões adequadas, inseriam código malicioso nos processos automatizados do projeto.
Esse código estava preparado para coletar informações como:
Depois de executar o código, os atacantes revertiam as alterações, às vezes em menos de um minuto, e apagavam os registros de execução quando podiam.
Isso complica bastante a detecção, porque um repositório pode parecer normal mesmo que suas credenciais tenham ficado expostas.
💻 Também foram detectados pacotes afetados
A investigação identifica como maliciosa a versão 3.14.3 do pacote
O próprio repositório de pacotes exibe um aviso relacionado a malware.
Também são mencionadas duas versões do módulo Go
No caso do módulo Go, o código malicioso estava em arquivos do GitHub Actions e não no código do módulo nem nos seus binários.
Portanto, instalar esse módulo não significa necessariamente ter executado o malware, embora os pesquisadores recomendem evitar essas versões.
🔎 Como verificar se o seu repositório pode estar afetado
A Aikido publicou vários indicadores que podem ajudar a identificar essa campanha.
Branches suspeitas:
Os dois últimos padrões representam nomes de branches variáveis, não nomes literais.
Título de pull request utilizado:
Mensagens de commits relacionadas:
Também foram identificados arquivos com nomes parecidos com:
Em alguns casos, os atacantes modificavam o arquivo
Identificador SHA-256 do script malicioso:
Endereços usados para receber os dados roubados:
Importante: encontrar algum desses indicadores não prova por si só que credenciais foram roubadas, mas é motivo suficiente para investigar.
Além disso, a ausência de arquivos suspeitos ou de registros de execução também não garante que um repositório esteja limpo, porque os atacantes tentavam apagar seus rastros.
🛡️ O que fazer se você encontrar algum desses sinais?
Se vocês usam o GitHub para gerenciar projetos, vale revisar os pull requests, os commits e o histórico do GitHub Actions desde 10 de novembro.
Se encontrarem atividade suspeita:
Um detalhe especialmente preocupante é que os pesquisadores encontraram técnicas que podiam manter o acesso mesmo depois de trocar determinadas credenciais.
Por exemplo, o malware podia modificar políticas de confiança da AWS ou adicionar credenciais de identidade federada no Azure.
Por isso, trocar as senhas ou os tokens nem sempre é suficiente: também é preciso revisar as permissões e as configurações de segurança.
🔗 Tem relação com os ataques de outubro?
A Aikido encontrou coincidências com contas afetadas pela campanha GhostAction de outubro passado.
Segundo os pesquisadores, as contas comprometidas durante aquela campanha tinham uma probabilidade muito maior de aparecer também neste novo ataque.
Em mais de 100 repositórios, o novo código malicioso foi adicionado a arquivos usados anteriormente pelo GhostAction.
No entanto, ainda não há provas suficientes para afirmar que os dois ataques sejam obra do mesmo grupo.
A infraestrutura e as técnicas utilizadas apresentam diferenças, e as credenciais roubadas podem acabar nas mãos de atacantes diferentes.
Também não se sabe publicamente como eles conseguiram inicialmente as credenciais das 4.837 contas.
📅 O que se sabe em 12 de novembro de 2026?
Por enquanto, os principais números conhecidos são:
Esses números vêm de repositórios públicos que puderam ser analisados.
Os pesquisadores alertam que também podem existir repositórios privados afetados.
Além disso, foram detectadas novas solicitações suspeitas durante a manhã de 12 de novembro, embora não tenha sido possível confirmar se chegaram a executar o malware.
Não foi demonstrado que os servidores do GitHub tenham sido hackeados diretamente.
O que está documentado é o uso de credenciais de contas comprometidas para agir sobre repositórios com permissões de escrita.
Para quem usa o GitHub em projetos web, aplicativos ou deploys automatizados, vale a pena revisar as contas e os repositórios, especialmente se tivermos chaves de API ou credenciais de servidores configuradas.
Não é preciso que alguém consiga diretamente a senha do nosso servidor: se conseguir executar código em um workflow com permissões suficientes, pode acessar informações igualmente sensíveis.
🔗 Fontes
Importante: as informações correspondem às investigações publicadas em 12 de novembro de 2026.
O alcance do ataque pode mudar à medida que surgirem novos dados.
Segundo uma investigação publicada em 12 de novembro de 2026 pela Aikido Security, os atacantes usaram as credenciais de 4.837 contas comprometidas para inserir código malicioso em repositórios aos quais tinham acesso.
Os pesquisadores detectaram tentativas de ataque em 61.764 repositórios, dos quais pelo menos 1.806 chegaram a executar código projetado para roubar credenciais.
O preocupante é que os atacantes não buscavam simplesmente modificar arquivos.
O objetivo deles era obter as chaves e segredos usados pelos sistemas de integração contínua (CI/CD), especialmente o GitHub Actions, para acessar depois outros serviços.
🔴 Como o ataque funcionava?
Os atacantes usavam contas do GitHub previamente comprometidas para verificar em quais repositórios podiam fazer alterações.
Primeiro criavam uma branch chamada
wfx-docs e abriam uma solicitação de alteração (pull request) com o título docs: dependency audit notes.Quando encontravam um repositório com as permissões adequadas, inseriam código malicioso nos processos automatizados do projeto.
Esse código estava preparado para coletar informações como:
- Tokens do GitHub e segredos do GitHub Actions.
- Credenciais da AWS, Azure e Google Cloud.
- Chaves SSH e acessos a servidores.
- Tokens do npm, PyPI e outros gerenciadores de pacotes.
- Variáveis de ambiente e arquivos de configuração com credenciais.
- Informações do repositório, commits recentes e artefatos de execução.
Depois de executar o código, os atacantes revertiam as alterações, às vezes em menos de um minuto, e apagavam os registros de execução quando podiam.
Isso complica bastante a detecção, porque um repositório pode parecer normal mesmo que suas credenciais tenham ficado expostas.
💻 Também foram detectados pacotes afetados
A investigação identifica como maliciosa a versão 3.14.3 do pacote
digitalelvis/neuronai-studio, publicado no Packagist.O próprio repositório de pacotes exibe um aviso relacionado a malware.
Também são mencionadas duas versões do módulo Go
github.com/onuragtas/docker-env:v1.0.278v1.0.280
No caso do módulo Go, o código malicioso estava em arquivos do GitHub Actions e não no código do módulo nem nos seus binários.
Portanto, instalar esse módulo não significa necessariamente ter executado o malware, embora os pesquisadores recomendem evitar essas versões.
🔎 Como verificar se o seu repositório pode estar afetado
A Aikido publicou vários indicadores que podem ajudar a identificar essa campanha.
Branches suspeitas:
Inserir CODE, HTML ou PHP:
wfx-docs
chore/[a-z0-9]{8}
ci-check-[0-9]{4}Os dois últimos padrões representam nomes de branches variáveis, não nomes literais.
Título de pull request utilizado:
Inserir CODE, HTML ou PHP:
docs: dependency audit notesMensagens de commits relacionadas:
Inserir CODE, HTML ou PHP:
ci: refresh build cache
chore: add ci helper
chore: add dependency audit workflow
ci: restore
ci: cleanupTambém foram identificados arquivos com nomes parecidos com:
Inserir CODE, HTML ou PHP:
.ci-xxxxxx.sh
.github/workflows/build-audit-xxxxxx.ymlEm alguns casos, os atacantes modificavam o arquivo
package.json para executar scripts por meio de postinstall.Identificador SHA-256 do script malicioso:
Inserir CODE, HTML ou PHP:
89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cfEndereços usados para receber os dados roubados:
Inserir CODE, HTML ou PHP:
194.150.166[.]244:8080/exfil
18.143.168[.]96:8080/exfilImportante: encontrar algum desses indicadores não prova por si só que credenciais foram roubadas, mas é motivo suficiente para investigar.
Além disso, a ausência de arquivos suspeitos ou de registros de execução também não garante que um repositório esteja limpo, porque os atacantes tentavam apagar seus rastros.
🛡️ O que fazer se você encontrar algum desses sinais?
Se vocês usam o GitHub para gerenciar projetos, vale revisar os pull requests, os commits e o histórico do GitHub Actions desde 10 de novembro.
Se encontrarem atividade suspeita:
- Revisem a segurança da conta do GitHub, suas sessões, tokens pessoais, chaves SSH e aplicativos autorizados.
- Verifiquem quais repositórios podiam ser modificados a partir dessa conta.
- Investiguem os workflows suspeitos e as execuções apagadas.
- Se for confirmado que o código malicioso chegou a ser executado, revoguem e substituam todas as credenciais às quais ele podia ter acesso.
- Revisem os acessos à AWS, Azure, Google Cloud e outros serviços conectados.
- Verifiquem se os atacantes não criaram novos usuários, chaves ou permissões para manter o acesso.
Um detalhe especialmente preocupante é que os pesquisadores encontraram técnicas que podiam manter o acesso mesmo depois de trocar determinadas credenciais.
Por exemplo, o malware podia modificar políticas de confiança da AWS ou adicionar credenciais de identidade federada no Azure.
Por isso, trocar as senhas ou os tokens nem sempre é suficiente: também é preciso revisar as permissões e as configurações de segurança.
🔗 Tem relação com os ataques de outubro?
A Aikido encontrou coincidências com contas afetadas pela campanha GhostAction de outubro passado.
Segundo os pesquisadores, as contas comprometidas durante aquela campanha tinham uma probabilidade muito maior de aparecer também neste novo ataque.
Em mais de 100 repositórios, o novo código malicioso foi adicionado a arquivos usados anteriormente pelo GhostAction.
No entanto, ainda não há provas suficientes para afirmar que os dois ataques sejam obra do mesmo grupo.
A infraestrutura e as técnicas utilizadas apresentam diferenças, e as credenciais roubadas podem acabar nas mãos de atacantes diferentes.
Também não se sabe publicamente como eles conseguiram inicialmente as credenciais das 4.837 contas.
📅 O que se sabe em 12 de novembro de 2026?
Por enquanto, os principais números conhecidos são:
- 4.837 contas do GitHub usadas pelos atacantes.
- 61.764 repositórios que receberam solicitações de teste.
- Pelo menos 1.806 repositórios onde o código malicioso chegou a ser executado.
- Uma versão maliciosa identificada no Packagist.
- Duas versões de um módulo Go com workflows maliciosos.
Esses números vêm de repositórios públicos que puderam ser analisados.
Os pesquisadores alertam que também podem existir repositórios privados afetados.
Além disso, foram detectadas novas solicitações suspeitas durante a manhã de 12 de novembro, embora não tenha sido possível confirmar se chegaram a executar o malware.
Não foi demonstrado que os servidores do GitHub tenham sido hackeados diretamente.
O que está documentado é o uso de credenciais de contas comprometidas para agir sobre repositórios com permissões de escrita.
Para quem usa o GitHub em projetos web, aplicativos ou deploys automatizados, vale a pena revisar as contas e os repositórios, especialmente se tivermos chaves de API ou credenciais de servidores configuradas.
Não é preciso que alguém consiga diretamente a senha do nosso servidor: se conseguir executar código em um workflow com permissões suficientes, pode acessar informações igualmente sensíveis.
🔗 Fontes
Importante: as informações correspondem às investigações publicadas em 12 de novembro de 2026.
O alcance do ataque pode mudar à medida que surgirem novos dados.