Paquets npm maliciosos a l'ecosistema React Native

Darrera actualització: 03/26/2026
  • Diverses campanyes han abusat dels paquets i eines npm de React Native de confiança, des de components d'IU fins a utilitats CLI, mitjançant la presa de control de comptes i el typosquatting.
  • Els atacants despleguen cada cop més programari maliciós sofisticat de diverses etapes mitjançant Solana o C2 descentralitzat, dirigit a màquines de desenvolupadors, canals de CI i dades de moneders o credencials.
  • Els proveïdors de seguretat ara confien en l'anàlisi d'IA, les comprovacions de temps de reutilització i els controls de sortida de CI reforçats per detectar i contenir aquests atacs a la cadena de subministrament en qüestió de minuts.
  • Els equips de React Native han de combinar una higiene estricta de dependències, npm 2FA, fitxers de bloqueig i monitorització contínua per reduir significativament el risc de la cadena de subministrament.

paquets npm maliciosos a React Native

React Native s'ha convertit en un framework de referència per a la creació d'aplicacions mòbils, cosa que fa que el seu ecosistema npm sigui un objectiu extremadament atractiu per als atacants que busquen comprometre les màquines dels desenvolupadors i els pipelines de CI. Durant els darrers anys, diverses campanyes altament sofisticades han abusat de paquets React Native de confiança, eines populars al voltant del framework i fins i tot utilitats typosquatted per plantar programari maliciós, robar credencials, exfiltrar carteres i sabotejar projectes de JavaScript a gran escala.

Si creeu o manteniu aplicacions React Native avui dia, ja no n'hi ha prou amb "instal·lar npm i esperar que tot vagi bé". Diversos actors d'amenaces abusen sistemàticament de npm, atacant tot, des dels components de la interfície d'usuari fins a les eines de la CLI, i fins i tot el graf de dependències transitives que s'amaga a les profunditats dels fitxers de bloqueig. Aquest article repassa els principals incidents coneguts, analitza com funciona el programari maliciós i exposa passos pragmàtics que podeu prendre per reduir el radi de l'explosió al vostre propi entorn de desenvolupament.

Assalt de comptes i programari maliciós en components d'entrada de React Native

Un dels incidents més alarmants de la cadena de subministrament al món de React Native va afectar dos components d'IU molt comuns per a la selecció de telèfon i país: react-native-international-phone-number i react-native-country-select. Tots dos paquets, mantinguts pel mateix autor (@AstrOOnauta, usuari npm astroonauta), han acumulat desenes de milers de descàrregues setmanals i estan integrats en moltes aplicacions mòbils de producció.

Atac de la cadena de subministrament de NPM a components natius de React

El 16 de març de 2026, l'analista de paquets basat en IA de StepSecurity va ser el primer a detectar que les noves versions d'aquestes biblioteques havien adquirit sobtadament programari maliciós en temps d'instal·lació. Les versions immediatament compromeses van ser react-native-international-phone-number@0.11.8 i react-native-country-select@0.3.91Les últimes versions netes confirmades fins a aquell moment eren 0.11.7 i 0.3.9 respectivament.

La porta del darrere inicial (Ona 1) era brutalment simple: una nova preinstall guió i un fort ofuscat install.js fitxer inclòs al tarball. El maliciós package.json el fragment tenia aquest aspecte:

"scripts": { "preinstall": "node install.js" }

Com que els scripts del cicle de vida de npm s'executen automàticament npm install, qualsevol persona que instal·lés aquestes versions, localment o en CI, va executar el programari maliciós sense importar cap codi. No hi havia etiquetes de Git, versions o execucions de flux de treball de CI corresponents per a les versions compromeses, i gitHead coincidia amb la versió correcta anterior, un fort indicador que l'atacant havia obtingut accés de publicació directe al compte npm del mantenidor en lloc de modificar el repositori de GitHub.

Les dades de descàrrega d'aquella època subratllen com de dolent podria haver estat això: aproximadament 9,000 descàrregues setmanals per a react-native-country-select i més de 20,000 per react-native-international-phone-number, sumant més de 130,000 descàrregues al mes entre les dues. Aquest és precisament el tipus de dependència d'alt volum i baixa visibilitat que aterra silenciosament en milers de màquines de desenvolupadors i CI.

Atac en tres onades: des d'una preinstal·lació òbvia fins a cadenes de dependències furtives

onades d'atacs maliciosos de NPM a React Native

La campanya contra aquests paquets React Native es va desenvolupar en tres onades diferents, cada iteració més evasiva que l'anterior mentre reutilitzava el mateix programari maliciós principal. StepSecurity va fer un seguiment de l'evolució gairebé en temps real i es va coordinar amb el mantenidor, però l'atacant va recuperar o retenir repetidament l'accés al compte npm compromès.

L'ona 1 (16 de març de 2026) es va centrar en la directa preinstall enganxar els dos paquets. En uns cinc minuts després de la publicació, la IA de StepSecurity va marcar les noves versions com a crítiques i es van obrir incidències a GitHub: #165 per a react-native-international-phone-number i el número 11 per react-native-country-selectEl mantenidor va respondre ràpidament, desaprovant les versions malicioses i enviant una versió neta. react-native-country-select@0.4.0El temps total des de la publicació fins a la desactivació va ser d'unes 2 hores i 21 minuts, un temps ràpid per als estàndards de l'ecosistema.

Malgrat això, l'atacant mai va perdre el control de les credencials npm, cosa que va donar lloc a la segona onada el 17 de març. En lloc de tornar a incloure un script obvi als paquets principals, l'actor amenaçador va preparar dos nous paquets amb àmbit per actuar com a infraestructura oculta:

  • @usebioerhold8733/s-format@2.0.1 – un clon buit de string-format amb una postinstall: "node init.js" guió però falta el init.js fitxer, de manera que el ganxo falla silenciosament.
  • @agnoliaarisian7180/string-argv@0.3.0 – un paquet gairebé buit (README, LICENSE, package.json) l'únic propòsit real del qual era dependre de @usebioerhold8733/s-format, amb una adreça de mantenidor basada en ProtonMail.

Més tard aquell vespre, react-native-international-phone-number@0.12.1 es va publicar amb @agnoliaarisian7180/string-argv@0.3.0 afegit com una nova dependència, de nou sense cap activitat d'accions de GitHub. En aquell moment, la cadena estava preparada però inert, esperant que s'activés la càrrega útil. Quan StepSecurity va informar de l'anomalia, el mantenidor va confirmar el que ja era evident pels artefactes: "el meu compte npm va ser atacat i la biblioteca va ser presa de control".

La tercera onada (18 de març) va canviar la infraestructura per etapes a una cadena activa de distribució de programari maliciós multicapa i després la va refinar en ràpida successió. Les noves versions dels paquets de retransmissió i de la biblioteca principal es van publicar en menys d'una hora, i l'atacant va iterant sobre com es va llançar la càrrega útil.

La cadena final tenia aquest aspecte:

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)

L'atacant va activar primer la càrrega útil @usebioerhold8733/s-format@2.0.2 afegint un gran i ofuscat init.js fitxer que era byte per byte idèntic a l'anterior install.js de l'Ona 1. Aleshores van canviar el postinstall trucar child.js en lloc de init.js, publicat 2.0.3 amb el guió perdut (una altra prova), i finalment enviat 2.0.4 amb una petita child.js carregador que simplement comprova init.js i l'executa mitjançant child_process.exec mentre descarta els errors i la sortida de stderr.

Alhora, @agnoliaarisian7180/string-argv@0.3.1 va canviar la seva dependència de s-format d'una versió fixada a "latest"i react-native-international-phone-number@0.12.2 va fer el mateix amb string-argv. Això va crear una cadena maliciosa d'autoactualització on cada instal·lació del paquet principal extreia automàticament la versió més recent de la càrrega útil.

Finalment, react-native-international-phone-number@0.12.3 he eliminat el ganxo de preinstal·lació, ara innecessari (per tenir un aspecte més net), he mantingut la cadena de dependències maliciosa i he canviat el correu electrònic del mantenidor de npm a un altre compte de ProtonMail que no és propietat de l'autor original. Això era un senyal clar que l'atacant estava consolidant el control persistent sobre la identitat npm, no només reutilitzant oportunistament un token filtrat.

Dins del programari maliciós recolzat per Solana dirigit als desenvolupadors de React Native

Sota el capó, la càrrega útil que s'executava en les tres onades era el mateix programari maliciós sofisticat de diverses etapes que abusa de la cadena de blocs de Solana com a canal dinàmic de comandament i control. El mecanisme de lliurament canviava constantment, però "l'arma" es mantenia idèntica en totes les iteracions, fins i tot sent el mateix fitxer byte per byte quan es va trasplantar de la primera onada a la infraestructura de la tercera onada.

L'script comença amb un retard deliberat de 10 segons utilitzant setTimeout, un truc clàssic per evasió de sandbox. Molts espais de prova automatitzats i eines de seguretat només donen als scripts una curta finestra d'execució abans de decidir que no ha passat res sospitós, de manera que el programari maliciós simplement espera abans de fer res interessant.

A continuació, realitza un geofiltre per evitar infectar sistemes a Rússia i parts de la CEI. Inspecciona variables d'entorn com ara LANG, LANGUAGE, LC_ALL, informació de l'usuari amfitrió, el fus horari del sistema i fins i tot desplaçaments UTC en brut, buscant valors que indiquin una configuració regional russa (com ara ru_RU or Russian) o un d'una llista de fusos horaris de Rússia/CEI. Si algun d'aquests coincideix, l'script es tanca immediatament i silenciosament.

Només si l'entorn supera aquesta comprovació, el programari maliciós comença a comunicar-se amb la cadena de blocs de Solana. Conté una adreça de cartera codificada i la consulta a través de getSignaturesForAddress Mètode JSON-RPC en nou punts finals RPC de Solana diferents allotjats per diversos proveïdors. Aquest disseny proporciona a l'atacant una alta disponibilitat i fa que el bloqueig simple de dominis o IP sigui ineficaç.

El truc és que l'atacant amaga l'URL de la càrrega útil de la següent etapa dins del camp de nota de les transaccions de Solana a aquesta cartera. El memoràndum emmagatzema una massa de JSON codificat en base64, la qual link El camp conté l'URL de la següent etapa. En publicar una nova transacció, l'operador pot rotar l'URL de la càrrega útil en qualsevol moment sense modificar els paquets npm publicats.

Un cop extreta l'URL, el programari maliciós realitza una sol·licitud HTTP al servidor de l'atacant a http://45.32.150.251/, enviant el tipus de sistema operatiu en un fitxer personalitzat os capçalera perquè el C2 pugui retornar binaris específics de la plataforma. El cos de la resposta porta la càrrega útil xifrada, però la clau AES-256 i l'IV necessaris per desxifrar-la només s'envien a les capçaleres HTTP (secretkey i ivbase64), de manera que qualsevol dada corporal emmagatzemada a la memòria cau o interceptada és inútil per si sola.

La segona etapa desxifrada no toca mai el disc; s'executa a la memòria amb eval(atob(...)) en sistemes tipus Unix o mitjançant vm.Script a Windows amb accés complet a les funcions internes de Node. Després, el programari maliciós deixa anar un ~/init.json fitxer de marcadors que emmagatzema una marca de temps i un identificador únic perquè la mateixa màquina no es torni a infectar més d'una vegada cada 48 hores. Aquesta limitació de velocitat redueix dràsticament el soroll i dóna als defensors menys indicadors de comportament als quals aferrar-se.

La càrrega útil de tercera etapa desxifrada per AES, recuperada pels investigadors reproduint els mateixos passos de Solana i HTTP, és un lladre de credencials i moneders centrat en Windows, a més d'un carregador. Estableix persistència amb schtasks i la Run clau de registre, descarrega mòduls xifrats addicionals de 45.32.150.251i exfiltra el botí resultant a una IP dins del rang 217.69.3.x.

Aquesta càrrega útil busca dades de moneders d'escriptori i extensions de navegador com ara MetaMask, Phantom, Exodus, Atomic, Guarda, Coinomi, Daedalus, OKX Wallet, Trust Wallet, Braavos i més, recorrent les carpetes de perfil del navegador i els directoris locals de moneders després de tancar per força Chrome i Firefox. A més a més, extreu els tokens npm i les credencials de GitHub directament de la configuració local i dels ajudants de credencials, convertint les caixes de desenvolupador compromeses en plataformes de llançament perfectes per a futurs atacs a la cadena de subministrament.

Cal destacar que el programari maliciós fins i tot descarrega els seus propis runtimes de Node.js (v22.9.0) tant per a x86 com per a x64 a %APPDATA%\_node_x86 i %APPDATA%\_node_x64, assegurant-se que tingui un entorn d'execució consistent fins i tot quan Node no estigui instal·lat al sistema de destinació.

Enllaços a ForceMemo i l'actor d'amenaces GlassWorm

L'empremta tècnica d'aquest incident de React Native npm s'alinea gairebé perfectament amb una campanya anterior anomenada "ForceMemo", que va comprometre centenars de repositoris de Python a GitHub. Ambdues operacions van utilitzar Solana com a C2 dead-drop, el mateix grup de nou punts finals RPC, el mateix format de memò JSON amb un link camp, lògica de geofiltratge idèntica de Rússia/CEI, la mateixa ~/init.json bloqueig de persistència i fins i tot rangs d'infraestructura similars allotjats a Vultr.

Tot i que les adreces de la cartera Solana difereixen entre les dues campanyes, tot apunta a un únic actor altament capaç, que es creu que és el grup conegut com a GlassWorm. ForceMemo va atacar els desenvolupadors a través de repositoris enverinats de GitHub, mentre que l'incident de React Native ho va fer a través de paquets npm i les seves cadenes de dependències. L'estratègia és clara: reutilitzar un marc de programari maliciós sofisticat i modular, però connectar-lo a diferents canals de distribució per arribar a tants entorns de desenvolupament com sigui possible.

Altres campanyes npm malicioses al voltant de React Native i JavaScript

El compromís d'AstrOOnauta és només una peça d'una onada més àmplia d'atacs basats en npm que afecten les aplicacions React Native directament o indirectament. Diversos proveïdors de seguretat han documentat campanyes paral·leles centrades en les biblioteques d'IU de React Native, les eines principals de la CLI i fins i tot els complements de compilació genèrics dels quals depenen moltes bases de codi de React Native.

Aikido Security va descobrir una important operació de la cadena de subministrament el juny de 2025 que va desbloquejar almenys 16 paquets relacionats amb React Native sota la protecció de... @react-native-aria/* abast més @gluestack-ui/utils, que en conjunt serveixen al voltant d'un milió de descàrregues setmanals. La bretxa inicial va tenir lloc el 6 de juny de 2025, començant amb @react-native-aria/focus@0.2.10, i després es va expandir ràpidament a paquets addicionals de focus, overlay, interaction, toggle, switch, checkbox, radio, button, menu, listbox, tabs, combobox, disclosure, slider, separator i les utilitats GlueStack el 7 de juny.

El programari maliciós d'aquella campanya era un troià d'accés remot (RAT) adaptat a entorns Windows, que persistia sota %LOCALAPPDATA%\Programs\Python\Python3127 i connectant-se als servidors C2 a 136.0.9[.]8 i 85.239.62[.]36. Les seves capacitats incloïen l'execució arbitrària d'ordres, la càrrega/descàrrega de fitxers i l'accés remot a llarg termini. La persistència significava que simplement actualitzar a una versió neta de la biblioteca React Native no netejava les màquines ja infectades.

Una altra campanya de llarga durada descoberta per l'equip de recerca de amenaces de Socket va utilitzar typosquatting i mimetisme per plantar paquets destructius que tenen com a objectiu explícit frameworks populars de JavaScript com ara React, Vue, Vite i Quill. L'actor d'amenaces, utilitzant l'àlies npm xuxingfeng, va publicar una barreja de paquets legítims i maliciosos durant més de dos anys, creant una impressió superficial de ser un mantenidor de confiança.

Paquets com vite-plugin-bomb, vite-plugin-bomb-extend, vite-plugin-react-extend, vite-plugin-vue-extend i vue-plugin-bomb van ser dissenyats no per robar dades sinó per corrompre o destruir activament projectes. Van implementar atacs multifàsics desencadenats per dates específiques, eliminant fitxers crítics del marc de treball sota node_modules (Vue, React, Vite, TypeScript, Ant Design Vue, Pinia, ECharts i més), de vegades combinat amb apagades forçades del sistema cada segon utilitzant shutdown -s -t 5.

Un paquet particularment desagradable, js-hood, van manipular prototips bàsics de JavaScript com ara Array.prototype.filter, map, push, pop i múltiples String mètodes, substituint-les per funcions que semblen sintàcticament vàlides però retornen dades aleatòries. Això fa que les aplicacions continuïn executant-se però produeixin resultats corruptes i no deterministes que són extremadament difícils de depurar.

La quill-image-downloader la sèrie va anar en una altra direcció, centrant-se en el sabotatge d'emmagatzematge del costat del client. Va incloure una arquitectura de tres fitxers que, després d'una data d'activació especificada, itera sobre totes les claus de localStorage, sessionStorage i galetes, i després barreja parcialment els seus valors amb caràcters aleatoris tot preservant l'estructura. Els tokens d'autenticació, els carrets de la compra, les preferències de l'usuari i qualsevol estat del navegador es corrompen subtilment, provocant errors intermitents que molts equips atribuirien inicialment a errors d'aplicació.

Una investigació independent d'OP Innovate va descobrir un grup de deu paquets npm maliciosos que suplantaven biblioteques conegudes com TypeScript, discord.js, ethers.js, nodemon, react-router-dom i zustand. Un cop instal·lats, aquests paquets presenten una finestra CAPTCHA falsa, prenen l'empremta digital de l'amfitrió i descarreguen un gran lladre d'informació multiplataforma des d'un C2 a 195.133.79.43, de nou amb suport explícit per a Windows, macOS i Linux.

Finalment, la campanya CanisterWorm, detallada per Aikido, va demostrar fins a quin punt estan disposats a arribar els atacants a l'hora d'explotar npm com a vehicle de lliurament. Més de 135 paquets d'un compte d'editor compromès van ser armats amb scripts en temps d'instal·lació que s'executen abans de qualsevol dels passos de codi o compilació de l'aplicació. Les etapes posteriors es comporten de manera diferent segons si arriben a un quadre de desenvolupament local, una tasca de CI o un node de compilació contenidoritzat, i comuniquen amb un canister d'ordinador d'Internet descentralitzat (ICP) que funciona com un C2 furtiu, cosa que permet als operadors canviar el comportament sobre la marxa sense tornar a tocar el registre npm.

Vulnerabilitats crítiques en les eines de React Native: la CLI comunitària RCE

No tots els riscos de seguretat de React Native provenen de paquets directament maliciosos; alguns provenen de vulnerabilitats greus en eines àmpliament utilitzades. Un cas destacable és el CVE-2025-11953 a la CLI de React Native Community, un paquet que els desenvolupadors de Windows, macOS i Linux extreuen milions de vegades cada setmana.

Aquesta falla permetia l'execució remota de codi (RCE) no autenticada a través de sol·licituds POST dissenyades al servidor de desenvolupament local iniciades per la CLI. Com que molts desenvolupadors exposen els seus servidors metro/dev a la xarxa per a la depuració o les proves de dispositius mòbils, un atacant proper (o algú que pugui encaminar el trànsit a aquests ports) podria executar ordres arbitràries a la màquina del desenvolupador.

L'impacte va molt més enllà d'una estació de treball de desenvolupador: Un cop un atacant ha executat codi en una màquina de desenvolupament, pot pivotar cap a xarxes corporatives, extreure credencials, enverinar compilacions o manipular canals de CI/CD que es sincronitzen des d'aquesta màquina. És un exemple de llibre de com "només una eina de desenvolupament local" forma part de la superfície d'atac de producció quan es treballa en sistemes connectats al núvol.

La mitigació recomanada és senzilla però innegociable: actualització a React Native Community CLI 12.5.1 o superior, registres d'auditoria per a sol·licituds POST sospitoses o processos inesperats iniciats pel servidor de desenvolupament, restringir l'accés als servidors locals i integrar les eines de desenvolupament a la vostra estratègia de detecció d'amenaces. Tracteu qualsevol punt final de DevOps o de desenvolupador com un objectiu d'alt valor, perquè així és exactament com ho veuen els atacants moderns.

Com van respondre els defensors: anàlisi de la IA, temps de reutilització i integració contínua reforçada

L'avantatge d'aquestes històries és que la comunitat de seguretat s'està tornant més ràpida i sofisticada a l'hora de detectar amenaces de la cadena de subministrament contra React Native i l'espai més ampli de JavaScript. Eines com StepSecurity, Socket i Aikido Security inverteixen molt en anàlisi del comportament, diferenciació automatitzada i models d'aprenentatge automàtic que escanegen les noves versions de npm en qüestió de minuts després de la publicació.

En l'atac d'AstrOOnauta, l'analista de paquets d'IA de StepSecurity va detectar versions malicioses en menys de cinc minuts, va obrir incidències de GitHub amb detalls tècnics complets i, posteriorment, va informar dels paquets d'infraestructura de l'atacant a npm per a la seva eliminació. L'equip va documentar cada onada, va fer un seguiment dels headers de git, va analitzar el codi ofuscat, va mostrar proves d'ús de Solana C2 i va donar instruccions pas a pas per a la correcció al mantenidor.

Més enllà de la detecció, els controls preventius comencen a guanyar força en les línies de producció de cimentació. Per exemple, la comprovació de temps de recàrrega de paquets npm de StepSecurity permet a les organitzacions bloquejar dependències que es van publicar fa només unes hores, cosa que permet als escàners i als humans inspeccionar-les. La seva comprovació d'actualitzacions compromeses fa referència creuada a un flux constantment actualitzat de paquets coneguts com a dolents i falla les PR que intenten afegir-los o actualitzar-los.

Les eines compatibles amb la xarxa com ara Harden-Runner restringeixen les connexions sortints a les accions de GitHub i altres tasques de CI a una llista permesa de punts finals esperats. En un món on el programari maliciós obté càrregues útils de nodes RPC de Solana, URL de Google Calendar, rangs d'IP de Vultr o contenidors ICP, bloquejar la sortida dels sistemes de compilació pot ser la diferència entre un diferencial de paquet incorrecte i una intrusió en tota regla.

Pel que fa a la resposta, funcions com la cerca de paquets a tota l'organització i els centres d'amenaces ajuden els equips a mapejar ràpidament el radi de l'explosió. Tan bon punt s'identifica un paquet o complement de React Native compromès, els equips de seguretat poden veure quins repositoris, branques i fitxers de bloqueig l'inclouen, quines tasques l'han executat i quines màquines han comunicat amb IP sospitoses, i després prioritzar la remediació en conseqüència en desenes o centenars de bases de codi.

Accions pràctiques per a equips React Native que s'enfronten a programari maliciós npm

Tant per als desenvolupadors de React Native com per als enginyers de seguretat, defensar-se contra atacs a nivell npm consisteix a combinar la higiene en màquines individuals amb barreres de seguretat en CI/CD i gestió de dependències. Cap control per si sol us salvarà, però les defenses per capes redueixen dràsticament les probabilitats que un paquet maliciós es converteixi en un compromís complet.

Si feu servir els paquets compromesos esmentats anteriorment, hi ha algunes comprovacions immediates que cal fer. Per a l'incident d'AstrOOnauta, pin react-native-international-phone-number a la versió 0.11.7 i react-native-country-select a 0.4.0, evitant totes les versions marcades com a malicioses o que resolen @latest que actualment correspon a una versió compromesa.

Inspeccioneu el vostre directori d'inici per trobar un fitxer anomenat init.json sota el perfil d'usuari (per exemple ~/init.json a Unix i ~\init.json a Windows). La seva presència suggereix que el programari maliciós basat en Solana s'ha executat almenys una vegada. També cal auditar els registres de xarxa sortints de les estacions de treball dels desenvolupadors i els executors de CI per detectar connexions a 45.32.150.251, els punts finals RPC de Solana utilitzats a les campanyes o les altres adreces C2 esmentades anteriorment (per exemple, 136.0.9[.]8, 85.239.62[.]36, 195.133.79.43, 217.69.3.152).

Revisi el seu node_modules i fitxers de bloqueig per a dependències reveladores com ara @agnoliaarisian7180/string-argv, @usebioerhold8733/s-format i el maliciós @react-native-aria/* or @gluestack-ui/utils versions que figuren als avisos. Si en trobeu algun, tracteu la màquina com a potencialment compromesa i roteu totes les credencials sensibles: tokens npm, tokens d'accés de GitHub, claus SSH, claus de proveïdor de núvol i qualsevol secret present a .env o fitxers de configuració en el moment de la instal·lació.

De cara al futur, enduriu la vostra postura a la cadena de subministrament per al treball de React Native: sempre confirma i aplica els fitxers de bloqueig (package-lock.json, yarn.lock, pnpm-lock.yaml), activeu l'autenticació a dos factors (2FA) en tots els comptes npm amb drets de publicació i configureu el vostre CI perquè falli les compilacions quan apareguin noves dependències sense revisió. Penseu en executar-ho amb --ignore-scripts en instal·lar paquets de tercers en contextos no fiables i connectar eines d'escaneig de dependències tant als fluxos de treball locals com a la CI.

Finalment, tracteu els entorns de desenvolupament, especialment els que s'utilitzen per a aplicacions React Native que connecten les API mòbils, web i de backend, com a part de la vostra superfície d'atac de producció. Tant si l'amenaça és una usurpació de comptes que col·loca programari maliciós recolzat per Solana en un component d'entrada de telèfon, com si és un complement Vite amb typosquat que elimina React de node_modules, una integració maliciosa de Quill que altera l'emmagatzematge del costat del client o un RCE a la CLI de React Native Community, el fil conductor és que els atacants ara veuen les eines de desenvolupador com una de les vies més eficients cap a les joies de la corona de la vostra organització.

Articles Relacionats: