Duas ações do GitHub Actions de actions-cool comprometidas em maio e reativadas em setembro

Duas ações públicas do GitHub Actions mantidas pelo projeto actions-cool — actions-cool/issues-helper e actions-cool/maintain-one-comment — foram reativadas em 16 de setembro de 2026 e, depois disso, o GitHub as voltou a desactivar. É confirmado que essas ações haviam sido comprometidas em 18 de maio de 2026 para executar código malicioso destinado a extrair credenciais das canalizações de CI/CD que as invocassem e enviar esses dados a um servidor controlado pelos atacantes; a atividade foi associada publicamente ao cluster de ameaças conhecido como Mini Shai-Hulud. Segundo a pesquisa publicada pela assinatura Socket e declarações de sua equipe, as etiquetas de versão (tags) que apontavam para o código malicioso nunca foram eliminadas, pelo que a única condição necessária para reativar a ameaça foi que os repositórios retornam a ser acessíveis publicamente.

Tecnicamente, o vetor explorado aqui não exige publicar um novo release nem comprometer outra conta: muitos workflows do GitHub Actions referenciam essas ações mediante referências mutáveis (por exemplo, tags como @v2.2.1). Quando uma tag mutável foi apontada em maio para um commit que injetava um payload —capaz de ler segredos de ambiente ou do contexto do runner e de exfiltrarlos—, qualquer workflow que use esse tag descarga e executa esse conteúdo em tempo de execução. Socket também indicou que a exfiltração reutilizava um domínio observado anteriormente no incidente do ecossistema @antv (t.m-kosche[.]com), o que permitiu correlacionar ambas as campanhas com Mini Shai-Hulud. Essa reutilização de infraestrutura é um indicador técnico útil para atribuição e foi um fator chave para identificar a conexão entre compromissos de pacotes npm e o abuso de ações no GitHub.

Aqueles que são afetados são, em primeiro lugar, os mantenedores e usuários de repositórios que incorporam essas ações sem defini-las a um commit SHA específico anterior a 18 de maio. Na prática, isto inclui projetos que automatizam fechamento de issues, manutenção de comentários de bot ou cheques periódicos, porque esses workflows costumam ser executados com frequência (por exemplo, on: schedule ou on: issues/pull_request). Socket estima que a maioria dos repositórios que dependiam dessas ações puderam executar o payload dentro de um dia desde a reativação, dado o padrão de execução habitual, embora esse ponto seja uma projeção baseada em como se configuram tipicamente esses workflows e não a verificação de cada repositório individual.

As consequências técnicas importantes são várias e concretas: a exposição de tokens e segredos armazenados como variáveis de ambiente nas execuções de Actions pode permitir a um atacante escalar privilégios, acessar outros repositórios, publicar pacotes maliciosos em registros com credenciais roubadas ou manipular pipelines de entrega. Além disso, ao tratar-se de uma dependência na cadeia de fornecimento de desenvolvimento, a execução silenciosa do payload em múltiplos projetos multiplica o risco sem exigir novas vulnerabilidades ou infra-estruturas adicionais por parte do atacante — você deve que o código malicioso permaneça disponível sob a referência que os workflows consomem.

Atos confirmados: os compromissos iniciais de 18 de maio de 2026, a reativação de acesso entre as 11:09 e as 18:16 (GMT+2) de 16 de setembro de 2026, a observação de etiquetas que seguiam apontando para o conteúdo malicioso, a identificação do domínio de exfiltração e a intervenção posterior do GitHub para desativar os repos. Estimações razoáveis: a rapidez com que a maioria dos repositórios afetados poderia ter executado o payload após a reativação, baseada em padrões de execução típicos. Informação ainda incerta: a causa raiz de por que o GitHub permitiu de novo o acesso a esses repositórios em setembro e se houve uma intervenção humana, um erro automatizado ou um procedimento administrativo que revirou a suspensão prévia.

O que deve fazer uma equipe de desenvolvimento ou um administrador de repositório agora mesmo: localizar todas as referências às duas ações afetadas e tratar a referência actions-cool/[email protected] Como comprometida; remover essa dependência ou substituí-la por um commit SHA conhecido e limpo que seja anterior a 18 de maio de 2026; rodar imediatamente todos os segredos e Tokens que puderam ter estado disponíveis em execuções que utilizaram essas ações; revisar o histórico de execuções de workflows para detectar execuções bem sucedidas após a reativação ou por períodos invulgarmente breves em que antes falhavam os jobs; e auditar o histórico do repositório procurando commits inesperados com data posterior a 16 de setembro de 2026. Estas recomendações estão em linha com as práticas de mitigação contra o supply chain risks e com os avisos públicos de pesquisadores; o GitHub mantém um guia sobre o endurecimento de segurança para a Actions que inclui a recomendação de usar referências imutáveis (SHA) para evitar exatamente este tipo de reativações: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions.

Medidas técnicas concretas e prioritárias: Pintar todas as dependências de ações ao seu commit SHA completo (não a tags mutáveis), invalidar e rotar qualquer segredo exposto (tokens pessoais, segredos de repositório ou de organização) e rever as permissões atribuídas aos tokens para aplicar o princípio de menor privilégio. Além disso, convém ativar controles organizacionais como a revisão manual de ações externas, permitir apenas ações auditadas desde o Marketplace ou restringir a execução de ações a runners auto-hospedados com políticas de segurança mais rigorosas. Para verificar a reputação e a história de uma ação, os equipamentos podem ser apoiados em análises externas e em ferramentas de detecção de dependências —Socket é uma das assinaturas que publicou detalhes sobre esta campanha e mantém informações técnicas sobre a pesquisa na sua web: https://socket.dev/.

Interpretação: este incidente sublinha que a segurança da cadeia de abastecimento não depende apenas de prevenir novas publicações maliciosas; também requer controlar como se referenciam e invocam dependências. Uma etiqueta mutável comprometida pode ser contida e depois inadvertidamente reativada sem que o consumidor modifique seu próprio workflow, o que faz com que a prática de pinning a SHA deixe de ser uma recomendação teórica para ser uma necessidade operacional.

Por último, o que ainda precisa de esclarecer: o GitHub não fez público por que o acesso a esses repositórios foi restaurado e se tomar medidas para notificar de forma proativa os repositórios que dependiam deles. As organizações devem assumir que a incerteza persiste e agir como se qualquer ação referenciada pela tag mutável e potencialmente afetada fosse insegura até que se prove o contrário através de uma auditoria interna. O erro nesta matéria não é esperar que o GitHub emita um comunicado, mas não verificar por conta própria a integridade das dependências e não ter um processo de resposta rápida para a rotação de credenciais e a remediação de pipelines.