O npm corrigiu uma falha no recurso de publicação confiável (Trusted Publishing) que deixava mais de 1.500 pacotes expostos a sequestro, segundo pesquisa da Bloom Security divulgada em 13 de outubro de 2026. Para quem mantém pacotes no registro ou instala dependências de forma automática, a mudança obriga a conferir quais repositórios estão ligados a cada pacote.
Como o nome de um repositório virou brecha de segurança
O recurso, lançado em julho de 2025, liga o direito de publicar um pacote ao nome do repositório no GitHub, no formato dono/repositório, e não ao número de identificação permanente dele. O número chega ao npm dentro do token do GitHub, mas era ignorado até a primeira publicação bem-sucedida, como descreve a reportagem do The Hacker News.
Se o mantenedor renomeia, transfere ou apaga o repositório, o nome antigo fica livre para qualquer pessoa. Um invasor cria um repositório com esse nome, monta um fluxo de publicação e troca o token gerado por uma credencial temporária do npm. Com ela, publica uma versão maliciosa do pacote alheio, que herda nome, reputação e downloads. Não é preciso roubar a senha de ninguém.
“É como uma fechadura que confere o endereço da porta, e não quem é dono da casa”, explicou Golan Myers, da Bloom Security.
Quantos pacotes estavam em risco e o que mudou no npm
A Bloom Security encontrou mais de 1.500 pacotes vulneráveis, que somam mais de 10 milhões de downloads. A empresa contou ter reportado o problema ao GitHub em 6 de junho de 2026, e o último retorno da equipe do npm veio em 8 de julho. Segundo os pesquisadores, agentes de IA que resolvem dependências sozinhos poderiam puxar uma versão maliciosa sem revisão humana.
O GitHub registrou a correção em um changelog de 2 de outubro de 2026. Configurações de publicação confiável que nunca publicaram nada expiram 48 horas depois de criadas e passam a valer sem prazo após a primeira publicação. O npm também rejeita tokens gerados por eventos issue_comment do GitHub Actions. Os pesquisadores testaram o ataque em um escopo do npm que eles mesmos controlavam.
O que você acha? Você acredita que o registro deveria validar a identidade numérica do repositório desde o primeiro dia? Para acompanhar mais, acesse nossa editoria de Cibersegurança.
Perguntas Frequentes
O que é a falha SlugFest encontrada no npm Trusted Publishing?
SlugFest é o nome dado pela Bloom Security a uma falha na publicação confiável do npm. O sistema reconhecia o repositório pelo nome, e não pelo número permanente. Quando o nome ficava livre depois de uma renomeação, transferência ou exclusão, outra pessoa podia reivindicá-lo e obter permissão para publicar versões do pacote.
Quais pacotes do npm ficaram expostos ao sequestro?
Pacotes com publicação confiável ligada a um repositório que nunca havia publicado no npm ficaram expostos ao ataque. A Bloom Security contou mais de 1.500 nessa situação, com mais de 10 milhões de downloads somados. Também era necessário que o nome do repositório vinculado estivesse livre para ser reivindicado por terceiros.
O que mantenedores devem fazer depois da correção do npm?
Bloom Security recomenda que mantenedores listem as ligações com o comando npm trust list e confiram se cada nome ainda aponta para um repositório sob seu controle. Se houve renomeação ou transferência, a orientação é apagar a ligação e criá-la de novo, além de monitorar publicações que não partiram deles.
