Lo m\u00e1s importante en resumen<\/p>\n
- \n
- Un paquete, muchos afectados.<\/strong> El comprometido @injectivelabs\/sdk-ts captur\u00f3 claves privadas y mnem\u00f3nicos, distribuy\u00e9ndose a trav\u00e9s de 17 paquetes dependientes.<\/li>\n
- Disfrazado como telemetr\u00eda.<\/strong> La funci\u00f3n maliciosa codificaba los datos en base64 y los enviaba silenciosamente a un punto final oculto.<\/li>\n
- Mucho m\u00e1s all\u00e1 de las criptomonedas.<\/strong> Cualquier compilaci\u00f3n que obtenga dependencias sin verificar conlleva el mismo riesgo. El bloqueo de versiones, la verificaci\u00f3n de firmas y la rotaci\u00f3n r\u00e1pida son la respuesta.<\/li>\n<\/ul>\n<\/div>\n
Relacionado:<\/strong> Un controlador firmado deja ciego a la protecci\u00f3n del extremo \u00b7 Cuando los atacantes son m\u00e1s r\u00e1pidos que el parche<\/a><\/p>\n
Qu\u00e9 escond\u00eda el SDK de Injective<\/h2>\n
\u00bfQu\u00e9 es un ataque a la cadena de suministro?<\/strong> Un ataque a la cadena de suministro no apunta directamente a una empresa, sino a un componente que utilizan muchas empresas. Si se manipula una dependencia p\u00fablica, el c\u00f3digo malicioso fluye hacia cualquiera que instale el paquete a trav\u00e9s del m\u00e9todo de instalaci\u00f3n habitual.<\/p>\n
En el caso actual, afect\u00f3 a la biblioteca TypeScript @injectivelabs\/sdk-ts, una herramienta para aplicaciones relacionadas con la blockchain de Injective. Una versi\u00f3n manipulada inclu\u00eda una funci\u00f3n que se hac\u00eda pasar por telemetr\u00eda. En realidad, capturaba credenciales de acceso. La llamada para derivar una billetera a partir de un mnem\u00f3nico registraba la frase completa, y la llamada desde una clave privada registraba su material.<\/p>\n
Los datos capturados se codificaban en base64 y se enviaban silenciosamente mediante una solicitud de red a un punto final oculto. Para el desarrollador, el proceso permanec\u00eda invisible. El paquete cuenta con unas 50.000 descargas semanales. La versi\u00f3n manipulada se distribuy\u00f3 adem\u00e1s a trav\u00e9s de otros 17 paquetes de Injective. Quien incluyera uno de ellos resultaba afectado, sin haber instalado nunca directamente la biblioteca principal.<\/p>\n
C\u00f3mo entr\u00f3 la puerta trasera en el c\u00f3digo<\/h2>\n
La v\u00eda de entrada pas\u00f3 por el propio proyecto oficial. La funci\u00f3n maliciosa lleg\u00f3 al repositorio de GitHub a trav\u00e9s de commits realizados desde una cuenta con una larga historia de contribuciones. Este tipo de cuentas no generan sospechas. Precisamente eso hace tan efectivo el secuestro de un colaborador establecido.<\/p>\n
Lo llamativo fue el antecedente. Ya semanas antes del lanzamiento apareci\u00f3 en el repositorio una rama de prueba con el nombre expl\u00edcito de una comprobaci\u00f3n de puerta trasera. Estas huellas son evidentes retrospectivamente, pero f\u00e1ciles de pasar por alto en el d\u00eda a d\u00eda de un proyecto de c\u00f3digo abierto activo.<\/p>\n
Por qu\u00e9 afecta a cada compilaci\u00f3n<\/h2>\n
El incidente lleva una etiqueta de criptomonedas, pero el patr\u00f3n es universal. Cada aplicaci\u00f3n moderna extrae docenas o incluso cientos de paquetes externos, a menudo a trav\u00e9s de m\u00faltiples niveles. Basta con un \u00fanico eslab\u00f3n comprometido. Entonces, el c\u00f3digo malicioso se ejecuta con los permisos de la compilaci\u00f3n.<\/p>\n
Especialmente delicadas son las dependencias transitivas. Un equipo incluye conscientemente un paquete y hereda as\u00ed toda su cadena, que nunca ha verificado. Quien almacene credenciales, tokens o claves en un entorno de desarrollo con dependencias no verificadas est\u00e1 entregando exactamente lo que busca este tipo de ataque.<\/p>\n
Qu\u00e9 deben hacer ahora los desarrolladores y los equipos de seguridad<\/h2>\n
La primera pregunta es: \u00bfSe est\u00e1 ejecutando una versi\u00f3n afectada en su propia infraestructura? Sin un inventario fiable de dependencias, la respuesta se convierte en un juego de adivinanzas. Solo despu\u00e9s se activan las palancas t\u00e9cnicas.<\/p>\n
\nVerificaci\u00f3n inmediata<\/p>\n
- \n
- ✓<\/span>Rastrear la versi\u00f3n del SDK afectada en todos los proyectos, incluyendo integraciones directas y transitivas, y luego actualizar a la versi\u00f3n corregida.<\/li>\n
- ✓<\/span>Tratar todas las claves y mnem\u00f3nicos que pasaron por una versi\u00f3n afectada como comprometidas, rotarlas y mover los saldos.<\/li>\n
- ✓<\/span>Fijar las dependencias mediante archivos Lock y asumir las actualizaciones de forma consciente en lugar de autom\u00e1tica.<\/li>\n
- ✓<\/span>Verificar los certificados de origen (provenance de npm) y las firmas de paquetes, as\u00ed como mantener una lista de materiales de software (SBOM).<\/li>\n
- ✓<\/span>No almacenar secretos duraderos en entornos de compilaci\u00f3n con dependencias no verificadas y restringir rigurosamente los permisos en el sistema CI\/CD.<\/li>\n<\/ul>\n<\/div>\n
Las herramientas de an\u00e1lisis de dependencias reducen el tiempo de reacci\u00f3n porque detectan un paquete manipulado antes de que se despliegue ampliamente. Sin embargo, la verdadera palanca sigue siendo organizativa: quien no conoce su cadena de suministro, no puede protegerla.<\/p>\n
Un caso de prueba para la cadena de suministro<\/h2>\n
Injective declar\u00f3 haber resuelto el incidente en menos de una hora y no haber da\u00f1ado a ning\u00fan usuario. Esta valoraci\u00f3n proviene del propio proveedor. Independientemente de ello, la lecci\u00f3n permanece: la r\u00e1pida respuesta de un proyecto no exime a los usuarios de asegurar su propia cadena.<\/p>\n
Para las empresas con obligaciones derivadas de NIS2 o DORA, el riesgo de la cadena de suministro ya no es un tema abstracto. Ambos marcos normativos exigen que las organizaciones controlen los riesgos de sus proveedores y componentes. Un paquete manipulado en su propia compilaci\u00f3n es precisamente el caso para el que se redactaron estas disposiciones.<\/p>\n
Preguntas frecuentes<\/h2>\n
Cada pregunta est\u00e1 cerrada. Un toque desbloquea la respuesta.<\/p>\n
\n\u00bfQu\u00e9 es un ataque a la cadena de suministro?<\/strong><\/summary>\n
Un ataque a la cadena de suministro manipula un componente que muchos objetivos utilizan en com\u00fan, como una dependencia de software p\u00fablica. El c\u00f3digo malicioso fluye entonces a trav\u00e9s de la ruta de instalaci\u00f3n normal hacia todos los que integran el paquete.<\/p>\n<\/details>\n
\n\u00bfEstoy afectado si nunca instal\u00e9 directamente el SDK?<\/strong><\/summary>\n
Es posible. La versi\u00f3n manipulada se distribuy\u00f3 a trav\u00e9s de 17 paquetes adicionales. Quien inclu\u00eda uno de ellos heredaba la dependencia de forma transitiva, sin haber descargado nunca la biblioteca real directamente.<\/p>\n<\/details>\n
\n\u00bfBasta con actualizar a la versi\u00f3n corregida?<\/strong><\/summary>\n
Como primer paso s\u00ed, como \u00fanico no. Las claves y mnemonics que pasaron por una versi\u00f3n afectada se consideran comprometidas. Deben rotarse, y los saldos deber\u00edan moverse.<\/p>\n<\/details>\n
\n\u00bfC\u00f3mo lleg\u00f3 el c\u00f3digo malicioso a un proyecto oficial?<\/strong><\/summary>\n
Mediante commits de una cuenta con un largo historial de contribuciones en el repositorio oficial. Un colaborador establecido no despierta sospechas, lo que hace que la toma de control de dicha cuenta sea especialmente efectiva.<\/p>\n<\/details>\n
\n\u00bfQu\u00e9 protege m\u00e1s eficazmente contra estos ataques?<\/strong><\/summary>\n
Un inventario de dependencias conocido, archivos de bloqueo fijos, pruebas de origen verificadas y firmas, as\u00ed como permisos estrictos en la compilaci\u00f3n. Adem\u00e1s, no tener secretos duraderos en entornos con dependencias no verificadas.<\/p>\n<\/details>\n
Recomendaciones de lectura de la redacci\u00f3n<\/h3>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/06\/oauth-token-diebstahl-mfa-umgehung-device-code-saas-soc-cover-hero-250x143.jpg\")
<\/span>Recomendaci\u00f3n<\/span>Robo de tokens OAuth: c\u00f3mo los atacantes burlan el MFA<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/was-ist-ransomware-cover-hero-250x143.jpg\")
<\/span>Recomendaci\u00f3n<\/span>C\u00f3mo se desarrolla un ataque de ransomware<\/span><\/span><\/a>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/was-ist-edr-xdr-cover-hero-250x143.jpg\")
<\/span>Recomendaci\u00f3n<\/span>Lo que realmente diferencia a EDR y XDR<\/span><\/span><\/a><\/p>\nM\u00e1s de la red MBF Media<\/h3>\n
- ✓<\/span>Tratar todas las claves y mnem\u00f3nicos que pasaron por una versi\u00f3n afectada como comprometidas, rotarlas y mover los saldos.<\/li>\n
- Disfrazado como telemetr\u00eda.<\/strong> La funci\u00f3n maliciosa codificaba los datos en base64 y los enviaba silenciosamente a un punto final oculto.<\/li>\n