SlugFest expôs 1.500 pacotes npm — o patch não encerra a auditoria

Na pesquisa da Bloom Security publicada em 13 de outubro de 2026, Golan Myers identificou mais de 1.500 pacotes npm potencialmente expostos ao SlugFest, com mais de 10 milhões de downloads acumulados, e resumiu a falha: “A name is not an identity.” Uma relação de Trusted Publishing ainda sem publicação inicial podia reconhecer o nome reutilizado de um repositório GitHub como se ele continuasse a identificar o projeto original.

A CSO relatou que os pesquisadores conseguiram publicar uma versão em um teste controlado, mas não observaram exploração ativa fora dele. A correção já estava implantada quando a pesquisa veio a público. Para mantenedores, resta conferir se as relações cadastradas em seus pacotes apontam para repositórios que ainda controlam.

Como um nome antigo herdava a autorização

O Trusted Publishing permite que um workflow do GitHub Actions publique no npm usando credenciais temporárias, sem armazenar um token permanente de publicação. A autorização associa o pacote ao caminho textual owner/repo e ao arquivo do workflow; também pode incluir um ambiente do GitHub Actions. Esse caminho é um nome que pode mudar de dono, não a identidade permanente atribuída pelo GitHub ao repositório.

O ponto vulnerável era o intervalo entre criar a relação e publicar pela primeira vez com ela. Antes dessa publicação, o npm ainda não havia registrado os identificadores permanentes do repositório e de seu proprietário. Embora esses identificadores estivessem no token de identidade emitido para o workflow, a verificação da relação pendente comparava o nome do repositório e o arquivo esperado.

Se o mantenedor renomeasse, transferisse ou excluísse o repositório vinculado, o endereço anterior poderia ficar disponível para outra pessoa. Enquanto a relação continuasse pendente, um projeto diferente que passasse a ocupar aquele endereço poderia obter uma credencial válida para publicar no pacote associado. O desvio aproveitava a autorização ligada ao nome reutilizável: não dependia de roubar a conta, a senha ou o token do mantenedor.

O que mudou com a correção

O changelog do GitHub de 2 de outubro de 2026 informa que configurações de Trusted Publishing ainda não validadas expiram 48 horas após a criação e deixam de autorizar publicações. A primeira publicação bem-sucedida valida a relação e a isenta desse prazo. A mudança reduz o tempo em que uma autorização pendente pode continuar associada a um nome de projeto que mudou de dono.

Uma configuração expirada permanece visível nas opções do pacote, mas precisa ser recriada para voltar a autorizar publicações. Alterar a identidade do repositório ou do projeto também exige uma nova relação; edições comuns não reiniciam o prazo. Outras configurações válidas do mesmo pacote não são afetadas pela expiração de uma relação pendente.

O npm passou ainda a recusar tokens de Trusted Publishing emitidos em eventos issue_comment do GitHub Actions, somando essa restrição à já aplicada a pull_request_target. Essa proteção trata do evento que originou o token. Ela não examina, por si só, se cada relação já cadastrada aponta para o repositório que o mantenedor pretende autorizar.

O que foi demonstrado e o que o levantamento mede

No teste, os pesquisadores usaram um pacote npm e repositórios sob seu controle. Depois que o endereço anteriormente associado ao projeto confiável ficou livre, conseguiram publicar uma versão do pacote a partir de um repositório pertencente a outra organização. O resultado demonstrou uma publicação autorizada pelo registro apesar da troca de identidade do repositório, sem comprometimento da conta legítima.

O levantamento identificou relações potencialmente vulneráveis, não uma lista de versões maliciosas encontradas no npm. Os pesquisadores não divulgaram os nomes dos pacotes classificados como expostos. Por isso, a contagem agregada não permite concluir que uma dependência específica tenha sido comprometida, nem substitui a análise de seu histórico de publicação.

Há uma distinção adicional na procedência das versões. Uma publicação feita por um repositório indevido poderia receber uma atestação válida que identificasse justamente aquele repositório. Verificar apenas a existência da atestação deixaria passar a pergunta decisiva: se a origem registrada corresponde ao projeto aprovado pelo mantenedor.

Quais vínculos antigos exigem revisão

A auditoria começa pelas relações de Trusted Publishing de cada pacote mantido. O endereço registrado no npm deve ser comparado com o repositório atualmente controlado pela equipe, sobretudo após mudanças de nome, transferências de organização ou exclusões. Também importa conferir o arquivo de workflow associado: a autorização envolve tanto a identidade textual do projeto quanto o fluxo de publicação esperado.

• Inventariar todas as relações do pacote, inclusive relações adicionais que possam autorizar uma publicação.
• Remover vínculos que apontem para nomes antigos ou repositórios fora do controle do mantenedor e criar relações para os projetos atuais.
• Examinar versões inesperadas e comparar sua procedência com o repositório aprovado para publicar o pacote.

Uma relação que já publicou passou pela validação descrita no funcionamento do recurso; a expiração anunciada se aplica às configurações ainda pendentes. Mesmo assim, a existência de uma relação validada não informa se ela continua necessária ou se o projeto associado ainda pertence à equipe. Para quem consome dependências, uma versão inesperada merece investigação de origem; a exposição apontada no levantamento, isoladamente, não é prova de código malicioso. O resultado da auditoria depende da correspondência concreta entre as relações mantidas no npm, os repositórios hoje autorizados e a procedência das versões publicadas.

Leia também:

• Memória do AgentCore expira por evento — mudar o prazo não salva o histórico
• Wimbledon não baniu influenciadores — regras antigas viraram notícia nova
• PaperCut sofre ataques ativos — até o primeiro patch precisa ser trocado