Un solo commit malicioso bastó para poner en riesgo miles de wallets cripto. El 8 de julio de 2026, atacantes desconocidos comprometieron el repositorio de GitHub de Injective Labs y publicaron en npm una versión envenenada de su SDK oficial, diseñada para robar claves privadas y frases semilla de wallets de criptomonedas. El paquete afectado, @injectivelabs/sdk-ts, acumula unas 50.000 descargas semanales y es la base de exchanges descentralizados, bots de trading y aplicaciones DeFi. Si desarrollas con este ecosistema, esto te interesa — y mucho.
¿Qué pasó exactamente con el SDK de Injective en npm?
Según reportaron The Hacker News y BleepingComputer, los atacantes introdujeron el código malicioso directamente en el repositorio oficial de GitHub mediante commits enviados desde la cuenta de un desarrollador con historial legítimo de contribuciones al proyecto. Es decir, no fue un paquete falso con nombre parecido (typosquatting), sino el paquete real, comprometido desde dentro de su propia cadena de publicación.
Lo más preocupante: el atacante aprovechó el pipeline de publicación confiable del repositorio (OIDC / trusted publishing) para firmar y publicar la versión maliciosa 1.20.21 como si fuera una release oficial. La misma versión envenenada se replicó en 17 paquetes adicionales del scope @injectivelabs.
Cómo funcionaba el malware: telemetría falsa que robaba tus claves
El código malicioso se disfrazaba de una función de telemetría anónima, según el análisis técnico de Datadog Security Labs. A diferencia de otros ataques de cadena de suministro que se ejecutan al instalar el paquete, este malware era más sigiloso:
Se activaba únicamente cuando el desarrollador usaba las funciones del SDK que generan o importan claves de wallet. En ese momento, capturaba la frase semilla (mnemonic) completa y la clave privada, las codificaba en base64 y las exfiltraba al servidor del atacante camuflando el envío como datos de telemetría. Un diseño pensado para pasar desapercibido en auditorías superficiales.
El alcance del ataque en números
La versión maliciosa estuvo disponible en npm durante menos de una hora antes de ser detectada y deprecada. En ese lapso, la firma de seguridad Socket registró 310 descargas del paquete comprometido. Injective Labs publicó rápidamente la versión limpia 1.20.23 y, según todos los reportes, no se registraron pérdidas de fondos. Eso sí: los artefactos maliciosos de la release en GitHub seguían disponibles días después, un recordatorio de que “deprecar” no es lo mismo que “eliminar”.
¿Por qué este ataque debería preocupar a todos los desarrolladores?
Este incidente confirma una tendencia alarmante de 2026: los atacantes ya no crean paquetes falsos, sino que comprometen las cuentas y pipelines de proyectos legítimos. Cuando el malware llega firmado por el publisher oficial, las defensas tradicionales (verificar el nombre del paquete, revisar el número de descargas, confiar en releases firmadas) dejan de ser suficientes.
Además, el malware activado por comportamiento — que solo actúa cuando manipulas claves — evade los análisis estáticos básicos y los sandboxes de instalación. La cadena de suministro de software se ha convertido en el eslabón más débil, y los proyectos cripto son el objetivo perfecto: el botín es dinero programable e irreversible.
Cómo protegerte: medidas concretas
Si usas @injectivelabs/sdk-ts o cualquiera de sus paquetes relacionados: actualiza de inmediato a la versión 1.20.23 o superior, considera comprometida cualquier clave privada o frase semilla que haya pasado por la versión 1.20.21 y rótala cuanto antes, y revisa tus dependencias transitivas con npm ls @injectivelabs/sdk-ts. Como práctica general: fija versiones exactas (lockfiles), usa herramientas de análisis de dependencias como Socket o npm audit, y desconfía de cualquier “telemetría” nueva en un changelog.
Preguntas frecuentes
¿Perdieron dinero los usuarios de Injective?
No. La versión maliciosa estuvo activa menos de una hora y fue descargada 310 veces. Injective confirmó que no hubo pérdida de fondos, aunque recomienda rotar cualquier clave que haya pasado por la versión comprometida.
¿Qué versiones del SDK de Injective son seguras?
La versión 1.20.21 de @injectivelabs/sdk-ts (y de otros 17 paquetes del scope @injectivelabs) es la comprometida. La versión segura publicada tras el incidente es la 1.20.23 o superior. Si tienes la 1.20.21, actualiza y rota tus claves ya.
¿Cómo puedo detectar un ataque de cadena de suministro en npm?
Revisa los cambios entre versiones antes de actualizar, usa lockfiles con versiones fijas, monitorea tus dependencias con herramientas como Socket, Datadog SCA o npm audit, y presta especial atención a paquetes que de pronto agregan funciones de red o “telemetría” no documentadas.
Conclusión
El caso Injective demuestra que hasta los proyectos con pipelines de publicación modernos y firmados pueden ser comprometidos si una sola cuenta de contribuidor cae en manos equivocadas. La respuesta en menos de una hora evitó una catástrofe, pero la lección queda: en la cadena de suministro de software, la confianza debe verificarse en cada release. Audita tus dependencias hoy — antes de que una “actualización rutinaria” vacíe una wallet.
Fuentes: The Hacker News, BleepingComputer, Datadog Security Labs, Socket.