El repositorio de GitHub de Injective Labs fue comprometido para publicar en npm una versión maliciosa del paquete @injectivelabs/sdk-ts que roba claves privadas y frases semilla de billeteras cripto. La versión infectada, la 1.20.21, estuvo disponible durante aproximadamente 49 minutos el 8 de junio de 2026 antes de que el propio equipo revirtiera el cambio y publicara una versión limpia. Las firmas Socket, Ox Security y StepSecurity detectaron el ataque y lo hicieron público, aunque la noticia recién trascendió masivamente en julio.
Qué pasó
Según Socket, la actividad maliciosa comenzó el 8 de junio a las 20:06 (GMT+2) a través de una cuenta de mantenedor comprometida con historial de contribuciones legítimo. A las 22:59 se publicó la versión 1.20.21 de @injectivelabs/sdk-ts con el código malicioso incorporado. El propio dueño de la cuenta detectó la intrusión en minutos: a las 23:18 se subió un commit de reversión y a las 23:48 ya estaba disponible la versión limpia 1.20.23. El SDK tiene un promedio de 50.000 descargas semanales, pero la versión comprometida se descargó solo 310 veces antes de ser marcada como deprecated en npm (no eliminada del todo; los artefactos del release también siguieron disponibles en GitHub).
El atacante no se limitó al paquete principal: publicó la misma versión 1.20.21 en otros 17 paquetes del scope @injectivelabs que dependen del SDK y lo fijan como versión pineada, entre ellos librerías de wallets vinculadas a Ledger, Trezor y WalletConnect. En conjunto, el SDK y sus paquetes dependientes suman 87 dependientes directos en el ecosistema npm.
Cómo funciona el robo
El malware no se activa con la sola instalación del paquete, sino cuando el código de la aplicación llama a funciones del SDK que generan o importan claves de billetera, puntualmente fromMnemonic() y fromHex(). Ahí intercepta la frase mnemónica o la clave privada completa, la codifica en base64 y la envía por HTTP POST a un endpoint que imita infraestructura legítima de Injective (testnet.archival.chain.grpc-web.injective[.]network), lo que dificulta que pase desapercibido en logs de red. Para evitar generar tráfico sospechoso por cada llamada, el código agrupaba varias claves y frases en una ventana de dos segundos antes de enviarlas en un solo request.
Versiones afectadas
La única versión comprometida confirmada es @injectivelabs/sdk-ts@1.20.21, junto con la versión 1.20.21 de otros 17 paquetes del mismo scope que la referencian como dependencia fija. La versión 1.20.23, publicada el mismo 8 de junio pocas horas después, es la limpia y la que se recomienda usar. Socket publicó los hashes SHA-256 de los archivos maliciosos (build CJS y ESM) para que los equipos de seguridad puedan verificar si tienen el paquete infectado en caché o en un lockfile congelado.
Qué hacer si instalaste el paquete
Quien haya instalado la versión 1.20.21 de @injectivelabs/sdk-ts o de cualquiera de los 17 paquetes asociados en la ventana del 8 de junio de 2026 debe actualizar de inmediato a la 1.20.23 o posterior, y tratar como comprometida cualquier clave privada o frase semilla que haya pasado por esas funciones del SDK: eso significa transferir los fondos a una billetera nueva y rotar cualquier otro secreto del entorno que haya estado expuesto en el mismo proceso. También conviene revisar dependencias transitivas, ya que proyectos que no instalaron el SDK directamente pero dependen de alguno de los 17 paquetes afectados quedaron expuestos igual.
Una alerta más para quienes viven de npm
Para la comunidad de developers del MUG que trabaja con Node y JavaScript, este caso es otro recordatorio de que confiar en un paquete de npm es confiar en la cadena entera de sus mantenedores y su historial de commits, no solo en el código que uno mismo revisó una vez. Auditar dependencias con herramientas como npm audit, fijar versiones exactas en el lockfile, revisar changelogs antes de actualizar paquetes sensibles (sobre todo los vinculados a wallets o secretos) y monitorear alertas de proveedores como Socket o GitHub Advisory Database son prácticas que cuestan poco y evitan sustos grandes.
¿Tu equipo audita las dependencias de npm en cada actualización, o confía en que si compila y pasan los tests ya está todo bien?
Fuentes
- BleepingComputer — Injective SDK on npm infected with cryptocurrency wallet stealer
- The Hacker News — Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages
- Socket — Compromised Injective SDK npm Package Exfiltrates Wallet Keys
