- Flere kampanjer har misbrukt pålitelige React Native npm-pakker og -verktøy, fra UI-komponenter til CLI-verktøy, via kontoovertakelse og typosquatting.
- Angripere distribuerer i økende grad sofistikert flertrinns skadelig programvare ved hjelp av Solana eller desentralisert C2, og retter seg mot utviklermaskiner, CI-pipelines og lommebok- eller legitimasjonsdata.
- Sikkerhetsleverandører er nå avhengige av AI-analyse, nedkjølingskontroller og forsterkede CI-utgangskontroller for å fange opp og begrense disse forsyningskjedeangrepene på få minutter.
- React Native-team må kombinere streng avhengighetshygiene, npm 2FA, låsefiler og kontinuerlig overvåking for å redusere risikoen i forsyningskjeden betydelig.
React Native har blitt et go-to-rammeverk for å bygge mobilapper, noe som gjør npm-økosystemet til et ekstremt attraktivt mål for angripere som ønsker å kompromittere utviklermaskiner og CI-pipelines. I løpet av de siste årene har flere svært sofistikerte kampanjer misbrukt pålitelige React Native-pakker, populære verktøy rundt rammeverket og til og med typosquattet verktøy for å plante skadelig programvare, stjele legitimasjon, tømme lommebøker og sabotere JavaScript-prosjekter i stor skala.
Hvis du bygger eller vedlikeholder React Native-apper i dag, er det ikke lenger nok å bare «installere npm og håpe på det beste». Flere trusselaktører misbruker systematisk npm, og retter seg mot alt fra UI-komponenter til CLI-verktøy, og til og med den transitive avhengighetsgrafen som gjemmer seg dypt inne i låsefilene dine. Denne artikkelen går gjennom de viktigste kjente hendelsene, dissekerer hvordan skadevaren fungerer, og legger frem pragmatiske tiltak du kan ta for å redusere eksplosjonsradiusen i ditt eget utviklingsmiljø.
Kontoovertakelse og skadelig programvare i React Native-inputkomponenter
En av de mest alarmerende hendelsene i forsyningskjeden i React Native-verdenen traff to svært vanlige UI-komponenter for valg av telefon og land: react-native-international-phone-number og react-native-country-select. Begge pakkene, vedlikeholdt av samme forfatter (@AstrOOnauta, npm-bruker astroonauta), har samlet titusenvis av ukentlige nedlastinger og er innebygd i mange produksjonsmobilapper.
16. mars 2026 var StepSecuritys AI-baserte pakkeanalytiker den første som oppdaget at nye versjoner av disse bibliotekene plutselig hadde fått skadelig programvare under installasjon. De umiddelbart kompromitterte utgivelsene var react-native-international-phone-number@0.11.8 og react-native-country-select@0.3.91De siste bekreftede rene versjonene på det tidspunktet var 0.11.7 og 0.3.9 henholdsvis.
Den første bakdøren (bølge 1) var brutalt enkel: en ny preinstall manus og et sterkt tilslørt install.js filen samlet i tarballen. Det ondsinnede package.json utdraget så slik ut:
"scripts": { "preinstall": "node install.js" }
Fordi npm-livssyklusskript kjører automatisk på npm installkjørte alle som hentet disse versjonene – lokalt eller i CI – skadevaren uten å importere noen kode. Det fantes ingen tilsvarende Git-tagger, utgivelser eller CI-arbeidsflytkjøringer for de kompromitterte versjonene, og gitHead samsvarte med den forrige fungerende utgivelsen, en sterk indikator på at angriperen hadde fått direkte publiseringstilgang til vedlikeholderens npm-konto i stedet for å endre GitHub-repoet.
Nedlastingsdata rundt den tiden understreker hvor ille dette kunne ha vært: omtrent 9,000 ukentlige nedlastinger for react-native-country-select og over 20 000 for react-native-international-phone-number, noe som gir opptil mer enn 130 000 nedlastinger per måned mellom de to. Dette er nettopp den typen avhengighet med stort volum og lav synlighet som stille lander på tusenvis av utvikler- og CI-maskiner.
Trebølgeangrep: fra åpenbar forhåndsinstallasjon til skjulte avhengighetskjeder
Kampanjen mot disse React Native-pakkene utspilte seg i tre distinkte bølger, hver iterasjon mer unnvikende enn den forrige, mens den samme kjerne-skadevaren ble gjenbrukt. StepSecurity sporet utviklingen i nær sanntid og koordinerte med vedlikeholderen, men angriperen fikk gjentatte ganger tilbake eller beholdt tilgangen til den kompromitterte npm-kontoen.
Bølge 1 (16. mars 2026) sentrert rundt den direkte preinstall krok i begge pakkene. Innen omtrent fem minutter etter publiseringen flagget StepSecuritys AI de nye utgivelsene som kritiske, og problemer ble åpnet på GitHub: #165 for react-native-international-phone-number og #11 for react-native-country-selectVedlikeholderen reagerte raskt, avskaffet de skadelige versjonene og presset inn en ren versjon. react-native-country-select@0.4.0Total tid fra publisering til avvikling var rundt 2 timer og 21 minutter – raskt etter økosystemstandarder.
Til tross for dette mistet angriperen aldri kontrollen over npm-legitimasjonene, noe som førte til bølge 2 den 17. mars. I stedet for å legge et åpenbart skript inn i hovedpakkene igjen, iscenesatte trusselaktøren to nye pakker med omfang som skulle fungere som skjult infrastruktur:
@usebioerhold8733/s-format@2.0.1– en hul klon avstring-formatmedpostinstall: "node init.js"manus, men manglerinit.jsfilen, slik at kroken feiler stille.@agnoliaarisian7180/string-argv@0.3.0– en nesten tom pakke (README, LICENSE, package.json) hvis eneste virkelige formål var å være avhengig av@usebioerhold8733/s-format, med en ProtonMail-basert vedlikeholderadresse.
Senere den kvelden, react-native-international-phone-number@0.12.1 ble publisert med @agnoliaarisian7180/string-argv@0.3.0 lagt til som en ny avhengighet, igjen uten noen GitHub Actions-aktivitet. På det tidspunktet var kjeden i iscenesatt tilstand, men inert, og ventet på at nyttelasten skulle slås på. Da StepSecurity rapporterte avviket, bekreftet vedlikeholderen det som allerede var åpenbart ut fra artefaktene: «npm-kontoen min ble angrepet og biblioteket ble overtatt».
Bølge 3 (18. mars) endret den trinnvise infrastrukturen til en aktiv flerlags leveringskjede for skadelig programvare, og forbedret den deretter i rask rekkefølge. Nye versjoner av både relépakkene og hovedbiblioteket ble publisert i løpet av under en time, og angriperen gjentok hvordan nyttelasten ble lansert.
Den endelige kjeden så slik ut:
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)
Angriperen slo først på nyttelasten i @usebioerhold8733/s-format@2.0.2 ved å legge til en stor, tilslørt init.js fil som var byte-for-byte identisk med den forrige install.js fra bølge 1. De endret deretter postinstall å ringe child.js istedenfor init.js, publisert 2.0.3 med manuset manglet (nok en prøvekjøring), og endelig sendt 2.0.4 med en liten child.js laster som bare sjekker etter init.js og utfører den via child_process.exec mens feil og stderr-utdata forkastes.
Samtidig, @agnoliaarisian7180/string-argv@0.3.1 byttet avhengighet på s-format fra en festet versjon til "latest"og react-native-international-phone-number@0.12.2 gjorde det samme med string-argv. Dette skapte en selvoppdaterende ondsinnet kjede der hver installasjon av hovedpakken automatisk hentet den nyeste nyttelastversjonen.
Endelig, react-native-international-phone-number@0.12.3 fjernet den nå unødvendige forhåndsinstallasjonskroken (for å se renere ut), beholdt den ondsinnede avhengighetskjeden og endret npm-vedlikeholderens e-postadresse til enda en ProtonMail-konto som ikke eies av den opprinnelige forfatteren. Det var et tydelig tegn på at angriperen konsoliderte vedvarende kontroll over npm-identiteten, ikke bare opportunistisk gjenbrukte en lekket token.
Inne i Solana-støttet skadevare som retter seg mot React Native-utviklere
Under panseret var nyttelasten som kjørte i alle tre bølgene den samme sofistikerte flertrinns skadelige programvaren som misbruker Solana-blokkjeden som en dynamisk kommando- og kontrollkanal. Leveringsmekanismen endret seg stadig, men «våpenet» forble identisk på tvers av alle iterasjoner, helt ned til å være den samme filen byte for byte da den ble transplantert fra bølge 1 til bølge 3-infrastrukturen.
Skriptet starter med en bevisst 10 sekunders forsinkelse ved hjelp av setTimeout, et klassisk triks for å unngå sandkassen. Mange automatiserte sandkasser og sikkerhetsverktøy gir skript bare et kort utførelsesvindu før de bestemmer seg for at ingenting mistenkelig har skjedd, så skadevaren venter bare på at de skal gjøre noe interessant.
Deretter utfører den et geofilter for å unngå å infisere systemer i Russland og deler av SNG. Den inspiserer miljøvariabler som LANG, LANGUAGE, LC_ALL, vertsbrukerinformasjon, systemets tidssone og til og med rå UTC-forskyvninger, og ser etter verdier som indikerer en russisk lokalitet (for eksempel ru_RU or Russian) eller en av en liste over russiske/SNG-tidssoner. Hvis noen av disse samsvarer, avsluttes skriptet umiddelbart og stille.
Først hvis miljøet består den sjekken, begynner skadevaren å kommunisere med Solana-blokkjeden. Den har en hardkodet lommebokadresse og spør den via getSignaturesForAddress JSON-RPC-metode på tvers av ni forskjellige Solana RPC-endepunkter som driftes av ulike leverandører. Denne designen gir angriperen høy tilgjengelighet og gjør enkel domene- eller IP-blokkering ineffektiv.
Trikset er at angriperen skjuler URL-en for neste trinns nyttelast i memofeltet for Solana-transaksjoner til den lommeboken. Notatet lagrer en blob med base64-kodet JSON hvis link Feltet inneholder URL-en til neste trinn. Ved å legge ut en ny transaksjon kan operatøren rotere nyttelast-URL-en når som helst uten å endre de publiserte npm-pakkene.
Når URL-en er hentet ut, utfører skadevaren en HTTP-forespørsel til angriperens server på http://45.32.150.251/, sender OS-typen i en tilpasset os header slik at C2 kan returnere plattformspesifikke binærfiler. Svarsteksten inneholder den krypterte nyttelasten, men AES-256-nøkkelen og IV-en som trengs for å dekryptere den sendes bare i HTTP-overskrifter (secretkey og ivbase64), så alle mellomlagrede eller avlyttede kroppsdata er ubrukelige i seg selv.
Det dekrypterte andre trinnet berører aldri disken; det utføres i minnet med eval(atob(...)) på Unix-lignende systemer eller via vm.Script på Windows med full tilgang til Node-internals. Etterpå slipper skadevaren en ~/init.json markørfil som lagrer et tidsstempel og en unik identifikator, slik at den samme maskinen ikke blir infisert på nytt mer enn én gang hver 48. time. Denne hastighetsbegrensningen reduserer støy dramatisk og gir forsvarerne færre atferdsindikatorer å holde seg til.
Den AES-dekrypterte nyttelasten i tredje trinn, som forskere har gjenopprettet ved å spille av de samme Solana- og HTTP-trinnene på nytt, er en Windows-sentrisk legitimasjons- og lommeboktyver pluss laster. Det etablerer utholdenhet med schtasks og Run registernøkkel, laster ned ekstra krypterte moduler fra 45.32.150.251, og eksfiltrerer det resulterende byttet til en IP i området 217.69.3.x.
Denne nyttelasten jakter på data fra skrivebordslommebøker og nettleserutvidelser som MetaMask, Phantom, Exodus, Atomic, Guarda, Coinomi, Daedalus, OKX Wallet, Trust Wallet, Braavos og flere, og går gjennom nettleserprofilmapper og lokale lommebokkataloger etter å ha tvangslukket Chrome og Firefox. I tillegg til dette henter den npm-tokens og GitHub-legitimasjon direkte fra lokale konfigurasjons- og legitimasjonshjelpere, og gjør dermed kompromitterte utviklerbokser til perfekte oppskytningsplattformer for ytterligere angrep i forsyningskjeden.
Det er verdt å merke seg at skadevaren til og med laster ned sine egne Node.js-kjøretider (v22.9.0) for både x86 og x64 til %APPDATA%\_node_x86 og %APPDATA%\_node_x64, sørger for at den har et konsistent utførelsesmiljø selv når Node ikke er installert på målsystemet.
Lenker til ForceMemo og trusselaktøren GlassWorm
Det tekniske fingeravtrykket til denne React Native npm-hendelsen stemmer nesten perfekt overens med en tidligere kampanje kalt «ForceMemo», som kompromitterte hundrevis av Python-repositorier på GitHub. Begge operasjonene brukte Solana som en dead-drop C2, den samme gruppen med ni RPC-endepunkter, det samme JSON-memoformatet med en link felt, identisk geofiltreringslogikk for Russland/SNG, den samme ~/init.json persistenslås og til og med lignende infrastrukturområder som ligger på Vultr.
Selv om Solana-lommebokadressene er forskjellige mellom de to kampanjene, peker alt annet mot én svært dyktig aktør, antatt å være gruppen kjent som GlassWorm. ForceMemo angrep utviklere gjennom forgiftede GitHub-repoer, mens React Native-hendelsen gjorde det gjennom npm-pakker og deres avhengighetskjeder. Strategien er klar: gjenbruk et sofistikert, modulært rammeverk for skadelig programvare, men koble det til forskjellige distribusjonskanaler for å nå så mange utviklingsmiljøer som mulig.
Andre ondsinnede npm-kampanjer rundt React Native og JavaScript
AstrOOnauta-kompromisset er bare én del av en bredere bølge av npm-baserte angrep som påvirker React Native-apper direkte eller indirekte. Flere sikkerhetsleverandører har dokumentert parallelle kampanjer som fokuserer på React Native UI-biblioteker, kjerneverktøy for CLI og til og med generiske byggepluginer som mange React Native-kodebaser er avhengige av.
Aikido Security avdekket en større forsyningskjedeoperasjon i juni 2025 som bakdøret minst 16 React Native-relaterte pakker under @react-native-aria/* omfang pluss @gluestack-ui/utils, som til sammen leverer rundt én million ukentlige nedlastinger. Det første bruddet skjedde 6. juni 2025, og startet med @react-native-aria/focus@0.2.10, deretter raskt utvidet til ytterligere fokus, overlegg, interaksjon, veksle, bryter, avkrysningsboks, radio, knapp, meny, listeboks, faner, kombinasjonsboks, avsløring, glidebryter, separatorpakker og GlueStack-verktøyene 7. juni.
Skadevaren i den kampanjen var en trojaner for fjerntilgang (RAT) skreddersydd for Windows-miljøer, som vedvarte under %LOCALAPPDATA%\Programs\Python\Python3127 og kobler seg til C2-servere på 136.0.9[.]8 og 85.239.62[.]36. Funksjonene inkluderte vilkårlig kommandokjøring, filopplasting/nedlasting og langvarig fjerntilgang. Persistens betydde at det å bare oppgradere til en ren versjon av React Native-biblioteket ikke ryddet opp i allerede infiserte maskiner.
En annen langvarig kampanje avslørt av Sockets trusselforskningsteam brukte typosquatting og mimicry for å plante destruktive pakker som eksplisitt retter seg mot populære JavaScript-rammeverk som React, Vue, Vite og Quill. Trusselaktøren, ved bruk av npm-aliaset xuxingfeng, publiserte en blanding av legitime og ondsinnede pakker over mer enn to år, noe som skapte et overfladisk inntrykk av å være en pålitelig vedlikeholder.
Pakker som vite-plugin-bomb, vite-plugin-bomb-extend, vite-plugin-react-extend, vite-plugin-vue-extend og vue-plugin-bomb ble ikke designet for å stjele data, men for aktivt å korrumpere eller ødelegge prosjekter. De implementerte flerfaseangrep utløst av bestemte datoer, og slettet kritiske rammeverksfiler under node_modules (Vue, React, Vite, TypeScript, Ant Design Vue, Pinia, ECharts og mer), noen ganger kombinert med tvungen systemavstengning hvert sekund ved hjelp av shutdown -s -t 5.
En spesielt ekkel pakke, js-hood, tuklet med kjerne-JavaScript-prototyper som Array.prototype.filter, map, push, pop og flere String metoder, og erstatter dem med funksjoner som ser syntaktisk gyldige ut, men returnerer tilfeldige data. Dette resulterer i applikasjoner som fortsetter å kjøre, men som produserer korrupte, ikke-deterministiske resultater som er ekstremt vanskelige å feilsøke.
Ocuco quill-image-downloader Serien gikk i en annen retning, med fokus på sabotasje av lagring på klientsiden. Den leverte en arkitektur med tre filer som, etter en spesifisert aktiveringsdato, itererer over alle nøkler i localStorage, sessionStorage og informasjonskapsler, og deretter delvis forvrenger verdiene deres med tilfeldige tegn samtidig som strukturen bevares. Autentiseringstokener, handlekurver, brukerpreferanser og enhver tilstand på nettlesersiden blir subtilt ødelagt, noe som forårsaker periodiske feil som mange team i utgangspunktet ville tilskrive applikasjonsfeil.
Separat forskning fra OP Innovate avdekket en klynge av ti ondsinnede npm-pakker som etterlignet kjente biblioteker som TypeScript, discord.js, ethers.js, nodemon react-router-dom og zustand. Når disse pakkene er installert, presenterer de et falskt CAPTCHA-vindu, tar fingeravtrykk av verten og laster ned en stor plattformuavhengig informasjonstyver fra en C2 på 195.133.79.43, igjen med eksplisitt støtte for Windows, macOS og Linux.
Til slutt demonstrerte CanisterWorm-kampanjen, detaljert beskrevet av Aikido, hvor langt angripere er villige til å gå i å utnytte npm som et leveringsmiddel. Over 135 pakker fra en kompromittert utgiverkonto ble bevæpnet med installasjonsskript som kjøres før noen av programkodene eller byggetrinnene dine. Senere stadier oppfører seg forskjellig avhengig av om de lander på en lokal utviklerboks, en CI-jobb eller en containerisert byggenode, og de kommuniserer med en desentralisert Internett-datamaskin (ICP)-beholder som fungerer som en skjult C2 – slik at operatører kan endre atferd på sparket uten å berøre npm-registeret igjen.
Kritiske sårbarheter i React Native-verktøy: Community CLI RCE
Ikke alle React Native-sikkerhetsrisikoer kommer fra direkte skadelige pakker; noen stammer fra alvorlige sårbarheter i mye brukte verktøy. Et bemerkelsesverdig tilfelle er CVE-2025-11953 i React Native Community CLI, en pakke som hentes millioner av ganger hver uke av utviklere på Windows, macOS og Linux.
Denne feilen tillot uautentisert ekstern kodekjøring (RCE) via håndlagde POST-forespørsler til den lokale utviklingsserveren startet av CLI. Fordi mange utviklere eksponerer sine metro-/utviklerservere på nettverket for feilsøking eller testing av mobile enheter, kan en angriper i nærheten (eller noen som kan rute trafikk til disse portene) kjøre vilkårlige kommandoer på utviklerens maskin.
Effekten går langt utover én utviklerarbeidsstasjon: Når en angriper har kjørt kode på en utviklerboks, kan de konvertere seg inn i bedriftsnettverk, skrape legitimasjonsinformasjon, forgifte bygg eller manipulere CI/CD-pipelines som synkroniseres fra den maskinen. Det er et skoleeksempel på hvordan «bare et lokalt utviklerverktøy» er en del av produksjonsangrepsflaten din når du jobber på skytilkoblede systemer.
Den anbefalte tiltaksløsningen er enkel, men ikke til å forhandle om: oppdater til React Native Community CLI 12.5.1 eller høyere, revisjonslogger for mistenkelige POST-forespørsler eller uventede prosesser startet av utviklerserveren, begrens tilgang til lokale servere og integrer utviklerverktøy i trusseldeteksjonsstrategien din. Behandle ethvert DevOps- eller utviklersluttpunkt som et verdifullt mål, for det er akkurat slik moderne angripere ser det.
Hvordan forsvarerne reagerte: AI-analyse, nedkjølingstider og herdet CI
Det positive med disse historiene er at sikkerhetsmiljøet blir raskere og mer sofistikerte når det gjelder å fange opp trusler i forsyningskjeden mot React Native og det bredere JavaScript-området. Verktøy som StepSecurity, Socket og Aikido Security investerer tungt i atferdsanalyse, automatisert diffing og maskinlæringsmodeller som skanner nye npm-utgivelser i løpet av minutter etter publisering.
I AstrOOnauta-angrepet oppdaget StepSecuritys AI-pakkeanalytiker skadelige versjoner på under fem minutter, åpnet GitHub-problemer med fullstendige tekniske havarier og rapporterte senere angriperens infrastrukturpakker til npm for fjerning. Teamet dokumenterte hver bølge, sporet git-heads, analyserte obfuskert kode, viste bevis på bruk av Solana C2 og ga vedlikeholderen trinnvis veiledning for utbedring.
Utover deteksjon begynner forebyggende kontroller å få fotfeste i CI-rørledninger. For eksempel lar StepSecuritys npm Package Cooldown Check organisasjoner blokkere avhengigheter som ble publisert for bare timer siden, noe som gir skannere og mennesker tid til å inspisere dem. Deres kontroll av kompromitterte oppdateringer kryssrefererer til en kontinuerlig oppdatert feed av kjente skadede pakker og feiler PR-er som prøver å legge til eller oppgradere til dem.
Nettverksbevisste verktøy som Harden-Runner begrenser utgående tilkoblinger i GitHub-handlinger og andre CI-jobber til en tillatelsesliste over forventede endepunkter. I en verden der skadelig programvare henter nyttelast fra Solana RPC-noder, Google Kalender-URL-er, Vultr IP-områder eller ICP-beholdere, kan det å låse utgående tilkoblinger fra byggesystemene dine være forskjellen mellom en dårlig pakkediff og et fullverdig inntrenging.
På responssiden hjelper funksjoner som organisasjonsomfattende pakkesøk og trusselsentre team med å raskt kartlegge eksplosjonsradiusen. Så snart en kompromittert React Native-pakke eller plugin identifiseres, kan sikkerhetsteam se hvilke repositorier, grener og låsefiler som inkluderer den, hvilke jobber som utførte den og hvilke maskiner som kommuniserte med mistenkelige IP-adresser – og deretter prioritere utbedring deretter på tvers av dusinvis eller hundrevis av kodebaser.
Praktiske tiltak for React Native-team som står overfor npm-skadevare
For både React Native-utviklere og sikkerhetsingeniører handler det å forsvare seg mot angrep på npm-nivå om å kombinere hygiene på individuelle maskiner med beskyttelse i CI/CD og avhengighetshåndtering. Ingen enkeltstående kontroll vil redde deg, men lagdelte forsvar reduserer dramatisk sjansen for at en ondsinnet pakke blir til et fullstendig kompromittert program.
Hvis du bruker de kompromitterte pakkene som er nevnt tidligere, er det noen umiddelbare kontroller du må utføre. For AstrOOnauta-hendelsen, pin react-native-international-phone-number til versjon 0.11.7 og react-native-country-select til 0.4.0, unngå alle versjoner som er flagget som skadelige eller løser å @latest som for øyeblikket er knyttet til en kompromittert utgivelse.
Sjekk hjemmekatalogen din for en fil med navnet init.json under brukerprofilen (for eksempel ~/init.json på Unix og ~\init.json på Windows). Tilstedeværelsen antyder at den Solana-baserte skadevaren har blitt kjørt minst én gang. Overvåk også utgående nettverkslogger fra utviklerarbeidsstasjoner og CI-kjørere for tilkoblinger til 45.32.150.251, Solana RPC-endepunktene som ble brukt i kampanjene, eller de andre C2-adressene som er nevnt tidligere (f.eks. 136.0.9[.]8, 85.239.62[.]36, 195.133.79.43, 217.69.3.152).
Sjekk din node_modules og låsefiler for avslørende avhengigheter som @agnoliaarisian7180/string-argv, @usebioerhold8733/s-format og det ondsinnede @react-native-aria/* or @gluestack-ui/utils versjoner oppført i veiledninger. Hvis du finner noen av dem, behandle maskinen som potensielt kompromittert og roter all sensitiv legitimasjon: npm-tokener, GitHub-tilgangstokener, SSH-nøkler, skyleverandørnøkler og eventuelle hemmeligheter som finnes i .env eller konfigurasjonsfiler under installasjon.
Stram opp forsyningskjeden for React Native-arbeid fremover: alltid begi og håndheve låsefiler (package-lock.json, yarn.lock, pnpm-lock.yaml), aktiver 2FA på alle npm-kontoer med publiseringsrettigheter, og konfigurer CI-en din til å feile bygg når nye avhengigheter dukker opp uten gjennomgang. Vurder å kjøre med --ignore-scripts når du installerer tredjepartspakker i uklarerte kontekster, og kobler verktøy for avhengighetsskanning til både lokale arbeidsflyter og CI.
Til slutt, behandle utviklingsmiljøer – spesielt de som brukes for React Native-apper som bygger bro mellom mobil-, nett- og backend-API-er – som en del av angrepsflaten i produksjonen. Om trusselen er en kontoovertakelse som slipper Solana-støttet skadelig programvare inn i en telefoninndatakomponent, en typosquatted Vite-plugin som sletter React fra node_modules, en ondsinnet Quill-integrasjon som forvrenger klientlagring, eller en RCE i React Native Community CLI, er den felles tråden at angripere nå ser utviklerverktøy som en av de mest effektive veiene inn i organisasjonens kronjuveler.
