Como 18 pacotes ganharam um backdoor
Às 20:24 UTC de 8 de julho de 2026, uma carteira que carregou a mais recente versão de @injectivelabs/sdk-ts entregou em silêncio a sua frase-semente a um atacante. O primeiro commit malicioso acabara de chegar e permaneceu ativo cerca de 49 minutos antes de alguém o notar.
Os atacantes não entraram à força. Usaram a conta GitHub de um colaborador de confiança há muito estabelecido para enviar três commits que colocaram um backdoor no SDK na versão 1.20.21, além de 17 pacotes dependentes fixados nessa versão exata. Dezoito pacotes no total carregavam o mesmo veneno. O backdoor capturava PrivateKey.fromMnemonic() e PrivateKey.fromHex(), pelo que exfiltrava frases-semente BIP-39 e chaves privadas no instante em que uma carteira arrancava.
Houve cerca de 310 descarregamentos antes de o mantenedor detetar, reverter e publicar uma versão limpa 1.20.23. A Injective Labs diz que não se perderam fundos de utilizadores. A versão maliciosa foi marcada como obsoleta no npm em vez de removida, pelo que continua no registo como sinal de aviso.
A conduta de confiança era o ponto fraco
A salvaguarda era o mecanismo de entrega. A versão maliciosa viajou pela própria conduta de publicação de confiança da Injective Labs no npm, a via OIDC construída precisamente para eliminar o risco de um token de publicação roubado.
Essa é a parte incómoda. A publicação de confiança OIDC significa que um pacote pode ser lançado sem qualquer token npm de longa duração para roubar, o que é um ganho de segurança real. Mas significa também que uma conta humana comprometida mais uma compilação automatizada tornam essa confiança na via de ataque. Não havia token para fugir porque a própria conduta fazia a assinatura, e a conduta confiava na conta que o GitHub declarava legítima.
O que verificar nas suas próprias dependências
A lição aqui é geral, não específica de criptomoedas. Qualquer responsável que publique software herda esta mesma exposição através de dependências transitivas, os pacotes de que os seus pacotes dependem e que nunca escolheu instalar diretamente.
Fixe as suas dependências transitivas em versões reconhecidas como boas e analise-as, para que uma troca a meio numa versão fixada apareça como uma alteração em vez de passar despercebida. Trate a automação do publicador de confiança como a redução de um risco, não a eliminação de todos, porque a via da conta humana comprometida permanece aberta. E rode qualquer segredo, chave ou credencial que tenha passado por uma compilação que agora suspeita, partindo do princípio de que foi vista.
Leia a seguir: Progress manda clientes ShareFile desligar tudo | Uma falha do Defender dá o controlo total do PC



