Un ataque coordinado a la cadena de suministro impactó a la comunidad de desarrolladores el 16 de marzo de 2026, cuando un actor de amenazas conocido como Glassworm introdujo puertas traseras en dos paquetes npm populares de React Native, convirtiéndolos en ladrones silenciosos de credenciales y criptomonedas. Los paquetes afectados —react-native-country-select@0.3.91 y react-native-international-phone-number@0.11.8— fueron publicados con minutos de diferencia por el mismo editor, AstrOOnauta

Un ataque coordinado a la cadena de suministro impactó a la comunidad de desarrolladores el 16 de marzo de 2026, cuando un actor de amenazas conocido como Glassworm introdujo puertas traseras en dos paquetes npm de React Native ampliamente utilizados, convirtiéndolos en ladrones silenciosos de credenciales y criptomonedas.

Los paquetes afectados — react-native-country-select@0.3.91 y react-native-international-phone-number@0.11.8 — fueron publicados con minutos de diferencia por el mismo editor, AstrOOnauta, y juntos acumularon más de 134.887 descargas en el mes previo al ataque.

Ambos paquetes gestionan tareas de interfaz de usuario móvil, como la entrada de números de teléfono y la selección de países, lo que los convertía en componentes confiables en muchos proyectos de desarrolladores.

El ataque no requería ninguna acción especial por parte de sus objetivos. Cualquier desarrollador, entorno de integración continua (CI) o agente de compilación que ejecutara un simple comando npm install era suficiente para activar el malware.

Ambas versiones maliciosas introdujeron un nuevo hook preinstall que ejecutaba un archivo JavaScript fuertemente ofuscado llamado install.js antes incluso de que el paquete terminara de instalarse en el equipo.

Este diseño hizo que la infección fuera prácticamente invisible, ya que los desarrolladores no tenían motivos para sospechar que una actualización rutinaria de un paquete estaba desplegando silenciosamente una carga útil de Windows en múltiples etapas directamente en sus máquinas.

Investigadores de Aikido identificaron ambos paquetes con puertas traseras y rastrearon toda la cadena de ejecución siguiendo los mismos pasos que toma el malware, recuperando y descifrando las cargas útiles en vivo de la segunda y tercera etapa sin ejecutarlas.

Su análisis confirmó que el archivo de carga era idéntico en bytes en ambos paquetes, compartiendo el mismo hash SHA-256.

Los cambios de versión también fueron limpios: el comportamiento malicioso se introdujo únicamente a través de un nuevo archivo install.js y una entrada preinstall correspondiente en el package.json, lo que sugiere una modificación deliberada y dirigida en lugar de un error de compilación.

La escala de exposición potencial fue grave. Solo en la semana del ataque, los dos paquetes sumaron 29.763 descargas, y 134.887 en el mes anterior.

Las versiones limpias inmediatamente anteriores a las versiones maliciosas — @0.3.9 y @0.11.7 — no contenían ningún hook malicioso y habían sido publicadas apenas tres días antes, el 13 de marzo de 2026.

Los desarrolladores que construían aplicaciones móviles con funciones de entrada de números de teléfono o selección de países estaban directamente en riesgo, pero cualquier proyecto que incluyera estos paquetes como dependencias indirectas enfrentaba el mismo peligro.

Ejecución en múltiples etapas: cómo se desarrolló el ataque

La cadena de infección estaba cuidadosamente estratificada, utilizando múltiples etapas y servicios legítimos de terceros para permanecer oculta.

Una vez que install.js se ejecutaba en una máquina con Windows, primero escaneaba el sistema en busca de marcadores de idioma ruso —incluyendo variables configuradas como ru_RU, ru-RU o Russian— y también verificaba las zonas horarias vinculadas a Rusia.

Si estos indicadores estaban presentes, el malware se detenía sin realizar ninguna acción, una táctica consistentemente observada en malware criminal asociado a actores de amenazas de habla rusa.

Si la verificación de localización pasaba, el instalador consultaba una cuenta de la blockchain de Solana utilizando el método RPC getSignaturesForAddress para recuperar una URL codificada en base64 oculta dentro de un memo de transacción.

Usar una cuenta pública de blockchain como relay de entrega hacía que la dirección de la segunda etapa fuera muy difícil de bloquear mediante filtrado de dominios o redes convencionales.

El script de la segunda etapa devuelto proporcionaba claves de descifrado para desbloquear la carga útil de la tercera etapa: un stealer completo enfocado en Windows.

Esa tercera etapa establecía persistencia a través del Programador de Tareas de Windows y la clave de registro Run, luego utilizaba un enlace de Google Calendar como relay adicional antes de descargar más componentes desde un servidor controlado por el atacante.

La carga final recopilaba datos de billeteras de MetaMask, Exodus, Atomic, Guarda, Coinomi, Trust Wallet y OKX Wallet, además de robar tokens de npm y credenciales de GitHub mediante comandos nativos de credenciales.

Los desarrolladores deben auditar inmediatamente los archivos de bloqueo (lock files) en busca de react-native-country-select@0.3.91 o react-native-international-phone-number@0.11.8 y tratar cualquier máquina que haya instalado alguna de estas versiones como comprometida.

Rota todos los tokens de npm, credenciales de GitHub y claves de billeteras de criptomonedas que estuvieran accesibles en los sistemas afectados.

Revisa los registros de red salientes en busca de conexiones a 45[.]32[.]150[.]251 y 217[.]69[.]3[.]152. Auditar los scripts del ciclo de vida de los paquetes y marcar hooks preinstall inesperados en los entornos de compilación reduce la exposición a ataques similares a la cadena de suministro.