Pesquisadores dizem que GitHub ignorou alertas sobre falhas usadas por hackers

O GitHub rejeitou dois relatórios formais de vulnerabilidade que apontavam falhas de design exploradas por variantes do worm de cadeia de suprimentos Shai-Hulud, segundo pesquisadores da Deep Specter Research. De acordo com o grupo de inteligência de ameaças, os problemas vêm sendo usados para infectar e comprometer centenas de pacotes de software e contas de desenvolvedores em diferentes partes do mundo.

Os relatórios foram enviados pela Deep Specter por meio do canal de divulgação de bugs do GitHub no HackerOne. Ambos foram encerrados como inelegíveis e classificados como não representando risco de segurança, apesar da atividade em curso associada ao worm. Para os pesquisadores, as falhas não são apenas questões de implementação do Git, mas recursos que, combinados com credenciais comprometidas e baixa visibilidade para revisores, facilitam a ocultação de alterações maliciosas em repositórios.

Embora a ferramenta de ataque tenha surgido inicialmente ligada ao grupo de cibercrime TeamPCP, outras entidades passaram a usar versões ligeiramente modificadas depois que o código original foi publicado no início de maio. Nos últimos meses, variantes do Shai-Hulud foram associadas a incidentes envolvendo a Comissão Europeia, a empresa de recrutamento com inteligência artificial Mercor, o pacote LiteLLM, o próprio GitHub e a Red Hat.

A Deep Specter afirmou à Recorded Future News que sua investigação, conduzida apenas com dados públicos, confirmou a existência de 516 pacotes maliciosos ainda ativos em cinco ecossistemas, incluindo npm, PyPI e RubyGems. O levantamento também identificou mais de 3 mil repositórios do GitHub afetados e mais de 200 contas de desenvolvedores comprometidas.

Segundo a empresa, esses números devem ser tratados como um piso, não como o total real da campanha. Em relatório técnico, a Deep Specter observou que a busca de código do GitHub não indexa arquivos acima de determinado limite de tamanho. Isso torna invisível para varreduras automatizadas o principal payload do worm, um arquivo ofuscado com aproximadamente 4,6 MB.

O primeiro relatório enviado ao GitHub tratava da forma como a plataforma lida com timestamps de commits. Na prática, quem envia o código pode definir livremente a data em que uma alteração parece ter sido adicionada ao repositório. De acordo com a Deep Specter, o worm explora esse comportamento para fazer com que mudanças maliciosas recentes pareçam edições rotineiras feitas anos antes, dificultando a detecção por defesas que analisam o histórico do repositório em busca de atividades suspeitas recentes.

O GitHub respondeu aos pesquisadores que os timestamps de commits são metadados fornecidos pelo cliente por design. Na avaliação da empresa, o problema de segurança subjacente seria o uso de credenciais comprometidas para enviar o código, e não o timestamp em si.

O segundo relatório da Deep Specter tratava da autoria exibida nos commits. O GitHub mostra nome, foto e usuário dos autores como se esses dados estivessem confirmados. Porém, na prática, esses campos podem ser definidos livremente pelo invasor e não são verificados. O Shai-Hulud usa esse comportamento para fazer commits maliciosos parecerem ter sido feitos por engenheiros confiáveis que nunca interagiram com aquele código.

Nesse caso, o GitHub afirmou que metadados arbitrários de autoria são uma característica do sistema de controle de versão Git, não uma vulnerabilidade específica da plataforma. A empresa também informou que sua documentação de bug bounty lista explicitamente a personificação de autores de commits como uma descoberta conhecida e inelegível para recompensa.

Como mitigação, o GitHub apontou aos pesquisadores o uso de assinatura de commits com GPG e SSH, além do Vigilant Mode, recurso opcional que sinaliza commits não verificados. No entanto, os desenvolvedores cujas identidades foram falsificadas na campanha Shai-Hulud não haviam habilitado esses controles.

A Deep Specter também destacou outro ponto considerado relevante para a segurança: o GitHub registra qual conta efetivamente enviou cada commit, um dado que não pode ser falsificado, por meio da Events API. Essa informação, porém, não aparece na página de commit normalmente visualizada por revisores. Além disso, o registro deixa de ficar publicamente acessível após aproximadamente 90 dias.

Os pesquisadores defenderam que tornar esses dados mais visíveis ajudaria equipes de segurança e mantenedores de projetos a diferenciar autores declarados de contas que realmente fizeram o push do código. O GitHub, no entanto, classificou a sugestão como uma solicitação de funcionalidade, não como uma correção de segurança.

Em 16 de junho, a Deep Specter informou que 1.729 repositórios descartáveis criados pelo worm para armazenar credenciais roubadas ainda estavam ativos no GitHub. A empresa também identificou 151 repositórios que continuavam servindo payloads maliciosos. Os números foram descritos como um retrato dos dados públicos disponíveis naquela data.

A cadeia de ataque descrita pelos pesquisadores combina comprometimento de credenciais, abuso de metadados do Git e manipulação da aparência dos commits. Primeiro, os invasores obtêm acesso a contas de desenvolvedores ou tokens válidos. Em seguida, usam esse acesso para inserir código malicioso em pacotes e repositórios. Para reduzir a chance de detecção, os operadores da campanha alteram timestamps e campos de autoria, fazendo com que mudanças recentes pareçam antigas ou atribuídas a pessoas confiáveis. Em paralelo, repositórios descartáveis são usados para armazenar dados roubados e payloads que sustentam a propagação do worm.

O impacto desse tipo de campanha é particularmente grave porque atinge a cadeia de suprimentos de software. Pacotes publicados em ecossistemas como npm, PyPI e RubyGems podem ser incorporados por milhares de projetos, aplicações corporativas e pipelines de desenvolvimento. Quando um pacote comprometido é instalado ou atualizado, o código malicioso pode alcançar ambientes de build, credenciais de desenvolvedores, tokens de acesso e sistemas internos.

O caso também expõe uma tensão recorrente entre pesquisadores e grandes plataformas sobre o que deve ser tratado como vulnerabilidade de segurança. Para o GitHub, os comportamentos relatados fazem parte do funcionamento esperado do Git ou são mitigáveis por recursos já existentes, como assinatura de commits. Para a Deep Specter, a combinação desses comportamentos com o uso real em campanhas ativas cria uma superfície de ataque que merece tratamento mais direto pela plataforma.

A discussão ocorre em um momento de maior pressão sobre empresas de tecnologia quanto à forma como recebem, avaliam e respondem a relatórios de segurança. Na semana anterior, a Microsoft lançou correções para mais de 200 falhas de segurança, o maior Patch Tuesday da história do programa, em um contexto no qual a inteligência artificial vem acelerando tanto a descoberta quanto a exploração de vulnerabilidades.

A Microsoft também enfrentou críticas recentes sobre suas políticas de divulgação, depois de precisar esclarecer que não tinha intenção de tomar medidas contra pesquisadores de segurança. A reação veio após preocupação da comunidade sobre possíveis consequências para profissionais que divulgam falhas. Pesquisadores têm reclamado repetidamente que relatórios legítimos são descartados de forma injusta por grandes fornecedores.

Em outro caso recente, um pesquisador publicou um exploit separado para roubo de tokens do GitHub direcionado a repositórios da Microsoft. A divulgação pública ocorreu após insatisfação com a forma como a empresa lidou com relatórios de segurança, reforçando o debate sobre transparência, resposta coordenada e limites entre comportamento esperado de plataformas e risco prático para ecossistemas de desenvolvimento.

Para mantenedores e equipes de segurança, a campanha Shai-Hulud amplia a necessidade de controles adicionais sobre repositórios e pipelines. Assinatura obrigatória de commits, revisão de permissões, rotação de tokens, monitoramento de eventos de push, verificação de pacotes publicados e análise de dependências passam a ser medidas críticas em ambientes onde bibliotecas de terceiros fazem parte da operação diária.

A atividade também reforça que ataques de supply chain não dependem apenas de vulnerabilidades tradicionais. Muitas vezes, os invasores exploram comportamentos legítimos de plataformas, fragilidades de governança e confiança excessiva em metadados visuais. Quando esses elementos se combinam com credenciais válidas, a detecção se torna mais difícil e o impacto pode se espalhar rapidamente por múltiplos ecossistemas de software.