Um ataque à cadeia de fornecimento de software comprometeu o kit de desenvolvimento oficial da Injective Labs no registo npm, injetando código malicioso concebido para capturar chaves privadas e frases mnemónicas de carteiras de criptomoedas. As empresas de segurança de aplicações Socket, OX Security e StepSecurity detetaram o ataque à cadeia de fornecimento através da versão 1.20.21 do pacote npm @injectivelabs/sdk-ts. O incidente expõe, uma vez mais, a fragilidade crescente dos ecossistemas de desenvolvimento aberto face a adversários capazes de comprometer contas legítimas de colaboradores.
O que é a Injective SDK e qual a sua relevância
A Injective SDK é um kit de desenvolvimento em TypeScript/JavaScript destinado à criação de aplicações sobre a blockchain Injective, uma blockchain de Camada 1 orientada para finanças descentralizadas (DeFi), ativos tokenizados e exchanges descentralizadas. O pacote regista cerca de 50 000 transferências semanais no npm e é utilizado por programadores que constroem carteiras de criptomoedas, bots de negociação, exchanges descentralizadas, aplicações DeFi e ferramentas de pagamento. Trata-se, portanto, de uma dependência central em inúmeros projetos do ecossistema Web3, o que torna qualquer comprometimento desta biblioteca particularmente grave.
Como decorreu o ataque: cronologia precisa
A 8 de julho de 2026, os atacantes aproveitaram o acesso à conta de um programador de confiança para introduzir uma backdoor num kit de desenvolvimento amplamente utilizado para a blockchain Injective. A StepSecurity publicou uma cronologia detalhada: o primeiro commit malicioso chegou ao ramo principal às 20h24 UTC, adicionando o ficheiro key-derivation-telemetry.ts e ligando-o às funções PrivateKey.fromMnemonic() e fromHex(); às 20h59 UTC todas as 18 versões dos pacotes @injectivelabs foram publicadas no npm; às 21h16 UTC foi submetido um commit de reversão; e às 21h47 UTC a versão limpa 1.20.23 foi publicada, com a versão 1.20.21 marcada como deprecada.
Um pormenor técnico relevante diz respeito ao método de publicação: a proveniência do pacote malicioso no npm aponta para um commit específico no ramo principal, construído pelo GitHub Actions através do pipeline de publicação confiável OIDC do próprio repositório — pelo que não foi necessário roubar nenhum token npm; bastou obter acesso de escrita ao repositório GitHub.
Funcionamento técnico do malware: telemetria falsa como disfarce
Disfarçado como análise inócua, o código capturava silenciosamente frases de recuperação de carteiras e chaves privadas, enviando-as para um servidor controlado pelo atacante no momento em que uma carteira era criada ou carregada. A sofisticação do método residia precisamente na sua invisibilidade: o malware ativava-se quando os programadores utilizavam funções do SDK para gerar ou importar chaves de carteira, e não aquando da instalação.
Uma vez chamadas essas funções, o malware capturava a frase mnemónica completa e a chave privada, codificando os dados em base64. Os dados eram depois exfiltrados através de um pedido POST para um endpoint de infraestrutura pública da Injective Labs, com o endereço ofuscado por carateres, permitindo que o tráfego de exfiltração se confundisse com o tráfego normal dos produtos da InjectiveLabs. Segundo a StepSecurity, o malware não transmitia os dados imediatamente, mas acumulava várias chaves e mnemónicas durante dois segundos, agrupando-as no cabeçalho do pedido HTTP antes de enviar.
Amplitude do impacto: 18 pacotes e 112 000 transferências acumuladas
O atacante publicou também a versão 1.20.21 em 17 pacotes adicionais com escopo @injectivelabs que dependiam e fixavam a versão maliciosa do SDK, expondo utilizadores transitivos que podem não ter instalado o @injectivelabs/sdk-ts diretamente. A lógica era subtil: os pacotes secundários dentro do ecossistema Injective não foram diretamente injetados com código malicioso; em vez disso, as suas árvores de dependências foram modificadas para apontarem explicitamente para @injectivelabs/[email protected], de modo a executar o payload de forma indireta.
O impacto inclui potencial exfiltração de criptomoedas das máquinas das vítimas, com um alcance de 87 pacotes dependentes e um total acumulado de 112 378 transferências. Ainda assim, é importante distinguir entre transferências e comprometimentos efetivos: a versão comprometida foi transferida cerca de 310 vezes, mas uma transferência não significa automaticamente que uma chave de carteira foi exposta — o código malicioso teria de ter sido executado enquanto a aplicação processava uma chave privada ou frase de recuperação.
Não existe atualmente qualquer evidência de que a blockchain Injective tenha sido comprometida, de que todas as carteiras Injective tenham sido colocadas em risco, ou de que uma quantidade confirmada de criptomoeda tenha sido roubada. O CEO da Injective, Eric Chen, confirmou que as versões afetadas no npm foram deprecadas e o problema corrigido, acrescentando que nenhum fundo na rede Injective estava em risco.
O que devem fazer os programadores afetados
A Socket recomendou atualizar para a versão 1.20.23, rever as cadeias de dependências e tratar quaisquer credenciais de carteira processadas pelas versões comprometidas como totalmente comprometidas. Para quem suspeite de exposição, os programadores devem transferir as suas criptomoedas para novas carteiras e rodar todos os segredos no seu ambiente. Adicionalmente, um projeto que tenha instalado, por exemplo, @injectivelabs/[email protected] resolveria o SDK malicioso de forma transitiva e executaria o stealer sem nunca nomear o sdk-ts no seu próprio manifesto — razão pela qual auditar apenas as dependências diretas não é suficiente.
Porque é que isto importa
Este incidente insere-se numa tendência crescente e preocupante. Os comprometimentos de carteiras foram o vetor de ataque mais oneroso no primeiro semestre de 2026, com 444 milhões de dólares roubados em 33 incidentes, de acordo com a CertiK. A Security Alliance referiu no seu relatório do segundo trimestre que os atacantes têm utilizado cada vez mais plataformas como o GitHub, o npm e o Google para distribuir malware, sendo que em alguns incidentes máquinas comprometidas foram usadas para introduzir código malicioso diretamente nos repositórios GitHub das próprias empresas, transformando um único comprometimento num canal de distribuição para o seguinte.
Para Portugal e para a União Europeia, este tipo de ataque à cadeia de fornecimento de software tem enquadramento direto no Regime Jurídico da Cibersegurança e no Decreto-Lei 125/2025, que transpõe a Diretiva NIS2 para o ordenamento jurídico nacional. A NIS2 exige que entidades essenciais e importantes implementem medidas de gestão de risco que incluam explicitamente a segurança da cadeia de fornecimento de software — abrangendo a avaliação de dependências de terceiros e a monitorização de pacotes open source utilizados em produção. O Centro Nacional de Cibersegurança (CNCS) tem reiterado que as dependências de software de terceiros constituem uma superfície de ataque crítica que as organizações portuguesas — incluindo PME que desenvolvem ou integram soluções baseadas em tecnologias blockchain e Web3 — não podem ignorar.
Do ponto de vista prático, este ataque demonstra que a simples utilização de pacotes com proveniência aparentemente legítima — publicados por contas com histórico verificado e através de pipelines CI/CD oficiais — não é garantia de segurança. Os ataques à cadeia de fornecimento vieram para ficar e encontraram no registo npm o seu novo domínio; estas operações não precisam de ser altamente sofisticadas — basta que funcionem. Para as PME portuguesas que utilizam dependências npm em projetos de software, a recomendação passa por implementar verificação de integridade de pacotes, fixar versões de dependências de forma explícita, monitorizar alertas de segurança em registos como o npm e o GitHub Advisory Database, e avaliar ferramentas de análise de composição de software (SCA) que detetem comprometimentos em tempo real — práticas alinhadas com os controlos técnicos exigidos pelo RGPD quando dados pessoais são processados por aplicações que dependem destas bibliotecas.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Socket, StepSecurity, OX Security, BleepingComputer, CoinTelegraph e Crypto.news.