La cadena de suministro de software en alerta: paquetes dYdX comprometidos roban credenciales y permiten acceso remoto

La comunidad de seguridad acaba de identificar un nuevo incidente que vuelve a poner en primer plano una amenaza conocida pero cada vez más sofisticada: la cadena de suministro de software. Investigadores de Socket detectaron que versiones maliciosas de paquetes legítimos publicados en npm y PyPI fueron distribuidas con el objetivo de robar credenciales de billeteras de criptomonedas y, en el caso de Python, incluso obtener acceso remoto a los sistemas afectados. Puedes leer el análisis técnico en el informe original de Socket aquí: Socket: Malicious dYdX packages published to npm and PyPI.

Los paquetes comprometidos sirven a desarrolladores que integran funcionalidades del protocolo dYdX, una plataforma descentralizada de intercambio de derivados y operaciones sobre criptoactivos. En npm los nombres afectados son @dydxprotocol/v4-client-js, con varias versiones maliciosas detectadas; en PyPI el paquete afectado es dydx-v4-client en una versión post-publicada. dYdX confirmó el incidente en una serie de mensajes públicos y recomendó a los usuarios que hayan descargado esas versiones aislar los equipos, mover fondos desde un sistema limpio y rotar claves y credenciales. La publicación original de dYdX está disponible en X (antes Twitter): dYdX: comunicado.

Según los análisis, el atacante no explotó una vulnerabilidad técnica de los repositorios, sino que publicó nuevas versiones con credenciales de publicación legítimas, lo que apunta a la compromiso de cuentas de mantenedores. El actor malicioso introdujo código en ficheros centrales del paquete (por ejemplo, archivos de registro y cuenta), de modo que la carga dañina se ejecutaba durante el uso habitual de la librería. Esto muestra un conocimiento profundo de la estructura interna de los paquetes y de cómo se integran en aplicaciones que manipulan fondos y claves.

El payload en el ecosistema JavaScript se orienta a la exfiltración: recoge frases semilla de carteras y datos del dispositivo para enviarlos a un servidor controlado por el atacante. La variante de Python añade un componente más peligroso: un troyano de acceso remoto (RAT) que se ejecuta al importar el paquete y que consulta un servidor externo para recibir comandos. En concreto, ese componente contacta un endpoint observado por los investigadores y utiliza banderas del sistema operativo —por ejemplo, la bandera CREATE_NO_WINDOW en Windows— para ejecutarse sin mostrar ventanas y pasar desapercibido. Socket y otros analistas han destacado además un alto grado de ofuscación en la versión de PyPI, lo que sugiere intención de ocultar la actividad maliciosa y persistente.

Este suceso no nace de la nada: dYdX ya había sido blanco de ataques a la cadena de suministro en el pasado. En 2022 se reportó que cuentas de npm vinculadas al equipo fueron comprometidas y se publicaron paquetes que robaban credenciales, y en 2024 la web asociada con su plataforma v3 fue manipulada para redirigir a víctimas hacia un sitio de phishing. La recurrencia de estos incidentes pone de manifiesto que los actores maliciosos ven a proyectos con componentes financieros como objetivos de alto valor y que los canales de distribución confiables —repositorios oficiales, cuentas de mantenedores— son un vector muy atractivo para conseguir un gran impacto con poco ruido. Sobre el incidente de 2022 se puede consultar el hilo en GitHub y la cobertura en medios: GitHub issue y Bleeping Computer.

Además de los ataques dirigidos a paquetes existentes, los investigadores advierten sobre otra técnica preocupante: la publicación de paquetes "fantasma" con nombres referenciados en documentación o scripts pero nunca publicados oficialmente. Aikido hizo un estudio sobre este fenómeno y encontró que decenas de paquetes sin registro previo acumularon cientos de miles de descargas en meses recientes, simplemente porque usuarios ejecutaron comandos npx que intentaban invocar nombres inexistentes y, por tanto, el registro permitió la creación de paquetes con esos nombres. El análisis de Aikido detalla el riesgo del "npx confusion" y enumera ejemplos de paquetes que alcanzaron miles de descargas; puedes leer su informe aquí: Aikido: NPX confusion — unclaimed package names.

Este vector aprovecha una configuración por defecto que busca ser práctica pero que abre la puerta a la ejecución de código remoto sin una verificación explícita por parte del usuario. Como señaló uno de los investigadores, el ecosistema npm tiene millones de paquetes y los desarrolladores ejecutan comandos npx con mucha frecuencia; existe, por tanto, un gap entre la comodidad y el riesgo real de ejecutar código arbitrario desde la red.

Frente a estos problemas, hay medidas tanto inmediatas para usuarios afectados como prácticas preventivas para desarrolladores y organizaciones. dYdX recomendó —y es sensato repetir— que quien instaló las versiones maliciosas aísle el equipo, deje de usar las claves en ese entorno, mueva fondos desde un sistema que sepa limpio y rote todas las claves y API keys. A nivel operativo, Aikido y otros expertos recomiendan evitar que npx haga fallback para instalar paquetes desde el registro sin control: usar la opción npx --no-install impide la instalación automática y fuerza a que el comando falle si no existe localmente. También conviene instalar explícitamente las herramientas CLI que se usan con frecuencia y verificar siempre la existencia y reputación del paquete que la documentación sugiere ejecutar.

Para equipos de desarrollo y responsables de proyectos, las prácticas de mitigación incluyen exigir autenticación multifactor para cuentas de publicación, auditar y minimizar los derechos de las claves de publicación, cerrar sesiones y rotar credenciales ante cualquier sospecha de compromiso, y vigilar la cadena de dependencias con herramientas de Software Composition Analysis (SCA). Mantener ficheros lock (lockfiles) en los repositorios, pinnear versiones, revisar cambios en dependencias transitorias y validar firmas o sumas de paquetes cuando sea posible son medidas que reducen la superficie de riesgo. Asimismo, registrar variantes obvias de nombres de paquetes o alias puede ser una barrera contra actores oportunistas que intenten publicar paquetes con nombres confundibles.

Este incidente es una llamada de atención: la confianza que depositamos en repositorios centrales y en cuentas de mantenedores es un activo que debe cuidarse con la misma seriedad que las llaves privadas en el mundo cripto. Los atacantes prefieren "moverse upstream" porque comprometer una sola identidad de publicación puede afectar a miles o millones de usuarios de una sola vez, con muy poco ruido en los sistemas de detección convencionales. Como resume un análisis sectorial, la tendencia es clara: tanto ataques dirigidos a mantenedores concretos como campañas a gran escala que aprovechan configuraciones por defecto están en aumento, y la defensa exige simultáneamente controles técnicos, procesos organizativos y una mayor higiene en la gestión de cuentas y claves. Un buen resumen sobre la evolución reciente de estas amenazas está en el reporte de Sygnia sobre supply chain: Sygnia: Supply chain attacks Q4 2025.

Si trabajas en proyectos que interactúan con firmas, transacciones o almacenan secretos relacionados con criptoactivos, recuerda que la exposición principal no siempre está en tu código: a veces está en la cadena que trae ese código a tus entornos. Revisa dependencias críticas, proteja las cuentas con capacidad de publicar, y cuando onboarding de herramientas incluya ejecutar comandos remotos, detente un momento y verifica la procedencia. La conveniencia tiene un coste si no la acompañamos de controles mínimos de seguridad.

Para más contexto y lecturas adicionales sobre el incidente y los vectores involucrados, revisa la cobertura técnica en Socket, el comunicado de dYdX, el análisis de Aikido y la cobertura histórica en Bleeping Computer y GitHub enlazados en el texto anterior.