Duas GitHub Actions (recursos de automação da plataforma GitHub) do projeto actions-cool foram desativadas pela segunda vez depois que os repositórios ficaram acessíveis na semana passada, meses após serem comprometidos durante a campanha Mini Shai-Hulud de maio de 2026.
As GitHub Actions afetadas estão listadas abaixo:
Ao acessar qualquer um dos repositórios agora, é exibida a mensagem: "O acesso a este repositório foi desativado pela equipe do GitHub devido a uma violação dos termos de serviço do GitHub. Se você é o proprietário do repositório, pode entrar em contato com o suporte do GitHub para obter mais informações."
"Em 16 de setembro de 2026, ambos os repositórios voltaram a ficar acessíveis", afirmou o pesquisador da Socket, Karlo Zanki. "As tags de lançamento não foram limpas antes. Elas ainda apontam para o conteúdo malicioso introduzido em 18 de maio, então qualquer workflow (fluxo de trabalho automatizado) que referencie qualquer uma das ações por uma tag de versão voltou a baixar e executar o payload (código malicioso) na próxima execução."
Os dois workflows do GitHub Actions foram originalmente comprometidos em 18 de maio de 2026 para executar código malicioso que coletava credenciais sensíveis de pipelines de CI/CD (Integração Contínua e Entrega Contínua) que os executavam, e enviavam os dados para um servidor controlado pelo atacante.
A atividade foi posteriormente vinculada ao cluster de atividades Mini Shai-Hulud, citando sobreposições no domínio de exfiltração ("t.m-kosche[.]com") usado nos workflows do GitHub Actions e nos pacotes npm (gerenciador de pacotes do Node.js) do ecossistema @antv.
"Isso aponta para o mesmo cluster de atividades Mini Shai-Hulud, não para um incidente separado apenas no npm", disse Philipp Burckhardt, chefe de inteligência de ameaças da Socket, ao The Hacker News na época.
Os repositórios foram reativados em 16 de setembro de 2026, em algum momento entre 11h09 e 18h16 no fuso GMT+2. Atualmente, não se sabe por que isso aconteceu.
Mas o desenvolvimento mais recente aponta para outro problema: o código malicioso permaneceu nas bases de código afetadas e nunca foi limpo, e tudo o que foi necessário para ativar a ameaça foi que os repositórios voltassem a ficar disponíveis para download.
Dado que ainda existem vários workflows que usam as duas GitHub Actions, a exposição poderia ter levado a riscos severos de segurança na cadeia de suprimentos de software, sem a necessidade de os agentes de ameaça usarem um novo exploit (código de exploração) ou montarem uma nova infraestrutura.
"Ambas as ações automatizam a organização de issues (relatórios de problemas) e comentários, como fechar issues inativas, verificar novos relatos abertos ou manter um único comentário de bot atualizado", disse a Socket.
"Os workflows que as chamam geralmente são executados em uma programação diária ou sempre que alguém abre uma issue ou pull request (solicitação de mesclagem de código). Na prática, a maioria dos repositórios afetados provavelmente executou o payload em até um dia após a reativação, sem necessidade de qualquer ação adicional por parte do agente de ameaça."
Recomendações para desenvolvedores
O problema não afeta workflows que fixam qualquer uma das ações no SHA (identificador hash de commit) completo de uma versão anterior a 18 de maio de 2026. Os desenvolvedores são recomendados a executar as seguintes etapas:
- Localizar todas as referências às ações afetadas e tratar "actions-cool/issues-helper@v2.2.1" como afetada.
- Remover as ações e fixá-las em um SHA conhecido como limpo, anterior a 18 de maio de 2026.
- Rotacionar todos os segredos expostos.
- Revisar o histórico de execuções dos workflows e verificar execuções bem-sucedidas recentes após um período prolongado de falhas em "Set up job" (etapa de preparação do trabalho).
- Auditar o histórico do repositório em busca de commits inesperados após 16 de setembro de 2026.
"A maioria dos incidentes de cadeia de suprimentos envolve algo novo: uma versão maliciosa recém-publicada, uma conta sequestrada ou um workflow recém-injetado", disse Zanki. "Este não foi o caso. Nenhum código novo foi publicado e nenhuma configuração foi alterada."
"Este incidente mostra que uma tag mutável pode ser comprometida, contida e depois reativada sem qualquer alteração no seu próprio arquivo de workflow. A fixação por SHA remove essa dependência do estado do repositório de origem."
