Los atacantes comprometieron el repositorio oficial de GitHub del proyecto Injective Labs y publicaron en el registro de npm una versión maliciosa del paquete SDK @injectivelabs/[email protected], diseñada para robar claves privadas y frases mnemónicas de monederos de criptomonedas. Según los datos de los investigadores de Socket, OX Security y StepSecurity, el ataque afectó en total a 18 paquetes dentro del ámbito @injectivelabs. Todos los desarrolladores que utilicen estas bibliotecas deben actualizar inmediatamente a la versión 1.20.23 y considerar todas las claves procesadas mediante la versión comprometida como expuestas.
Mecanismo del ataque y detalles técnicos
La versión comprometida 1.20.21 fue publicada el 8 de julio de 2026. Como señalan los investigadores de Socket, el código malicioso se introdujo en el repositorio oficial mediante commits desde la cuenta de un desarrollador con un historial consolidado de contribuciones al proyecto. Según los datos de StepSecurity, la publicación de la versión maliciosa se realizó a través del propio pipeline de publicación de confianza del repositorio basado en OIDC (trusted-publisher), lo que permitió eludir los mecanismos de control estándar.
El backdoor se implementó mediante la modificación de funciones legítimas de generación de claves privadas. En el código se inyectó la función trackKeyDerivation(), disfrazada como recopilación de telemetría anonimizada para la optimización del SDK. Según la descripción en el código, la función supuestamente «rastrea los métodos de derivación de claves y los patrones de temporización para identificar cuellos de botella de rendimiento». En realidad, se le pasaban un identificador del método de generación de la clave y el propio material sensible: datos suficientes para la recuperación completa de la clave privada en el lado del atacante.
Una característica fundamental del malware es el rechazo del uso de npm lifecycle scripts. El código no se activaba en la fase de instalación del paquete, sino que se ejecutaba únicamente cuando el desarrollador utilizaba directamente la funcionalidad de la biblioteca. Tal como señalaron en OX Security, la lógica maliciosa interceptaba las frases mnemónicas cada vez que un usuario legítimo creaba un monedero o recurría a funciones de lectura de mnemónicos.
Mecanismo de exfiltración
Para reducir el número de solicitudes salientes y disminuir la probabilidad de detección, el malware acumulaba en una cola, durante una ventana de dos segundos, los datos de derivación de claves interceptados, tras lo cual los enviaba en una única solicitud HTTPS POST a un servidor externo. El dominio utilizado para la exfiltración se eligió de forma que imitara la infraestructura legítima de Injective:
- Dominio de exfiltración: testnet.archival.chain.grpc-web.injective[.]network
Alcance de la compromisión
El ataque no se limitó al paquete principal del SDK. Según los investigadores, el atacante publicó la versión 1.20.21 para otros 17 paquetes adicionales dentro del ámbito @injectivelabs, que dependían de la versión maliciosa del SDK y fijaban estrictamente esa versión. Esto creó una amenaza de compromiso transitivo: los desarrolladores que no instalaban el SDK principal directamente podían recibir el código malicioso a través de las dependencias. Paquetes afectados:
- @injectivelabs/utils
- @injectivelabs/networks
- @injectivelabs/ts-types
- @injectivelabs/exceptions
- @injectivelabs/wallet-base
- @injectivelabs/wallet-core
- @injectivelabs/wallet-cosmos
- @injectivelabs/wallet-private-key
- @injectivelabs/wallet-evm
- @injectivelabs/wallet-trezor
- @injectivelabs/wallet-cosmostation
- @injectivelabs/wallet-ledger
- @injectivelabs/wallet-wallet-connect
- @injectivelabs/wallet-magic
- @injectivelabs/wallet-strategy
- @injectivelabs/wallet-turnkey
- @injectivelabs/wallet-cosmos-strategy
La versión 1.20.21 del paquete principal fue marcada como deprecated en el registro de npm. Sin embargo, en el momento de la publicación de las investigaciones, los artefactos de la versión seguían estando disponibles para su descarga en GitHub.
Evaluación del impacto
Este incidente supone un nivel de riesgo elevado por varias razones. En primer lugar, el ataque estaba dirigido a la cadena de suministro de un proyecto de criptomonedas, donde el compromiso de claves privadas conduce a pérdidas financieras directas e irreversibles. En segundo lugar, el uso de un pipeline de publicación de confianza y de una cuenta con un historial legítimo de contribuciones dificultaba considerablemente su detección. En tercer lugar, el alcance de 18 paquetes con dependencias transitivas multiplicaba la superficie de ataque.
Los desarrolladores de aplicaciones descentralizadas basadas en Injective Protocol están expuestos al mayor riesgo, así como cualquier proyecto que utilice los paquetes enumerados en sus dependencias. Cabe señalar que, en el momento de la preparación de este material, no se había publicado un informe formal sobre el incidente por parte de Injective Labs ni un boletín oficial de seguridad de npm: la información se basa en el análisis de equipos de investigación independientes.
Recomendaciones de respuesta
- Actualice de inmediato todos los paquetes @injectivelabs a la versión 1.20.23 o posterior.
- Revise las dependencias transitivas: lleve a cabo una auditoría del árbol de dependencias del proyecto para detectar cualquiera de los 18 paquetes comprometidos en la versión 1.20.21.
- Rotación de claves: cualquier clave privada o frase mnemónica que haya sido generada o procesada a través de la versión comprometida debe considerarse expuesta. Traslade los fondos a nuevos monederos con claves generadas de nuevo.
- Revise la actividad de red: analice los registros en busca de conexiones HTTPS salientes hacia el dominio testnet.archival.chain.grpc-web.injective[.]network.
- Fije las versiones de las dependencias utilizando archivos lock y considere la implantación de herramientas de monitorización de la cadena de suministro, como Socket o StepSecurity, para detectar cambios anómalos en los paquetes.
Este incidente demuestra la creciente eficacia de los ataques a la cadena de suministro mediante el compromiso de pipelines de publicación de confianza. Los desarrolladores que trabajen con infraestructura de criptomonedas deben priorizar la verificación de dependencias en busca de la versión 1.20.21 de cualquiera de los 18 paquetes afectados de @injectivelabs, llevar a cabo la rotación de todas las claves potencialmente comprometidas y trasladar los fondos antes de que los atacantes puedan aprovechar el material robado.
