Uma vulnerabilidade na plataforma de hospedagem de código GitHub e no gerenciador de pacotes npm expôs mais de 1.500 pacotes de software a invasões, sem precisar roubar credenciais ou senhas. A falha, revelada por pesquisadores da empresa de cibersegurança Bloom Security, possibilitava a inclusão de arquivos maliciosos em programas legítimos, o que afetou diretamente ferramentas e agentes de inteligência artificial (IA) que baixam dependências de forma automática. Em resposta às descobertas, o GitHub alterou as regras de validação do sistema para conter o risco.
A brecha estava localizada no mecanismo “publicação confiável” (Trusted Publishing), lançado em julho do ano passado para substituir o uso de senhas e tokens de longa duração por credenciais temporárias. O sistema tinha como objetivo aumentar a segurança, porém apresentava uma vulnerabilidade na forma como identificava os repositórios de código.
Em vez de registrar o número de identificação permanente atribuído pelo GitHub, o npm checava apenas o endereço legível, conhecido como slug (formado pelo nome do proprietário e do projeto). Assim, caso um desenvolvedor trocasse o nome do perfil, transferisse ou apagasse o projeto, o endereço antigo ficava livre para ser registrado por qualquer outra pessoa e mantinha a confiança prévia do sistema.
A manobra, apelidada pelos pesquisadores de “SlugFest”, permitia que um invasor criasse um projeto com o mesmo endereço abandonado e emitisse atualizações maliciosas para um pacote legítimo já existente no npm. “A vulnerabilidade expõe pacotes legítimos e os invasores os comprometem. O agente de inteligência artificial faz a distribuição”, afirmou o analista de segurança Golan Myers, no relatório divulgado pela empresa.
O GitHub informou na documentação oficial da plataforma que passou a impor um prazo de 48 horas para que novas configurações de publicação confiável sejam validadas por meio do primeiro envio bem-sucedido de um pacote. Caso o envio não ocorra dentro desse intervalo de dois dias, a autorização expira automaticamente.
“Mudanças na identidade do repositório ou do projeto exigem uma nova relação de confiança com um novo prazo de validação de 48 horas, e edições comuns não reiniciam essa data limite”, declarou a subsidiária da Microsoft, em nota sobre a atualização do serviço.
A urgência para corrigir a falha aumentou com a popularização de assistentes de IA focados em programação, como Claude Code, Codex, Gemini e Cursor. Segundo dados levantados pela Bloom Security em empresas, cada agente automatizado instala dezenas de pacotes de software por mês para construir e atualizar programas, na maioria das vezes sem a interferência ou revisão direta de um ser humano. Se um pacote com reputação positiva é adulterado por meio do endereço reaproveitado, as ferramentas inteligentes puxam a versão mais recente e executam códigos no computador dos desenvolvedores sem emitir alertas.
Segundo o relatório, as descobertas foram comunicadas ao GitHub em 6 de junho. A empresa identificou que mais de 1.500 pacotes estavam expostos à brecha e acumulavam mais de 10 milhões de downloads no total. O encerramento definitivo do risco para novas configurações ocorreu após a implementação das regras de expiração e das atualizações de segurança lançadas neste mês.
Como funcionava o ataque aos pacotes de código
O problema central do sistema estava na diferença entre o nome público de um projeto e a identidade real nos servidores. Enquanto o GitHub gera números de identificação fixos que continuam iguais mesmo se o projeto mudar de nome, o npm ignorava esses números até que a primeira publicação oficial fosse realizada.
Para explorar a brecha, o invasor precisava apenas identificar um pacote cujo recurso de publicação confiável estivesse ativado, mas que nunca tivesse enviado uma versão ao npm, e cujo endereço no GitHub estivesse disponível após ter sido alterado pelo dono original. Assim, o criminoso criava um repositório com o mesmo nome na plataforma, configurava a rotina de envio automatizado e solicitava a validação. O sistema do npm comparava apenas o texto do endereço e liberava a autorização de publicação para o pacote do proprietário verdadeiro.
A imagem é esta: um invasor compromete um único pacote. Um agente de IA no dispositivo de um mantenedor popular o puxa autonomamente para um projeto. Aquele único ponto de acesso é usado para enviar código malicioso para o pacote popular. Todos os usuários do pacote ficam expostos. Tudo porque uma pessoa com o acesso correto foi exposta
Golan Myers, analista de segurança da Bloom Security
A partir desse momento, a versão adulterada passava a ser distribuída com o nome oficial do projeto, herdando o histórico de downloads e a reputação construída ao longo do tempo. O envio também gerava um comprovante de proveniência assinado automaticamente, o que podia enganar ferramentas de checagem que analisam apenas a presença da assinatura, sem checar a origem exata do projeto.
Riscos em bibliotecas e extensores de programas
Esse tipo de vulnerabilidade em nomes e endereços não se limita aos pacotes de código do npm. Em agosto de 2026, a Bloom Security identificou uma falha semelhante, batizada de “Extension Resurrection”, que afetou lojas de extensões para editores de código — como o VS Code Marketplace, da Microsoft, e o Open VSX.
Na ocasião, os pesquisadores descobriram que conjuntos de extensões recomendados para programadores citavam complementos que haviam sido apagados ou que nunca existiram nas plataformas. Bastava criar um perfil com o nome exato do criador ausente e publicar um arquivo com um número de versão superior para que a loja atualizasse o pacote automaticamente nos computadores de quem já usava o conjunto de ferramentas.
“Os invasores podiam reivindicar esses espaços vazios, publicar código malicioso neles e fazê-los ser instalados automaticamente junto com o pacote confiável, enviando atualizações silenciosas para qualquer pessoa que tivesse instalado o pacote anteriormente”, escreveu Golan Myers, na divulgação da pesquisa. O problema nas lojas de extensores foi comunicado às empresas responsáveis e corrigido após as notificações.
Para evitar contaminações por meio da brecha no npm, o especialista orienta que os mantenedores de programas revisem as autorizações de publicação conectadas aos perfis. Caso um projeto tenha mudado de nome ou de conta no GitHub, a recomendação é apagar a regra de confiança antiga e criar uma nova apontando para o endereço atualizado, além de realizar o primeiro envio de código imediatamente para fixar a identificação permanente da aplicação.
Siga o TecMundo no X, Instagram, Facebook e YouTube e assine a nossa newsletter para receber as principais notícias e análises diretamente no seu e-mail.
Meridiano
