GitHub descarta dois relatórios de segurança sobre falhas exploradas pelo worm Shai-Hulud em ataques à cadeia de suprimentos

O GitHub fechou como “fora de escopo” dois relatórios formais de vulnerabilidade enviados pela Deep Specter Research por meio do canal oficial no HackerOne — falhas de design que, segundo os pesquisadores, estão sendo ativamente exploradas pelas variantes do worm Shai-Hulud para infectar pacotes e contas de desenvolvedores em escala global. O levantamento, baseado apenas em dados públicos, confirma 516 pacotes maliciosos atualmente vivos em cinco ecossistemas (incluindo npm, PyPI e RubyGems), mais de 3 mil repositórios afetados e mais de 200 contas de desenvolvedor comprometidas.

O que aconteceu

A Deep Specter Research, grupo de inteligência de ameaças que vem acompanhando o Shai-Hulud desde sua publicação original pelo coletivo TeamPCP no início de maio, encaminhou ao GitHub dois relatórios técnicos detalhando como o worm aproveita características do próprio Git e da plataforma para se disseminar e evadir detecção. O GitHub respondeu fechando ambos como inelegíveis para o programa de bug bounty, classificando os comportamentos descritos como propriedades intencionais do sistema de versionamento — e não como vulnerabilidades passíveis de correção.

O problema, argumentam os pesquisadores, é que mesmo sendo comportamentos “por design”, eles são instrumentais para a operação ofensiva de um worm que vem encadeando comprometimentos de alto perfil. Variantes do Shai-Hulud foram associadas a incidentes na Comissão Europeia, na empresa de recrutamento de IA Mercor, no pacote LiteLLM, no próprio GitHub e na Red Hat ao longo das últimas semanas.

De acordo com a Deep Specter, os números levantados representam um piso, não um teto: a busca de código do GitHub não indexa arquivos acima de um determinado tamanho, e o payload primário do worm — um arquivo ofuscado de aproximadamente 4,6 MB — fica invisível para varreduras automatizadas baseadas em pesquisa de código.

As duas falhas de design

O primeiro relatório descreve como o GitHub trata os timestamps de commit. Em Git, a data de um commit é metadado fornecido pelo cliente — qualquer pessoa que faça o push pode arbitrar quando “afirma” ter feito a alteração. O Shai-Hulud explora isso ao antedatar commits maliciosos para que pareçam edições rotineiras feitas anos atrás. Defensores que olham para o histórico recente em busca de atividade suspeita simplesmente não veem a inserção.

“O GitHub respondeu que timestamps de commit são metadados fornecidos pelo cliente por design e que o problema de segurança subjacente são as credenciais comprometidas usadas para enviar o código, não o timestamp”, relatou a Deep Specter.

O segundo relatório aponta a falta de verificação da autoria dos commits. O GitHub exibe nome, foto e usuário do autor como se fossem confirmados — mas, na prática, esses campos são livremente definidos pelo atacante. O worm usa essa lacuna para fazer commits maliciosos aparecerem como se tivessem sido feitos por engenheiros confiáveis que nunca tocaram no código. O GitHub respondeu que essa é uma propriedade do Git, não do GitHub, e que a personificação de autoria de commit é explicitamente listada como achado inelegível na documentação do programa de bug bounty.

A plataforma apontou GPG e SSH commit signing e o opt-in Vigilant Mode como mitigações disponíveis. Mas os desenvolvedores cujas identidades foram forjadas na campanha do Shai-Hulud não tinham esses controles habilitados — e, sem opt-in, a interface continua exibindo o nome falso sem qualquer indicador visual de que a autoria é não verificada.

O que continua ativo no GitHub agora

O retrato em 16 de junho, segundo a Deep Specter, é o seguinte:

• 516 pacotes maliciosos vivos em cinco ecossistemas, com presença confirmada em npm, PyPI e RubyGems.
• Mais de 3.000 repositórios afetados pelo worm em alguma forma.
• Mais de 200 contas de desenvolvedor comprometidas pelo Shai-Hulud e suas variantes.
• 1.729 repositórios descartáveis criados pelo worm para armazenar credenciais roubadas, ainda online no GitHub.
• 151 repositórios servindo payloads maliciosos ativos no momento do levantamento.

O GitHub mantém, em sua Events API, o registro de qual conta efetivamente fez o push de cada commit — informação essa que não pode ser forjada. O dado existe, mas não é exibido na página do commit visível ao revisor, e expira da visão pública em cerca de 90 dias. A Deep Specter sugeriu melhorar essa visibilidade como uma medida de segurança barata; o GitHub classificou o pedido como uma solicitação de funcionalidade (“feature request”), não como correção de segurança.

Quem é afetado

• Organizações que consomem pacotes npm, PyPI e RubyGems sem revisão de origem — especialmente equipes de IA e DevOps, que tendem a integrar dependências novas rapidamente.
• Mantenedores open source de pacotes populares, cuja identidade pode estar sendo forjada em commits maliciosos sem que tenham conhecimento.
• Times de revisão de código que se apoiam exclusivamente na interface do GitHub para identificar quem propôs uma mudança — o autor exibido pode ser ficção.
• Pipelines de CI/CD que executam scripts pós-instalação de pacotes npm ou PyPI sem sandboxing efetivo.

Análise

O atrito entre Deep Specter e GitHub ilustra uma fissura crescente no modelo de divulgação responsável. Programas de bug bounty operam com critérios bem definidos — e, dentro deles, o GitHub está tecnicamente correto: a personificação de autoria em commits é uma característica conhecida do Git, e timestamps client-supplied são parte do protocolo desde 2005. O problema é que critérios desenhados para uma era em que o Git era usado por equipes presenciais e pequenas não dão mais conta de um cenário onde a Git é a espinha dorsal de uma cadeia de suprimentos global de software.

Quando um worm consegue se aproveitar sistematicamente de “comportamentos esperados” para infectar centenas de pacotes, a distinção entre “vulnerabilidade” e “design choice” perde valor operacional. Os incidentes recentes — Nx Console, IronWorm no ecossistema Arweave, o ataque contra a Red Hat e agora a documentação detalhada da Deep Specter — convergem para o mesmo ponto: o ecossistema precisa de sinais visuais de confiança no nível da plataforma, não apenas controles opt-in que dependem da boa vontade do mantenedor.

Vale o paralelo com o GitHub anterior à introdução do Verified badge em e-mails de commit assinados: na época, o argumento era idêntico — “isso é Git, não GitHub”. Acabou sendo implementado, e tornou o ataque mais caro. A história tende a repetir-se aqui — a questão é quantos pacotes vão cair no intervalo.

Recomendações práticas

• Habilite Vigilant Mode nas configurações da sua conta GitHub — commits sem assinatura passam a ser marcados como “Unverified” em vez de exibirem nome do autor como se fosse confirmado.
• Configure assinatura GPG ou SSH para todos os commits dos mantenedores em repositórios sensíveis. Para times, considere torná-la obrigatória via branch protection rule “Require signed commits”.
• Audite commits recentes por origem real: a Events API expõe quem fez o push (em vez de quem aparece como autor) por aproximadamente 90 dias — vale roteirizar uma comparação para repositórios críticos.
• Para pacotes consumidos via npm/PyPI/RubyGems: fixe versões com lockfile, ative dependabot ou Renovate com revisão obrigatória, e prefira pacotes com 2FA exigido no publish.
• Bloqueie scripts de instalação no CI: use npm install --ignore-scripts em pipelines onde a execução de hooks não é estritamente necessária.
• Monitore os IOCs do Shai-Hulud publicados por Deep Specter, Aikido e Socket: 1.729 repositórios descartáveis ainda recebem credenciais roubadas, e bloqueá-los no egress reduz vazamento.

Fonte: The Record