Paquete Injective SDK tenía puerta trasera para claves…
@Injectivelabs/sdk-ts v1.20.21 fue descargado 310 veces antes de su eliminación, y los investigadores instaron a la rotación de claves para cualquier billetera expuesta.
Un compromiso en la cadena de suministro afectó el paquete npm @injectivelabs/sdk-ts, ampliamente utilizado, con atacantes modificando la versión 1.20.21 para robar claves privadas de billetera y frases semilla. La versión maliciosa ha sido eliminada y desaprobada, pero los investigadores advirtieron que cualquier secreto manejado por los paquetes afectados debe ser tratado como comprometido.
Puntos Clave
- Una versión maliciosa de @injectivelabs/sdk-ts (v1.20.21) fue alterada para capturarclaves privadasy mnemotécnicas al enganchar funciones de derivación de claves de billetera y enviar datos a través de 'telemetría falsa'.
- La huella del SDK es grande, con aproximadamente 50,000 descargas semanales, a pesar de que la versión comprometida específica fue retirada después de 310 descargas.
- El riesgo de exposición se extiende más allá de las instalaciones directas porque la v1.20.21 fue fijada en 17 otros paquetes en el ámbito npm de Injective Labs.
- Los investigadores aconsejaron tratar cualquier clave ofrases semillaque pasen a través de los paquetes afectados como comprometidas, mientras que el CEO de Injective, Eric Chen, dijo que el problema fue solucionado y 'No hay fondos en la red en riesgo', con las versiones afectadas desaprobadas.
Secretos de billetera objetivo de la puerta trasera del SDK npm de Injective
Un ataque a la cadena de suministro de software comprometió las herramientas de desarrollo de Injective al insertar un backdoor en el paquete npm @injectivelabs/sdk-ts.
Investigadores de seguridad en Socket revelaron que la versión 1.20.21 fue modificada para robar las claves privadas de las billeteras de criptomonedas y las frases semilla (mnemotécnicas), un golpe directo a la seguridad de las billeteras en lugar de un fallo a nivel de protocolo.
El código malicioso ha sido eliminado. El CEO de Injective, Eric Chen, dijo: “ya está solucionado, y las versiones afectadas en npm ya están obsoletas,” y agregó: “No hay fondos en la red en riesgo,” enmarcando el incidente como un compromiso de dependencia que podría afectar a los desarrolladores y usuarios que ejecutaron versiones afectadas, no a la cadena de Injective en sí.
Cómo v1.20.21 exfiltró claves a través de "telemetría falsa"
La descripción de Socket es contundente: “La liberación maliciosa engancha las funciones de derivación de claves de la billetera, registra claves privadas y mnemotécnicas, y las exfiltra a través de telemetría falsa”, lo que significa que los flujos normales de creación o derivación de billeteras podrían filtrar secretos en silencio.
El camino de intrusión importa. Socket vinculó la modificación a una cuenta de GitHub de desarrollador comprometida, con commits sospechosos que comenzaron el 8 de junio. Eso crea una ventana de riesgo clara para cualquier persona que instaló o construyó contra la dependencia afectada durante ese período.
La exfiltración fue diseñada para integrarse. Los datos robados fueron codificados y enviados a una web.direcciónhecho para parecer un servidor legítimo de la red Injective, consistente con el robo de credenciales que busca evitar romper aplicaciones o activar alarmas inmediatas.
Radio de explosión: 50,000 descargas semanales y 17 paquetes fijados
La escala del paquete es el problema operativo. @injectivelabs/sdk-ts ve alrededor de 50,000 descargas semanales, y Socket calificó esa huella como "significativa para desarrolladores y aplicaciones que manejan flujos de trabajo de billetera Injective."
La versión maliciosa específica fue descargada 310 veces antes de su eliminación, lo que sugiere una distribución confirmada limitada de v1.20.21 en sí, pero no necesariamente una exposición limitada a nivel descendente.
El riesgo de segundo orden es la propagación de dependencias. Socket dijo que v1.20.21 estaba fijada en otros 17 paquetes en el ámbito npm de Injective Labs, "exponiendo a usuarios que pueden no haber instalado el SDK directamente."
En la práctica, las dependencias fijadas pueden introducir una versión comprometida en las compilaciones a través de instalaciones transitivas, ampliando el conjunto de aplicaciones afectadas más allá de los equipos que actualizaron el SDK conscientemente.
La remediación no es solo "actualizar y seguir adelante." Socket advirtió: "Cualquier clave o mnemotécnica pasada a través de paquetes afectados debe ser tratada como comprometida," implicando migración de billetera y rotación de claves para cualquier secreto que tocó el código comprometido.
Socket también dijo que el desarrollador cuyo cuenta fue infiltrada detectó rápidamente el compromiso, pero advirtió que "la campaña en sí aún no está completamente contenida," dejando incertidumbre sobre lanzamientos o paquetes adicionales afectados.
Por qué el robo de billeteras en la cadena de suministro sigue apareciendo en cripto
Este incidente encaja en un patrón: los atacantes apuntan cada vez más a rieles de distribución de confianza como npm y GitHub en lugar de intentar romper la criptografía de cadena.
La Alianza de Seguridad (SEAL) ha advertido que "los sistemas comprometidos se están utilizando para empujar código malicioso directamente en los propios repositorios de GitHub de una empresa, convirtiendo un solo compromiso en un canal de distribución para el siguiente," y notó que el malware se está volviendo más amplio "con cargas útiles multiplataforma, incluyendo un aumento en campañas específicas de macOS, que combinan infostealers, RATs (troyanos de acceso remoto) y capacidades de puerta trasera en un solo paquete."
El incentivo es claro. CertiK informó que los compromisos de billeteras fueron el vector de ataque más costoso en el primer semestre de 2026, con $444 millones robados en 33 incidentes.
El seguimiento ahora importa más que la divulgación inicial. Los comerciantes y usuarios de DeFi deben buscar actualizaciones sobre si la campaña está completamente contenida, si algún paquete adicional del ámbito Injective fue afectado más allá de @injectivelabs/sdk-ts v1.20.21, y si se confirman fondos robados de claves que pasaron por compilaciones impactadas.
Del lado del desarrollador, la señal es la remediación pública: estado de depreciación en el ámbito npm de Injective Labs y si los proyectos importantes confirman rotación de claves o migraciones de billetera después de una posible exposición.
Trata esto como un evento de riesgo de billetera, no como una historia de interrupción de cadena
Yo trato esto como una configuración de compromiso de billetera con un riesgo asimétrico para cualquiera que tocó la dependencia durante la ventana de intrusión, no como una explotación de protocolo que debería reajustar mecánicamente el riesgo de cadena de Injective.
La afirmación de Chen de "No hay fondos en la red en riesgo," es consistente con ese marco, pero no reduce la urgencia para desarrolladores y usuarios avanzados porque el objetivo del robo es el material secreto que controla las billeteras.
El umbral que importa es si los drenajes descendentes se atribuyen a claves derivadas o manejadas a través de los paquetes afectados. Si esa vinculación aparece y la remediación sigue siendo desigual en las dApps de Injective, la configuración comienza a parecer estructural en lugar de impulsada por la narrativa, porque traduciría un incidente de cadena de suministro en pérdidas reales y repetidas de billetera.
