O GitHub mudou as regras do trusted publishing do npm depois que pesquisadores da Bloom Security mostraram que mais de 1.500 pacotes podiam ser sequestrados sem roubo de credenciais. A correção foi publicada no changelog do GitHub em 2 de outubro de 2026, e a falha, batizada de SlugFest, foi detalhada publicamente em 13 de outubro de 2026.
Se você mantém pacotes no npm e publica pelo GitHub Actions, há configurações para revisar e, em alguns casos, refazer.
Em resumo: até a primeira publicação, o npm identificava o repositório confiável pelo nome (dono/repositório), e não pelo ID fixo. Quem registrasse um nome abandonado podia publicar versões do pacote. Agora, configurações não validadas expiram em 48 horas e tokens vindos de issue_comment são recusados. Revise seus vínculos e refaça os que apontam para repositórios renomeados ou transferidos.
Como o SlugFest permitia tomar um pacote
O trusted publishing troca tokens de longa duração por uma relação de confiança: o pacote no npm aceita publicações vindas de um workflow específico do GitHub Actions, autenticado por OIDC. O problema estava no intervalo entre criar essa relação e usá-la pela primeira vez. Segundo o The Hacker News, nesse período o vínculo era guardado pelo slug do repositório, e não pelo identificador numérico permanente.
O roteiro de ataque descrito pelos pesquisadores tinha quatro passos:
- O mantenedor configurava o trusted publishing apontando para um repositório, mas ainda não publicava por ele.
- Depois, o repositório era renomeado, transferido ou apagado, e o nome antigo ficava livre.
- Um atacante criava um repositório com o mesmo nome e disparava um workflow de publicação.
- O npm via o nome esperado, emitia a credencial e aceitava a versão maliciosa, que herdava downloads, reputação e dependentes do pacote original.
De acordo com o Daily Security Review, a falha foi encontrada por Golan Myers, da Bloom Security. Os pacotes vulneráveis somavam mais de 10 milhões de downloads. Não há relato público de exploração confirmada.
Linha do tempo da falha
| Data | O que aconteceu |
|---|---|
| 6 de junho de 2026 | Bloom Security reporta a falha ao GitHub |
| 2 de outubro de 2026 | Changelog do GitHub anuncia a expiração de configurações não validadas |
| 13 de outubro de 2026 | Pesquisadores publicam os detalhes do SlugFest |
Foram cerca de quatro meses entre o aviso e a mitigação, intervalo em que os pacotes ficaram expostos.
O nome SlugFest vem justamente do slug, o identificador em texto no formato dono/repositório. Diferente do ID numérico, que nunca muda, o slug pode ser reaproveitado por qualquer pessoa depois que o nome fica livre. É a mesma lógica de outros ataques à cadeia de suprimentos de software, em que o invasor não quebra nada: apenas ocupa um espaço que o sistema ainda considera confiável.
O que o GitHub mudou no npm
O changelog oficial do GitHub descreve as regras novas:
- Prazo de 48 horas: uma configuração de trusted publishing que não for usada numa publicação bem-sucedida em até 48 horas expira e deixa de autorizar publicações.
- Validação na primeira publicação: depois do primeiro uso, a configuração fica validada, isenta de expiração e presa à identidade imutável do repositório.
- Mudança de identidade exige vínculo novo: trocar o repositório ou o projeto cria uma relação de confiança nova, com nova janela de 48 horas. Edições comuns não reiniciam o prazo.
- Eventos bloqueados: o npm passou a recusar tokens emitidos em workflows disparados por issue_comment, somando-se ao bloqueio que já existia para pull_request_target.
Configurações expiradas continuam visíveis na tela de trusted publishers, mas não contam para o limite por pacote. As demais configurações do pacote seguem funcionando.
Checklist para quem mantém pacotes
- Abra as configurações de trusted publishing de cada pacote e confira se cada repositório listado ainda é seu e está com o mesmo nome.
- Se algum repositório foi renomeado, transferido ou apagado, exclua o vínculo e crie outro apontando para o endereço atual.
- Depois de criar um vínculo, publique dentro de 48 horas. Se não for publicar logo, deixe para configurar perto do lançamento.
- Procure nos workflows publicações disparadas por issue_comment e migre para push, release ou workflow_dispatch, como orienta o GitHub.
- Ative alertas para publicações inesperadas e compare as versões publicadas com as tags do repositório.
- Antes de apagar ou renomear um repositório ligado a um pacote, remova o vínculo no npm.
Para equipes que estão revendo a governança dos repositórios, o buildbase explicou como preparar os repositórios para o controle de licenças do GitHub.
E quem só instala pacotes, precisa fazer algo?
O risco para quem consome dependências vinha de uma versão maliciosa publicada por um invasor. Como não houve exploração confirmada, não há lista de versões a remover. Mesmo assim, o caso reforça práticas que reduzem o estrago se algo parecido acontecer:
- Fixe versões com o lockfile commitado e use npm ci em builds de produção.
- Evite que ferramentas e agentes de IA atualizem dependências para a versão mais recente sem revisão.
- Verifique a procedência das publicações quando o pacote oferece provenance.
O buildbase também acompanha falhas de infraestrutura que pedem atualização imediata, como a falha Vghost no kernel Linux.
Dúvidas que estão aparecendo
Meu pacote já publicado por trusted publishing está seguro?
Se a configuração já foi usada numa publicação bem-sucedida, ela está validada e presa ao ID do repositório. A janela de risco era a anterior a esse primeiro uso.
Tokens clássicos de publicação foram afetados?
O SlugFest dizia respeito ao trusted publishing. Tokens de longa duração têm outros riscos, como vazamento, e continuam exigindo cuidado próprio.
Preciso recriar todas as configurações?
Não. Só as que expiraram e ainda são necessárias, e as que apontam para repositórios que mudaram de nome ou de dono.
Se você publica pacotes pelo GitHub Actions
Se todas as suas configurações já foram usadas e os repositórios não mudaram, basta conferir os eventos dos workflows. Se você criou vínculos que nunca publicaram, eles vão expirar, e o caminho é recriá-los perto da próxima versão. Se algum repositório foi transferido para uma organização nova, refaça o vínculo antes de publicar de novo.
