- Varias campañas han abusado de paquetes y herramientas npm de confianza de React Native, desde componentes de interfaz de usuario hasta utilidades de línea de comandos, mediante el robo de cuentas y el typosquatting.
- Los atacantes despliegan cada vez más malware sofisticado de varias etapas utilizando Solana o servidores C2 descentralizados, dirigido a las máquinas de los desarrolladores, las canalizaciones de integración continua y los datos de monederos o credenciales.
- Actualmente, los proveedores de seguridad confían en el análisis mediante IA, las comprobaciones de tiempo de espera y los controles de salida de infraestructura crítica reforzados para detectar y contener estos ataques a la cadena de suministro en cuestión de minutos.
- Los equipos que trabajan con React Native deben combinar una estricta gestión de dependencias, la autenticación de dos factores (2FA) de npm, archivos de bloqueo y monitorización continua para reducir significativamente el riesgo en la cadena de suministro.
React Native se ha convertido en un framework de referencia para la creación de aplicaciones móviles, lo que convierte a su ecosistema npm en un objetivo extremadamente atractivo para los atacantes que buscan comprometer las máquinas de los desarrolladores y los flujos de trabajo de integración continua (CI). En los últimos años, varias campañas muy sofisticadas han abusado de paquetes de React Native de confianza, herramientas populares relacionadas con el framework e incluso utilidades typosquatting para instalar malware, robar credenciales, extraer monederos y sabotear proyectos de JavaScript a gran escala.
Si hoy en día desarrollas o mantienes aplicaciones React Native, ya no basta con simplemente "instalar con npm y esperar lo mejor". Diversos actores maliciosos están abusando sistemáticamente de npm, atacando desde componentes de interfaz de usuario hasta herramientas de línea de comandos, e incluso el gráfico de dependencias transitivas que se oculta en los archivos de bloqueo. Este artículo analiza los principales incidentes conocidos, explica cómo funciona el malware y presenta medidas prácticas que puede tomar para reducir el impacto en su entorno de desarrollo.
Robo de cuentas y malware en componentes de entrada de React Native
Uno de los incidentes más alarmantes en la cadena de suministro en el mundo de React Native afectó a dos componentes de interfaz de usuario muy comunes para la selección de teléfono y país: react-native-international-phone-number además react-native-country-select. Ambos paquetes, mantenidos por el mismo autor (@AstrOOnauta, usuario de npm astroonauta), acumularon decenas de miles de descargas semanales y están integradas en muchas aplicaciones móviles de producción.
El 16 de marzo de 2026, el analizador de paquetes basado en IA de StepSecurity fue el primero en detectar que las nuevas versiones de estas bibliotecas habían adquirido repentinamente malware durante la instalación. Los lanzamientos comprometidos de inmediato fueron react-native-international-phone-number@0.11.8 además react-native-country-select@0.3.91Las últimas versiones limpias confirmadas en ese momento fueron: 0.11.7 además 0.3.9 respectivamente.
La puerta trasera inicial (Ola 1) fue brutalmente simple: una nueva preinstall guion y un altamente ofuscado install.js archivo incluido en el archivo tar. El malicioso package.json El fragmento tenía este aspecto:
"scripts": { "preinstall": "node install.js" }
Porque los scripts del ciclo de vida de npm se ejecutan automáticamente en npm installCualquiera que descargara estas versiones, ya sea localmente o en CI, ejecutaba el malware sin importar ningún código. No había etiquetas Git, versiones o ejecuciones de flujo de trabajo de CI correspondientes para las versiones comprometidas, y la gitHead Coincidía con la versión anterior, un buen indicador de que el atacante había obtenido acceso directo de publicación a la cuenta npm del mantenedor en lugar de modificar el repositorio de GitHub.
Los datos de descargas en ese momento subrayan lo malo que podría haber sido: aproximadamente 9,000 descargas semanales para react-native-country-select y más de 20,000 para react-native-international-phone-numberlo que suma más de 130,000 descargas mensuales entre ambas plataformas. Este es precisamente el tipo de dependencia de alto volumen y baja visibilidad que se instala silenciosamente en miles de máquinas de desarrolladores y de integración continua.
Ataque en tres fases: desde la preinstalación obvia hasta las cadenas de dependencias sigilosas.
La campaña contra estos paquetes de React Native se desarrolló en tres oleadas distintas, cada una más evasiva que la anterior, pero reutilizando el mismo malware principal. StepSecurity realizó un seguimiento de la evolución prácticamente en tiempo real y se coordinó con el responsable del mantenimiento, pero el atacante recuperó o mantuvo repetidamente el acceso a la cuenta npm comprometida.
La ola 1 (16 de marzo de 2026) se centró en la dirección preinstall Enganche en ambos paquetes. Aproximadamente cinco minutos después de la publicación, la IA de StepSecurity marcó las nuevas versiones como críticas y se abrieron problemas en GitHub: #165 para react-native-international-phone-number y el número 11 para react-native-country-selectEl mantenedor respondió rápidamente, descontinuando las versiones maliciosas y lanzando una versión limpia. react-native-country-select@0.4.0El tiempo total transcurrido desde la publicación hasta la descontinuación fue de aproximadamente 2 horas y 21 minutos, un tiempo rápido para los estándares del ecosistema.
A pesar de esto, el atacante nunca perdió el control de las credenciales de npm, lo que dio lugar a la segunda oleada el 17 de marzo. En lugar de volver a insertar un script obvio en los paquetes principales, el atacante creó dos nuevos paquetes con alcance definido para que actuaran como infraestructura oculta:
@usebioerhold8733/s-format@2.0.1– un clon hueco destring-formatconpostinstall: "node init.js"guion pero falta elinit.jsarchivo, por lo que el gancho falla silenciosamente.@agnoliaarisian7180/string-argv@0.3.0– un paquete casi vacío (README, LICENSE, package.json) cuyo único propósito real era depender de@usebioerhold8733/s-format, con una dirección de mantenedor basada en ProtonMail.
Más tarde esa noche, react-native-international-phone-number@0.12.1 fue publicado con @agnoliaarisian7180/string-argv@0.3.0 Se agregó como una nueva dependencia, nuevamente sin ninguna actividad en GitHub Actions. En ese momento, la cadena estaba preparada pero inactiva, a la espera de que se activara la carga útil. Cuando StepSecurity informó de la anomalía, el responsable del mantenimiento confirmó lo que ya era evidente a partir de los artefactos: "Mi cuenta de npm fue atacada y la biblioteca fue secuestrada".
La tercera oleada (18 de marzo) transformó la infraestructura por etapas en una cadena de distribución de malware multicapa activa y, posteriormente, la perfeccionó en rápida sucesión. En menos de una hora se publicaron nuevas versiones tanto de los paquetes de retransmisión como de la biblioteca principal, mientras el atacante experimentaba con diferentes métodos para lanzar la carga útil.
La cadena final tenía este aspecto:
react-native-international-phone-number@0.12.2/0.12.3 → @agnoliaarisian7180/string-argv@latest → @usebioerhold8733/s-format@latest → postinstall → node child.js → init.js (malware)
El atacante activó primero la carga útil en @usebioerhold8733/s-format@2.0.2 agregando un gran y ofuscado init.js archivo que era idéntico byte a byte al anterior install.js de la Ola 1. Luego cambiaron el postinstall llamar child.js en lugar de init.jspublicado 2.0.3 con el guion faltante (otra prueba), y finalmente enviado 2.0.4 con un pequeño child.js cargador que simplemente comprueba init.js y lo ejecuta a través de child_process.exec mientras se descartan los errores y la salida de stderr.
Al mismo tiempo, @agnoliaarisian7180/string-argv@0.3.1 cambió su dependencia de s-format de una versión fijada a "latest"y el ámbito react-native-international-phone-number@0.12.2 hizo lo mismo con string-argv. Esto creó una cadena maliciosa de actualización automática en la que cada instalación del paquete principal descargaba automáticamente la versión más reciente de la carga útil.
Finalmente, react-native-international-phone-number@0.12.3 Se eliminó el gancho de preinstalación, ahora innecesario (para que tuviera un aspecto más limpio), se mantuvo la cadena de dependencias maliciosas y se cambió el correo electrónico del mantenedor de npm a otra cuenta de ProtonMail que no pertenece al autor original. Esa era una clara señal de que el atacante estaba consolidando un control persistente sobre la identidad de npm, y no simplemente reutilizando de forma oportunista un token filtrado.
Dentro del malware respaldado por Solana que ataca a los desarrolladores de React Native
En el fondo, la carga útil que se ejecutaba en las tres oleadas era el mismo malware sofisticado de múltiples etapas que abusa de la cadena de bloques Solana como un canal dinámico de comando y control. El mecanismo de entrega fue cambiando, pero el "arma" se mantuvo idéntica en todas las iteraciones, hasta el punto de ser el mismo archivo byte a byte cuando se trasplantaba de la Ola 1 a la infraestructura de la Ola 3.
El guion comienza con un retraso deliberado de 10 segundos usando setTimeout, un truco clásico para evadir la trampa. Muchas herramientas de seguridad y entornos aislados automatizados solo dan a los scripts un breve período de ejecución antes de decidir que no ha ocurrido nada sospechoso, por lo que el malware simplemente espera a que finalice el plazo antes de hacer algo interesante.
A continuación, realiza un geofiltro para evitar infectar sistemas en Rusia y partes de la CEI. Inspecciona variables de entorno como LANG, LANGUAGE, LC_ALL, información del usuario anfitrión, la zona horaria del sistema e incluso desplazamientos UTC sin procesar, buscando valores que indiquen una configuración regional rusa (como ru_RU or Russian) o una de las zonas horarias de Rusia/CEI. Si alguna coincide, el script finaliza de inmediato y sin mostrar ningún mensaje de error.
Solo si el entorno supera esa comprobación, el malware comenzará a comunicarse con la cadena de bloques de Solana. Contiene una dirección de billetera codificada y la consulta a través de la getSignaturesForAddress Método JSON-RPC en nueve puntos finales Solana RPC diferentes alojados por varios proveedores. Este diseño proporciona al atacante alta disponibilidad y hace que el bloqueo simple de dominio o IP sea ineficaz.
El truco consiste en que el atacante oculta la URL de la siguiente fase de la carga útil dentro del campo de memo de las transacciones de Solana dirigidas a esa billetera. El memo almacena un bloque de JSON codificado en base64 cuya link El campo contiene la URL de la siguiente etapa. Al publicar una nueva transacción, el operador puede rotar la URL de la carga útil en cualquier momento sin modificar los paquetes npm publicados.
Una vez extraída la URL, el malware realiza una solicitud HTTP al servidor del atacante en http://45.32.150.251/, enviando el tipo de sistema operativo en un personalizado os encabezado para que el C2 pueda devolver binarios específicos de la plataforma. El cuerpo de la respuesta contiene la carga útil cifrada, pero la clave AES-256 y el IV necesarios para descifrarla se envían únicamente en los encabezados HTTP (secretkey además ivbase64), por lo que cualquier dato corporal almacenado en caché o interceptado es inútil por sí solo.
La segunda etapa descifrada nunca toca el disco; se ejecuta en la memoria con eval(atob(...)) en sistemas tipo Unix o a través de vm.Script en Windows con acceso completo a los componentes internos de Node. Después, el malware deja caer un ~/init.json Archivo marcador que almacena una marca de tiempo y un identificador único para evitar que la misma máquina se vuelva a infectar más de una vez cada 48 horas. Esta limitación de velocidad reduce drásticamente el ruido y ofrece a los defensores menos indicadores de comportamiento a los que aferrarse.
La carga útil de la tercera etapa, descifrada mediante AES y recuperada por los investigadores al reproducir los mismos pasos de Solana y HTTP, es un programa para robar credenciales y monederos, además de un cargador, centrado en Windows. Establece persistencia con schtasks y Run clave de registro, descarga módulos cifrados adicionales desde 45.32.150.251y extrae el botín resultante a una IP en el rango 217.69.3.x.
Este programa malicioso busca datos de monederos de escritorio y extensiones de navegador como MetaMask, Phantom, Exodus, Atomic, Guarda, Coinomi, Daedalus, OKX Wallet, Trust Wallet, Braavos y más, recorriendo las carpetas de perfil del navegador y los directorios de monederos locales después de cerrar forzosamente Chrome y Firefox. Además, extrae los tokens de npm y las credenciales de GitHub directamente de la configuración local y de los asistentes de credenciales, convirtiendo los equipos de desarrolladores comprometidos en plataformas de lanzamiento perfectas para futuros ataques a la cadena de suministro.
Cabe destacar que el malware incluso descarga sus propios entornos de ejecución de Node.js (v22.9.0) tanto para x86 como para x64 en %APPDATA%\_node_x86 además %APPDATA%\_node_x64, garantizar que disponga de un entorno de ejecución coherente incluso cuando Node no esté instalado en el sistema de destino.
Enlaces a ForceMemo y al actor de amenazas GlassWorm
La huella técnica de este incidente de npm en React Native coincide casi a la perfección con una campaña anterior denominada "ForceMemo", que comprometió cientos de repositorios de Python en GitHub. Ambas operaciones utilizaron Solana como un punto de entrega C2, el mismo grupo de nueve puntos finales RPC, el mismo formato de memo JSON con un link campo, lógica de geofiltrado idéntica para Rusia/CEI, la misma ~/init.json bloqueo de persistencia e incluso rangos de infraestructura similares alojados en Vultr.
Aunque las direcciones de la cartera Solana difieren entre las dos campañas, todo lo demás apunta a un único actor altamente capacitado, que se cree que es el grupo conocido como GlassWorm. ForceMemo atacaba a los desarrolladores mediante repositorios de GitHub infectados, mientras que el incidente de React Native lo hacía a través de paquetes npm y sus cadenas de dependencias. La estrategia es clara: reutilizar un marco de malware sofisticado y modular, pero integrándolo en diferentes canales de distribución para llegar al mayor número posible de entornos de desarrollo.
Otras campañas maliciosas de npm relacionadas con React Native y JavaScript
La vulnerabilidad AstroNauta es solo una parte de una oleada más amplia de ataques basados en npm que afectan a las aplicaciones React Native de forma directa o indirecta. Varios proveedores de seguridad han documentado campañas paralelas centradas en las bibliotecas de interfaz de usuario de React Native, las herramientas principales de la interfaz de línea de comandos e incluso los complementos de compilación genéricos de los que dependen muchas bases de código de React Native.
Aikido Security descubrió en junio de 2025 una importante operación en la cadena de suministro que introdujo puertas traseras en al menos 16 paquetes relacionados con React Native. @react-native-aria/* alcance más @gluestack-ui/utils, que en conjunto generan alrededor de un millón de descargas semanales. La brecha inicial ocurrió el 6 de junio de 2025, comenzando con @react-native-aria/focus@0.2.10, luego se expandió rápidamente a través de paquetes adicionales de enfoque, superposición, interacción, interruptor, casilla de verificación, radio, botón, menú, cuadro de lista, pestañas, cuadro combinado, divulgación, control deslizante, separador y las utilidades GlueStack el 7 de junio.
El malware de esa campaña era un troyano de acceso remoto (RAT) adaptado a entornos Windows, que persistía bajo %LOCALAPPDATA%\Programs\Python\Python3127 y conectándose a los servidores C2 en 136.0.9[.]8 además 85.239.62[.]36. Entre sus capacidades se incluían la ejecución de comandos arbitrarios, la carga y descarga de archivos y el acceso remoto a largo plazo. Su persistencia implicaba que, simplemente actualizando a una versión limpia de la biblioteca React Native, no se limpiaban las máquinas ya infectadas.
Otra campaña de larga duración, descubierta por el equipo de investigación de amenazas de Socket, utilizó el typosquatting y la mimetización para instalar paquetes destructivos que atacan explícitamente a marcos de trabajo JavaScript populares como React, Vue, Vite y Quill. El actor de la amenaza, usando el alias de npm xuxingfengDurante más de dos años, publicó una mezcla de paquetes legítimos y maliciosos, creando una impresión superficial de ser un mantenedor de confianza.
Paquetes como vite-plugin-bomb, vite-plugin-bomb-extend, vite-plugin-react-extend, vite-plugin-vue-extend además vue-plugin-bomb No fueron diseñados para robar datos, sino para corromper o destruir proyectos activamente. Implementaron ataques multifase activados por fechas específicas, eliminando archivos de marco críticos en node_modules (Vue, React, Vite, TypeScript, Ant Design Vue, Pinia, ECharts y más), a veces junto con apagados forzados del sistema cada segundo usando shutdown -s -t 5.
Un paquete particularmente desagradable, js-hood, manipulado prototipos centrales de JavaScript como Array.prototype.filter, map, push, pop y múltiple String métodos, reemplazándolas con funciones que parecen sintácticamente válidas pero que devuelven datos aleatorios. Esto da como resultado aplicaciones que siguen ejecutándose pero producen resultados corruptos y no deterministas que son extremadamente difíciles de depurar.
La quill-image-downloader La serie tomó otro rumbo, centrándose en el sabotaje del almacenamiento por parte del cliente. Se envió una arquitectura de tres archivos que, después de una fecha de activación específica, itera sobre todas las claves en localStorage, sessionStorage y las cookies, y luego mezcla parcialmente sus valores con caracteres aleatorios mientras conserva la estructura. Los tokens de autenticación, los carritos de compra, las preferencias del usuario y cualquier estado del lado del navegador se corrompen sutilmente, lo que provoca fallos intermitentes que muchos equipos inicialmente atribuirían a errores de la aplicación.
Una investigación independiente de OP Innovate descubrió un grupo de diez paquetes npm maliciosos que suplantaban bibliotecas conocidas como TypeScript, discord.js, ethers.js, nodemon, react-router-dom además zustand. Una vez instalados, estos paquetes presentan una ventana CAPTCHA falsa, obtienen la huella digital del host y descargan un gran programa de robo de información multiplataforma desde un servidor C2 en 195.133.79.43, de nuevo con soporte explícito para Windows, macOS y Linux.
Finalmente, la campaña CanisterWorm, detallada por Aikido, demostró hasta dónde están dispuestos a llegar los atacantes para explotar npm como vehículo de distribución. Más de 135 paquetes de una cuenta de editor comprometida fueron modificados con scripts de instalación que se ejecutan antes que cualquier código de la aplicación o pasos de compilación. Las etapas posteriores se comportan de manera diferente según si se instalan en un entorno de desarrollo local, un trabajo de CI o un nodo de compilación en contenedores, y se comunican con un contenedor descentralizado de Internet Computer (ICP) que funciona como un C2 oculto, lo que permite a los operadores cambiar el comportamiento sobre la marcha sin volver a tocar el registro de npm.
Vulnerabilidades críticas en las herramientas de React Native: la vulnerabilidad RCE de la CLI de la comunidad
No todos los riesgos de seguridad de React Native provienen de paquetes directamente maliciosos; algunos se derivan de vulnerabilidades graves en herramientas de uso generalizado. Un caso destacable es el de CVE-2025-11953 en la interfaz de línea de comandos de la comunidad de React Native, un paquete que los desarrolladores descargan millones de veces cada semana en Windows, macOS y Linux.
Esta vulnerabilidad permitía la ejecución remota de código (RCE) sin autenticación mediante solicitudes POST manipuladas al servidor de desarrollo local iniciado por la interfaz de línea de comandos (CLI). Debido a que muchos desarrolladores exponen sus servidores metro/dev en la red para depuración o pruebas en dispositivos móviles, un atacante cercano (o alguien que pueda redirigir el tráfico a esos puertos) podría ejecutar comandos arbitrarios en la máquina del desarrollador.
El impacto va mucho más allá de una sola estación de trabajo de desarrollador: Una vez que un atacante logra ejecutar código en un entorno de desarrollo, puede acceder a las redes corporativas, robar credenciales, manipular compilaciones o alterar los flujos de CI/CD que se sincronizan desde esa máquina. Es un ejemplo clásico de cómo una simple herramienta de desarrollo local se convierte en parte de la superficie de ataque en entornos de producción cuando se trabaja con sistemas conectados a la nube.
La mitigación recomendada es sencilla pero innegociable: actualizar a React Native Community CLI 12.5.1 o superior, auditar los registros en busca de solicitudes POST sospechosas o procesos inesperados iniciados por el servidor de desarrollo, restringir el acceso a los servidores locales e integrar las herramientas de desarrollo en su estrategia de detección de amenazas. Trata cualquier punto final de DevOps o de desarrollo como un objetivo de alto valor, porque así es precisamente como lo ven los atacantes modernos.
Cómo respondieron los defensores: análisis de IA, tiempos de espera y CI reforzado
Lo positivo de estas historias es que la comunidad de seguridad está mejorando en rapidez y sofisticación la detección de amenazas a la cadena de suministro contra React Native y el entorno JavaScript en general. Herramientas como StepSecurity, Socket y Aikido Security invierten mucho en análisis de comportamiento, comparaciones automatizadas y modelos de aprendizaje automático que analizan las nuevas versiones de npm a los pocos minutos de su publicación.
En el ataque AstroNauta, el analizador de paquetes con IA de StepSecurity detectó versiones maliciosas en menos de cinco minutos, abrió incidencias en GitHub con análisis técnicos completos y, posteriormente, informó a npm sobre los paquetes de infraestructura utilizados por el atacante para su eliminación. El equipo documentó cada oleada, realizó un seguimiento de las versiones de Git, analizó el código ofuscado, demostró el uso de Solana C2 y proporcionó al responsable del mantenimiento instrucciones paso a paso para la corrección del problema.
Más allá de la detección, los controles preventivos están empezando a ganar terreno en los flujos de trabajo de integración continua. Por ejemplo, la herramienta npm Package Cooldown Check de StepSecurity permite a las organizaciones bloquear dependencias publicadas hace apenas unas horas, lo que da tiempo a los escáneres y a los usuarios para inspeccionarlas. Su comprobación de actualizaciones comprometidas contrasta una lista actualizada constantemente de paquetes conocidos como defectuosos y rechaza las solicitudes de extracción que intentan añadirlos o actualizarlos.
Las herramientas que tienen en cuenta la red, como Harden-Runner, restringen las conexiones salientes en GitHub Actions y otros trabajos de CI a una lista permitida de puntos finales esperados. En un mundo donde el malware obtiene cargas útiles de nodos RPC de Solana, URL de Google Calendar, rangos de IP de Vultr o contenedores ICP, restringir la salida de sus sistemas de compilación puede marcar la diferencia entre una mala comparación de paquetes y una intrusión en toda regla.
En lo que respecta a la respuesta, funciones como la búsqueda de paquetes en toda la organización y los centros de amenazas ayudan a los equipos a delimitar rápidamente el radio de la explosión. En cuanto se identifica un paquete o complemento de React Native comprometido, los equipos de seguridad pueden ver qué repositorios, ramas y archivos de bloqueo lo incluyen, qué trabajos lo ejecutaron y qué máquinas se comunicaron con direcciones IP sospechosas, y luego priorizar la remediación en consecuencia en docenas o cientos de bases de código.
Acciones prácticas para equipos de React Native que se enfrentan al malware de npm
Tanto para los desarrolladores de React Native como para los ingenieros de seguridad, defenderse de los ataques a nivel de npm consiste en combinar la higiene en las máquinas individuales con medidas de protección en la integración y entrega continuas (CI/CD) y la gestión de dependencias. Ningún control por sí solo te salvará, pero las defensas por capas reducen drásticamente las probabilidades de que un paquete malicioso se convierta en una vulneración total de la seguridad.
Si utiliza los paquetes comprometidos mencionados anteriormente, deberá realizar algunas comprobaciones inmediatas. Para el incidente Astronauta, pin react-native-international-phone-number a la versión 0.11.7 además react-native-country-select a 0.4.0, evitando todas las versiones marcadas como maliciosas o que se resuelven en @latest que actualmente corresponde a una versión comprometida.
Inspeccione su directorio personal en busca de un archivo llamado init.json en el perfil de usuario (por ejemplo ~/init.json en Unix y ~\init.json en Windows). Su presencia sugiere que el malware basado en Solana se ejecutó al menos una vez. También audite los registros de red salientes de las estaciones de trabajo de los desarrolladores y los ejecutores de CI para conexiones a 45.32.150.251, los puntos finales RPC de Solana utilizados en las campañas, o las otras direcciones C2 citadas anteriormente (por ejemplo 136.0.9[.]8, 85.239.62[.]36, 195.133.79.43, 217.69.3.152).
Revise tu node_modules y archivos de bloqueo para dependencias reveladoras como @agnoliaarisian7180/string-argv, @usebioerhold8733/s-format y el malicioso @react-native-aria/* or @gluestack-ui/utils versiones enumeradas en los avisos. Si encuentra alguno de ellos, trate la máquina como potencialmente comprometida y rote todas las credenciales confidenciales: tokens npm, tokens de acceso de GitHub, claves SSH, claves de proveedor de nube y cualquier secreto presente en .env o archivos de configuración en el momento de la instalación.
De cara al futuro, refuerce la estructura de su cadena de suministro para el trabajo con React Native: Confirmar y aplicar siempre los archivos de bloqueo (package-lock.json, yarn.lock, pnpm-lock.yaml), habilite la autenticación de dos factores en todas las cuentas de npm con derechos de publicación y configure su CI para que falle las compilaciones cuando aparezcan nuevas dependencias sin revisión. Considere ejecutar con --ignore-scripts al instalar paquetes de terceros en contextos no confiables, e integrar herramientas de escaneo de dependencias tanto en flujos de trabajo locales como en CI.
Por último, considere los entornos de desarrollo, especialmente aquellos utilizados para aplicaciones React Native que conectan API móviles, web y de backend, como parte de su superficie de ataque de producción. Ya sea que la amenaza sea una toma de cuenta que coloca malware respaldado por Solana en un componente de entrada del teléfono, un complemento Vite con typosquatting que elimina React de node_modulesYa sea una integración maliciosa de Quill que altere el almacenamiento del lado del cliente o una vulnerabilidad de ejecución remota de código (RCE) en la CLI de la comunidad de React Native, el denominador común es que los atacantes ahora ven las herramientas para desarrolladores como una de las vías más eficientes para acceder a los activos más valiosos de su organización.
