Tags de ações do GitHub foram redirecionadas para commit impostor para roubo de credenciais de CI/CD

O comprometimento afetou actions-cool/issues-helper e tags de actions-cool/maintain-one-comment, fazendo execuções de workflows buscarem código malicioso capaz de exfiltrar credenciais para t.m-kosche[.]com.

Componente	Workflows do GitHub Actions que usam actions-cool/issues-helper ou tags comprometidas de actions-cool/maintain-one-comment.
Vetor	Tags existentes foram movidas para um commit impostor fora do histórico normal do repositório; workflows que referenciam a ação por versão baixam esse código na próxima execução.
Impacto	Execução de código malicioso dentro do runner do GitHub Actions, coleta de credenciais sensíveis disponíveis no pipeline e exfiltração por HTTPS para domínio controlado pelo atacante.
Prioridade	Identificar workflows que referenciam essas ações por tag, interromper execuções, migrar para SHA completo conhecido como íntegro e rotacionar segredos expostos ao job.
Artefatos	Ação actions-cool/issues-helper, ação actions-cool/maintain-one-comment, commit impostor e domínio t.m-kosche[.]com.
IoCs	Conexões HTTPS de runners ou ambientes de CI/CD para t.m-kosche[.]com durante execuções de workflows que carregam as ações afetadas.
Mitigação	Fixar dependências de GitHub Actions em SHA completo validado, revisar permissões de GITHUB_TOKEN, reduzir segredos disponíveis por job e auditar logs de execução.

Resumo técnico

Um ataque de cadeia de suprimentos comprometeu o fluxo de execução de ações populares do GitHub Actions ao alterar tags usadas por consumidores do projeto actions-cool/issues-helper. Em vez de resolverem para commits esperados dentro do histórico normal do repositório, as tags passaram a apontar para um commit impostor. Esse tipo de manipulação é especialmente perigoso em CI/CD porque muitos workflows referenciam ações por tags de versão, como uma forma de acompanhar atualizações sem alterar o arquivo de configuração a cada lançamento. Quando a tag é reatribuída, o consumidor continua vendo uma referência aparentemente legítima no YAML, mas o runner passa a baixar e executar outro conteúdo no próximo disparo do workflow.

O código associado ao commit impostor foi preparado para rodar dentro do runner do GitHub Actions e coletar credenciais sensíveis disponíveis no contexto da execução. O impacto depende dos segredos, tokens e permissões efetivamente expostos ao job atingido, mas a condição técnica central é clara: qualquer workflow que carregue a ação comprometida por tag passa a entregar ao código malicioso o mesmo nível de acesso concedido àquela etapa do pipeline. A exfiltração observada usa uma chamada HTTPS para t.m-kosche[.]com, o que transforma logs de rede, registros de workflow e trilhas de auditoria de segredos em fontes relevantes para resposta ao incidente.

O comprometimento não ficou limitado ao actions-cool/issues-helper. Quinze tags associadas a uma segunda ação, actions-cool/maintain-one-comment, também foram afetadas com a mesma funcionalidade maliciosa. O repositório foi posteriormente desabilitado no GitHub por violação dos termos de serviço, mas essa medida não elimina automaticamente o risco em ambientes que já executaram os workflows durante a janela de exposição. A resposta defensiva deve tratar a situação como possível execução de código não confiável em CI/CD, com revisão de histórico de jobs, rotação de credenciais e mudança de política para fixação por SHA completo validado.

Fluxo técnico

O ponto técnico que torna o ataque efetivo é a diferença entre referenciar uma ação por tag e referenciar uma ação por um identificador imutável. Em um workflow do GitHub Actions, uma etapa pode usar uma ação externa com sintaxe baseada em repositório e versão. Quando a versão é uma tag, a resolução depende do estado atual dessa tag no repositório remoto. Se um invasor consegue mover a tag para outro commit, o arquivo YAML do consumidor não precisa mudar para que a próxima execução baixe conteúdo diferente. A alteração ocorre no lado da dependência, fora do processo normal de revisão do repositório que consome a ação.

O commit impostor descrito no caso não pertence ao caminho histórico esperado do projeto original. Essa característica permite contornar controles que se concentram em pull requests, diffs revisados e histórico visível de commits dentro do repositório confiável. O consumidor enxerga a mesma referência de tag, mas o runner resolve a tag para um objeto que contém lógica de coleta e transmissão de dados. Como ações executam comandos dentro do ambiente do job, o código malicioso pode acessar variáveis de ambiente, arquivos temporários, tokens injetados no contexto da execução e credenciais disponibilizadas explicitamente para etapas do pipeline, desde que esses dados estejam presentes naquele job.

A exfiltração observada ocorre por uma requisição HTTPS para t.m-kosche[.]com. A presença de HTTPS reduz a visibilidade de conteúdo em inspeções simples de rede, mas não oculta metadados como destino, horário, runner, workflow, repositório e job responsável pela conexão. O domínio também foi observado em atividade recente vinculada à campanha Mini Shai-Hulud contra pacotes npm do ecossistema @antv, o que cria uma sobreposição relevante entre dois conjuntos de atividade. Essa relação deve ser tratada como correlação técnica baseada em infraestrutura compartilhada; o caminho inicial usado para alterar as tags das ações não foi confirmado no material analisado.

Superfície afetada

A superfície principal inclui repositórios que executaram workflows do GitHub Actions usando actions-cool/issues-helper por tag durante o período em que as tags estavam redirecionadas. Também entram no escopo workflows que usaram qualquer uma das quinze tags comprometidas de actions-cool/maintain-one-comment. A exposição não depende de interação manual do mantenedor no repositório consumidor depois da alteração da tag; basta que o workflow seja acionado por evento configurado, como push, pull request, rotina agendada ou disparo manual, para que o runner resolva a referência externa e carregue o conteúdo apontado pela tag naquele momento.

O impacto real varia conforme o desenho do pipeline. Jobs com permissões amplas de GITHUB_TOKEN, segredos de publicação, credenciais de nuvem, tokens de gerenciadores de pacotes ou chaves de automação disponíveis no ambiente têm risco maior, porque o código da ação roda com acesso ao contexto entregue à etapa. Ambientes que limitam segredos por ramificação, usam permissões mínimas por workflow e isolam tarefas de publicação reduzem o alcance da coleta, mas ainda precisam verificar execuções passadas. Workflows fixados em SHA completo previamente conhecido como íntegro não são afetados pela movimentação das tags, pois a resolução não acompanha o novo destino da tag.

Além dos repositórios diretamente dependentes das ações, organizações devem avaliar pipelines descendentes. Um token roubado de CI/CD pode permitir publicação de pacote, alteração de release, acesso a registro de artefatos, leitura de repositórios privados ou modificação de infraestrutura, dependendo das permissões concedidas. A investigação deve mapear não apenas o workflow onde a ação foi chamada, mas também quais credenciais estavam disponíveis naquele job, quais sistemas aceitam essas credenciais e quais operações foram possíveis durante e após a execução comprometida.

• Workflows que usam actions-cool/issues-helper por tag em vez de SHA completo.
• Workflows que usam tags comprometidas de actions-cool/maintain-one-comment.
• Jobs que expõem segredos, tokens de publicação, credenciais de nuvem ou permissões amplas de GITHUB_TOKEN.
• Execuções acionadas após o redirecionamento das tags para o commit impostor.
• Pipelines que reutilizam artefatos, caches ou credenciais produzidos por jobs que carregaram as ações afetadas.

Hunting e telemetria

A primeira linha de hunting deve combinar busca estática em repositórios com análise de execuções históricas. Em código, procure referências a actions-cool/issues-helper e actions-cool/maintain-one-comment nos arquivos de workflow, normalmente em .github/workflows/. O objetivo é distinguir referências por tag de referências por SHA completo. Referências por tag indicam que o workflow ficou dependente do estado remoto da tag no momento da execução; por isso, a triagem deve levantar quais jobs rodaram depois do redirecionamento e quais segredos estavam disponíveis em cada um deles.

Nos logs do GitHub Actions, revise o momento em que a ação foi baixada, o identificador resolvido, os passos executados e quaisquer mensagens incomuns antes de chamadas externas. Logs de rede do runner, quando disponíveis, devem ser consultados em busca de conexões para t.m-kosche[.]com. Em runners hospedados pelo próprio GitHub, a visibilidade de rede pode ser limitada, o que aumenta a importância de logs de workflow, auditoria de segredos, eventos de token e trilhas nos serviços que aceitam as credenciais usadas pelo pipeline. Em runners auto-hospedados, registros de proxy, DNS, EDR e firewall podem confirmar tentativa de saída para o domínio de exfiltração.

A análise de identidade deve se concentrar no uso posterior de credenciais que poderiam ter sido coletadas. Verifique eventos de login, geração de tokens, publicação de pacotes, alteração de releases, criação de chaves, acesso a repositórios privados e operações administrativas em provedores de nuvem ou registros de artefatos. O fato de o domínio aparecer também em atividade Mini Shai-Hulud contra pacotes @antv justifica enriquecimento de threat intel, mas não substitui evidência local. A organização deve separar correlação de infraestrutura de confirmação de comprometimento: a presença da ação vulnerada no workflow indica exposição, enquanto conexões, uso indevido de credenciais ou alterações não autorizadas indicam impacto observado.

• Busca por actions-cool/issues-helper e actions-cool/maintain-one-comment em .github/workflows/.
• Execuções de workflows que resolveram ações por tag depois da alteração das tags.
• Conexões HTTPS, consultas DNS ou eventos de proxy envolvendo t.m-kosche[.]com.
• Jobs com segredos disponíveis no ambiente ou permissões elevadas de GITHUB_TOKEN.
• Eventos posteriores de publicação, alteração de release, uso de token, acesso a nuvem ou mudança em registros de pacotes.

Mitigação

A contenção deve começar pela interrupção ou desabilitação temporária de workflows que chamam as ações afetadas por tag. Em seguida, substitua referências mutáveis por SHAs completos validados. Essa alteração precisa ser acompanhada de revisão do commit fixado, porque fixar um SHA só protege se o objeto escolhido for conhecido como íntegro. Onde a ação não for indispensável, remova a dependência até que exista uma alternativa auditada. Para organizações com muitos repositórios, a busca deve ser centralizada por código, inventário de dependências de CI/CD ou regras de governança que detectem ações externas não fixadas.

A rotação de credenciais deve ser orientada pela exposição real do job, não apenas pela presença da ação no repositório. Liste cada execução potencialmente afetada, identifique variáveis, segredos e permissões disponíveis e rotacione tokens que poderiam ter sido acessados pelo código da ação. Isso inclui credenciais de publicação, chaves de nuvem, tokens de registro de pacotes, segredos de deploy e qualquer token com escopo para repositórios privados. Também é necessário revisar logs dos serviços que aceitam essas credenciais, porque o uso indevido pode ocorrer fora do GitHub depois da coleta inicial.

Como melhoria estrutural, aplique permissões mínimas para GITHUB_TOKEN, segmente segredos por ambiente, limite exposição de credenciais a jobs específicos e evite entregar segredos a workflows disparados por eventos de maior risco. Caches e artefatos produzidos por execuções suspeitas devem ser invalidados quando puderem carregar conteúdo manipulado ou metadados sensíveis. Regras de proteção de ramificação e revisão de pull request continuam importantes, mas não bloqueiam sozinhas esse padrão de ataque, porque a alteração ocorreu na dependência externa resolvida por tag. O controle mais direto contra esse vetor é tratar dependências de CI/CD como código executável de alto privilégio e fixá-las em identificadores imutáveis revisados.

• Pausar workflows que usam as ações afetadas por tag e revisar execuções recentes.
• Trocar referências de tags por SHA completo conhecido como íntegro.
• Rotacionar segredos expostos aos jobs que executaram as ações comprometidas.
• Reduzir permissões de GITHUB_TOKEN e escopos de credenciais usadas em CI/CD.
• Auditar logs de rede, identidade, pacotes, nuvem e repositórios para uso posterior de credenciais.
• Invalidar caches e artefatos gerados por execuções consideradas suspeitas.