Atores desconhecidos usaram commits em conta de mantenedor confiável e pipeline OIDC de publicação para implantar telemetria falsa em @injectivelabs/sdk-ts@1.20.21, exfiltrando mnemônicos e material de derivação de chaves privadas via HTTPS.
| Componente | Ecossistema npm @injectivelabs/*, com foco em @injectivelabs/sdk-ts@1.20.21 e 17 pacotes adicionais no mesmo escopo que fixaram essa versão comprometida; repositório oficial do SDK Injective Labs no GitHub e artefatos de release ainda disponíveis no GitHub |
| Vetor | Comprometimento do repositório GitHub com commits maliciosos atribuídos a conta de desenvolvedor com histórico legítimo de contribuições (thomasRalee), publicação via pipeline trusted-publisher (OIDC) e ativação em tempo de execução ao usar funções legítimas de derivação de chaves, sem scripts de lifecycle na instalação |
| Impacto | Captura de mnemônicos, marcadores do método de derivação e parâmetros sensíveis suficientes para regenerar chaves privadas de carteiras cripto; exposição direta e transitiva para consumidores do SDK e de pacotes dependentes que pinaram a versão 1.20.21 |
| Prioridade | Remover @injectivelabs/sdk-ts@1.20.21, atualizar para 1.20.23, auditar dependências transitivas em lockfiles e pipelines, considerar comprometidas chaves e frases mnemônicas processadas pela versão afetada e executar rotação imediata |
| Artefatos | Função trackKeyDerivation() disfarçada de métrica de uso; beacon HTTPS POST agregando derivações em janela de dois segundos para testnet.archival.chain.grpc-web.injective[.]network |
| Mitigação | Atualização para versão limpa 1.20.23, rotação de chaves e mnemônicos expostos, revisão de integridade do repositório, endurecimento do fluxo OIDC de publicação e varredura de ambientes CI/CD e aplicações que consumiram o escopo @injectivelabs entre 8 de julho de 2026 e a depreciação no registro npm |
Atores de ameaça ainda não identificados comprometeram o repositório GitHub do projeto SDK da Injective Labs e converteram a cadeia de confiança oficial em veículo de distribuição de código malicioso no registro npm. A versão comprometida @injectivelabs/sdk-ts@1.20.21, publicada em 8 de julho de 2026, incorporava lógica de exfiltração disfarçada de telemetria de produto voltada à otimização do SDK. O pacote foi posteriormente marcado como depreciado no npm, mas os artefatos de release associados permaneciam acessíveis no GitHub no momento da divulgação, ampliando a janela em que equipes podem reinstalar, cachear ou reutilizar binários comprometidos fora do controle direto do registro.
A intrusão não se limitou ao SDK principal. A mesma versão maliciosa foi replicada em 17 pacotes adicionais no escopo @injectivelabs, configurados para depender e fixar explicitamente @injectivelabs/sdk-ts@1.20.21. Esse desenho amplia o raio de impacto para consumidores transitivos que nunca adicionaram o SDK diretamente ao package.json, mas herdaram a dependência por meio de bibliotecas auxiliares do ecossistema Injective. A análise técnica classifica o implante como simples e direto: ele evita gatilhos na fase de instalação, concentra a ativação no uso de rotinas legítimas de geração de chaves e reduz ruído operacional ao não empregar scripts de lifecycle típicos de campanhas npm mais barulhentas.
O código malicioso entrou no repositório oficial por meio de commits submetidos por uma conta GitHub pertencente a um desenvolvedor com histórico estabelecido de contribuições ao projeto. Essa combinação — identidade previamente confiável mais pipeline de publicação automatizada — reduz a fricção para que alterações hostis alcancem usuários finais sem revisão humana adicional suficiente para detectar a modificação semântica. A liberação maliciosa foi facilitada pelo mecanismo de trusted publisher baseado em OIDC do próprio repositório, o que significa que a cadeia de entrega comprometida operou dentro dos limites de um fluxo de CI/CD considerado legítimo até o incidente.
Em tempo de execução, a versão envenenada altera funções legítimas usadas em fluxos de geração de chaves privadas. Sempre que a aplicação consumidora aciona a lógica de derivação, o implante invoca trackKeyDerivation() sob o pretexto de coletar métricas anonimizadas para identificar gargalos de desempenho e entender a adoção de formatos de chave no ecossistema. A documentação embutida descreve a função como não bloqueante e do tipo fire-and-forget, reforçando a aparência de instrumentação benigna. Na prática, os parâmetros enviados incluem um marcador fixo do método empregado na derivação — por exemplo, fluxos baseados em hexadecimal versus frase mnemônica — e o material sensível necessário para reproduzir a chave privada no lado do atacante.
A exfiltração foi projetada para minimizar requisições de saída perceptíveis. Derivações sucessivas são enfileiradas ao longo de uma janela de aproximadamente dois segundos e consolidadas em um único beacon HTTPS POST enviado a um endpoint externo associado à infraestrutura Injective, com o domínio defangado como testnet.archival.chain.grpc-web.injective[.]network. Esse padrão mistura tráfego aparentemente relacionado ao ecossistema da plataforma com dados de carteira roubados, dificultando triagem baseada apenas em destinos completamente desconhecidos. Para operadores de segurança, o ponto crítico é temporal: cada uso legítimo da lógica de leitura ou criação de mnemônicos — que funcionam como chave mestra de carteiras cripto — representa um evento potencial de captura irreversível se a versão comprometida estiver em memória.
O incidente atinge desenvolvedores, integradores e aplicações que consumiram o escopo @injectivelabs durante o intervalo em que a versão 1.20.21 esteve disponível. O risco não se restringe a instalações diretas do SDK TypeScript: qualquer serviço, frontend, bot, ferramenta interna ou pipeline que tenha resolvido dependências transitivas para pacotes @injectivelabs pinados na versão maliciosa pode ter executado a lógica de captura sem interação explícita do operador além do uso normal da biblioteca.
Ambientes de build e publicação que confiam em identidades OIDC do repositório comprometido também fazem parte da superfície de revisão. Mesmo após a depreciação no npm, caches de artefatos, mirrors internos, imagens de container congeladas e releases baixados do GitHub podem perpetuar o binário afetado. Organizações que armazenam node_modules em cache, reutilizam lockfiles antigos ou reconstruem imagens a partir de camadas imutáveis devem tratar esses ativos como potencialmente contaminados até comprovar a ausência da versão 1.20.21.
- Pacote primário
@injectivelabs/sdk-ts@1.20.21, publicado em 8 de julho de 2026 e posteriormente depreciado no npm - 17 pacotes adicionais no escopo
@injectivelabscom dependência fixa na versão comprometida do SDK - Contas e pipelines de publicação GitHub/OIDC associados ao repositório oficial do SDK Injective Labs
- Carteiras cripto cujas chaves privadas ou frases mnemônicas passaram por rotinas de derivação da biblioteca afetada
- Artefatos de release ainda recuperáveis no GitHub, independentemente do status no registro npm
A detecção deve combinar análise de composição de software, telemetria de rede e revisão de identidade no repositório. Como o implante não depende de scripts pós-instalação, varreduras que procuram apenas preinstall ou postinstall maliciosos podem falhar. O sinal mais confiável é a presença da versão 1.20.21 em lockfiles, caches de registro privado, imagens publicadas e inventários de dependências, somada a evidências de chamadas de derivação de chave em aplicações que importam módulos @injectivelabs.
Em monitoramento de rede, equipes devem correlacionar saídas HTTPS POST originadas de processos Node.js ou bundlers que carregam o SDK comprometido com destinos no domínio defangado testnet.archival.chain.grpc-web.injective[.]network, especialmente quando múltiplos eventos de derivação ocorrem em sequência curta compatível com a agregação em janela de dois segundos. Em repositórios, a trilha de auditoria relevante inclui commits recentes na área de instrumentação ou telemetria do SDK, publicações automatizadas coincidentes com esses commits e uso da identidade thomasRalee em pushes que alteraram código sensível a chaves sem revisão proporcional ao risco.
- Presença de
@injectivelabs/sdk-ts@1.20.21ou dependências pinadas a essa versão empackage-lock.json,pnpm-lock.yaml,yarn.locke SBOMs - Chamadas à função
trackKeyDerivation()em builds que não deveriam emitir telemetria de produto para servidores externos - Tráfego HTTPS POST agregado de processos de aplicação Injective para
testnet.archival.chain.grpc-web.injective[.]network - Publicações npm do escopo
@injectivelabssincronizadas com commits suspeitos no repositório GitHub oficial - Atividade de pipeline OIDC trusted publisher executada imediatamente após alterações em módulos de derivação de chaves
A resposta deve priorizar contenção de segredo, erradicação da dependência comprometida e restauração da integridade da cadeia de publicação. Qualquer chave privada ou frase mnemônica que tenha transitado pela versão 1.20.21 durante operação normal da biblioteca deve ser tratada como exposta, com rotação e movimentação de fundos para endereços recém-gerados fora do material capturado. A atualização para a versão limpa 1.20.23 é necessária, mas insuficiente se lockfiles, caches ou imagens continuarem resolvendo a versão maliciosa.
No plano de engenharia de supply chain, mantenedores e consumidores devem revisar permissões de contas com push direto, exigir revisão obrigatória para alterações em áreas criptográficas, restringir publicação npm a workflows com aprovação explícita e validar assinaturas ou proveniência de releases quando disponíveis. Após erradicar a versão afetada, recomenda-se varredura completa de dependências transitivas em todos os repositórios que referenciam o escopo @injectivelabs, invalidação de caches de pacotes e reconstrução de imagens de deploy sem reutilizar camadas geradas durante a janela de exposição.
- Substituir imediatamente
@injectivelabs/sdk-ts@1.20.21por1.20.23e reinstalar dependências a partir de lockfiles regenerados - Rotacionar chaves privadas e mnemônicos que possam ter sido processados pela biblioteca comprometida
- Auditar os 17 pacotes
@injectivelabsadicionais que pinaram a versão maliciosa e remover resoluções transitivas residuais - Bloquear ou alertar sobre downloads da versão
1.20.21em proxies npm internos e em artefatos espelhados do GitHub - Revisar logs de OIDC, workflows de publicação e histórico de commits da conta
thomasRaleepara identificar o ponto inicial de comprometimento e impedir novas publicações não autorizadas
0 Comentários