O GitHub passou a expirar, 48 horas após a criação, as configurações de publicação confiável do npm que ainda não foram validadas. A medida foi adotada depois que pesquisadores descobriram que um invasor poderia publicar novas versões do pacote de outra pessoa sem roubar suas credenciais.
“Quando ocorre a primeira publicação bem-sucedida, a configuração é validada e deixa de expirar”, afirmou o GitHub. “Alterar a identidade do repositório ou do projeto exige uma nova relação de confiança, com um novo prazo de validação de 48 horas. Edições comuns não reiniciam o prazo.”
Segundo o GitHub, a mudança reduz o risco de confiar no nome de um repositório ou projeto que depois muda de proprietário. A empresa também informou que o npm passará a rejeitar tokens de publicação confiável emitidos em eventos `issue_comment` do GitHub Actions, além de manter a restrição já aplicada a eventos `pull_request_target`.
Em uma atualização da documentação, o GitHub afirma que uma configuração recém-criada de publicador confiável precisa realizar a primeira publicação bem-sucedida em até dois dias. Esse processo valida a configuração e a vincula à “identidade imutável do repositório”.
A mudança responde a descobertas da Bloom Security, que identificou uma brecha no sistema de publicação confiável do npm. A falha poderia permitir a tomada de controle de milhares de pacotes e desencadear um ataque em cascata à cadeia de fornecimento de software, semelhante ao Shai-Hulud. As descobertas foram comunicadas ao GitHub em 6 de junho de 2026.
“Imagine o seguinte: um invasor compromete um único pacote. Um agente de IA no dispositivo de um mantenedor de um pacote popular o baixa automaticamente para um projeto”, afirmou Golan Myers, pesquisador de segurança. “Esse único dispositivo é usado para enviar código malicioso ao pacote popular. Todos os usuários do pacote ficam expostos. Tudo isso porque uma pessoa com o acesso correto foi comprometida.”
A publicação confiável foi introduzida no npm em julho de 2025 como um método de autenticação sem credenciais. Ela permite que desenvolvedores publiquem pacotes no npm a partir de uma plataforma de CI/CD, como o GitHub Actions, usando tokens OpenID Connect (OIDC).
Com a publicação confiável configurada, o provedor de CI/CD do desenvolvedor gera um token criptográfico de curta duração para uma execução específica de um fluxo de trabalho. O registro do npm verifica esse token com base em uma configuração previamente autorizada.
Esse método elimina a necessidade de armazenar, trocar ou gerenciar manualmente segredos de longa duração do npm, reduzindo o risco de vazamento de credenciais. Também gera automaticamente atestados de procedência para os pacotes, permitindo que os usuários verifiquem onde foram compilados e quem os publicou. Isso reforça a segurança da cadeia de fornecimento de software.
No entanto, segundo a Bloom Security, essa arquitetura de segurança tinha uma falha na forma como identificava o repositório. Essa identificação, também chamada de slug, combina o proprietário ou a organização com o nome do repositório e segue o formato “proprietário/repositório”.
“Ela registra o endereço do repositório [...] em vez do identificador permanente atribuído pelo GitHub, pelo menos até que uma versão seja publicada pela primeira vez a partir daquele repositório”, explicou Myers. “É como uma fechadura que verifica o endereço na porta, em vez de quem é o dono da casa: quando o proprietário se muda, quem chega em seguida recebe a chave.”
Em outras palavras, os identificadores numéricos que permanecem os mesmos após a mudança de nome ou a transferência de um repositório são incluídos nos tokens OIDC do GitHub, mas o npm os ignora até que ocorra a primeira publicação bem-sucedida a partir daquele repositório.
Assim, a relação de confiança fica vinculada a um nome, e não a um identificador imutável do repositório. A brecha pode ser explorada quando alguém reivindica identificadores que ficaram disponíveis e herda a confiança associada a eles. Para o ataque funcionar, basta que a configuração de publicação confiável da vítima aponte para um identificador do GitHub que o invasor possa reivindicar e que o repositório nunca tenha sido usado para publicar uma versão do pacote no npm.
Quando um identificador fica disponível após o mantenedor renomear, transferir ou excluir um repositório, o invasor pode seguir estas etapas:
1. Criar um repositório no endereço liberado, no formato “proprietário/repositório”. Com isso, o GitHub atribui a ele um novo identificador de repositório.
2. Criar e iniciar um fluxo de trabalho de publicação do npm, que gera um token OIDC contendo o identificador reivindicado e o novo identificador numérico do repositório.
3. Enviar o token ao ponto de troca do npm. Como a identificação do repositório corresponde ao identificador armazenado, o npm emite uma credencial de publicação.
4. Receber um token de publicação com prazo limitado para um pacote que não pertence ao invasor e enviar alterações maliciosas ao registro.
Batizado de SlugFest, esse tipo de ataque pode ser usado para publicar uma nova versão maliciosa de um pacote legítimo, aproveitando seu nome, sua reputação, o número de downloads e as relações com outros pacotes que dependem dele. Isso pode resultar em ataques em larga escala à cadeia de fornecimento de software.
Agentes de IA executados nos dispositivos de desenvolvedores podem agravar o problema. “Os agentes resolvem dependências por conta própria, tendem a escolher a versão mais recente e raramente verificam a origem de um pacote”, afirmou a Bloom Security. “Uma versão maliciosa publicada por meio de um identificador reivindicado é baixada e executada sem intervenção humana.”
A empresa de cibersegurança informou ter encontrado mais de 1.500 pacotes vulneráveis, que somam mais de 10 milhões de downloads.
Desenvolvedores que mantêm pacotes no npm devem tomar as seguintes medidas:
1. Auditar os vínculos de publicadores confiáveis e verificar se o identificador de repositório listado ainda aponta para um repositório sob seu controle.
2. Se o repositório tiver sido renomeado ou transferido, excluir o vínculo de confiança existente e criar outro que aponte para o identificador atual.
3. Monitorar eventos inesperados de publicação no npm.
4. Excluir os vínculos de confiança sempre que um repositório for apagado, transferido ou renomeado.
“O ataque não exige conhecimento interno, roubo de credenciais nem uma condição de corrida”, afirmou Myers. “O único pré-requisito é que o identificador esteja disponível e que o vínculo ainda não tenha sido usado para publicar. Isso depende inteiramente da forma como a própria vítima administra seus repositórios.”
Myers também afirmou: “Esta pesquisa demonstra algo que a comunidade de segurança já observou repetidamente em ataques à cadeia de fornecimento: a ligação entre um identificador legível por pessoas e o elemento que ele identifica é a principal garantia de qualquer sistema de confiança. Quando essa ligação pode ser substituída silenciosamente por uma ação comum, como renomear um repositório, sem que o invasor precise fazer nada, a garantia de confiança desmorona.”
Esta não é a primeira vez que vetores incomuns de ataque à cadeia de fornecimento são identificados. Em agosto, a Bloom Security também descobriu que tanto o Open VSX quanto o marketplace do VS Code, da Microsoft, permitiam que conjuntos de extensões fizessem referência a extensões inexistentes nesses catálogos.
A técnica, chamada Extension Resurrection, pode ser usada para sequestrar extensões já mencionadas nesses conjuntos confiáveis, bastando reivindicar um espaço de nomes sem proprietário. Foram identificados como vulneráveis até 87 conjuntos no Open VSX e 677 no marketplace do VS Code.
“Os invasores poderiam reivindicar esses espaços vazios, publicar código malicioso com esses nomes e fazer com que ele fosse instalado automaticamente junto com o conjunto confiável, enviando atualizações silenciosamente a quem já o havia instalado”, observou Myers na ocasião. “Como as extensões têm acesso total ao dispositivo, isso equivale, na prática, à execução remota de código disfarçada de conteúdo legítimo.”
Publicidade
Nossa audiência é formada por analistas, pentesters, decisores e entusiastas que consomem nossas notícias todo dia pelo Site, Newsletter e Instagram. Fale com quem realmente importa para o seu negócio. Anuncie aqui. Saiba mais...