Schädliche npm-Pakete im React Native-Ökosystem

Startseite » Python » Schädliche npm-Pakete im React Native-Ökosystem

React Native hat sich zu einem Standardframework für die Entwicklung mobiler Apps entwickelt, was sein npm-Ökosystem zu einem äußerst attraktiven Ziel für Angreifer macht, die Entwicklerrechner und CI-Pipelines kompromittieren wollen. In den letzten Jahren wurden in mehreren hochkomplexen Kampagnen vertrauenswürdige React Native-Pakete, beliebte Tools rund um das Framework und sogar typosquatte Hilfsprogramme missbraucht, um Malware einzuschleusen, Zugangsdaten zu stehlen, Wallets zu exfiltrieren und JavaScript-Projekte in großem Umfang zu sabotieren.

Wer heute React Native-Apps entwickelt oder wartet, kann nicht mehr einfach nur „npm install“ verwenden und auf das Beste hoffen. Mehrere Angreifer missbrauchen systematisch npm und zielen dabei auf alles ab – von UI-Komponenten über CLI-Tools bis hin zum transitiven Abhängigkeitsgraphen, der tief in Ihren Sperrdateien verborgen ist. Dieser Artikel beschreibt die wichtigsten bekannten Vorfälle, analysiert die Funktionsweise der Malware und zeigt praktische Schritte auf, mit denen Sie die Auswirkungen auf Ihre Entwicklungsumgebung minimieren können.

Kontoübernahme und Malware in React Native-Eingabekomponenten

Einer der alarmierendsten Lieferkettenvorfälle in der React Native-Welt betraf zwei sehr verbreitete UI-Komponenten für die Auswahl von Telefonnummer und Land: react-native-international-phone-number , react-native-country-select. Beide Pakete werden vom selben Autor betreut (@AstrOOnauta, npm-Benutzer astroonautaSie verzeichnen wöchentlich zehntausende Downloads und sind in vielen mobilen Produktionsanwendungen integriert.

Am 16. März 2026 entdeckte StepSecurity mit seinem KI-basierten Paketanalysten als Erster, dass neue Versionen dieser Bibliotheken plötzlich Malware zur Installationszeit enthielten. Die sofort beeinträchtigten Veröffentlichungen waren react-native-international-phone-number@0.11.8 , react-native-country-select@0.3.91Die letzten zu diesem Zeitpunkt bestätigten fehlerfreien Versionen waren 0.11.7 , 0.3.9 beziehungsweise.

Die erste Hintertür (Welle 1) war brutal einfach: ein neues preinstall Skript und ein stark verschleiertes install.js Die Datei ist im Tarball enthalten. Die bösartige package.json Der Ausschnitt sah folgendermaßen aus:

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

Weil npm-Lebenszyklusskripte automatisch ausgeführt werden npm installJeder, der diese Versionen heruntergeladen hat – lokal oder in der CI – hat die Malware ausgeführt, ohne Code zu importieren. Für die kompromittierten Versionen gab es keine entsprechenden Git-Tags, Releases oder CI-Workflow-Läufe, und die gitHead entsprach der vorherigen erfolgreichen Version, ein starkes Indiz dafür, dass der Angreifer direkten Zugriff auf das npm-Konto des Maintainers erlangt hatte, anstatt das GitHub-Repository zu verändern.

Die Downloadzahlen aus dieser Zeit verdeutlichen, wie schlimm es hätte kommen können: etwa 9,000 wöchentliche Downloads für react-native-country-select und über 20,000 für react-native-international-phone-numberDas ergibt insgesamt mehr als 130,000 Downloads pro Monat zwischen den beiden. Genau diese Art von Abhängigkeit, die in großem Umfang auftritt, aber kaum sichtbar ist, schleicht sich unbemerkt auf Tausende von Entwickler- und CI-Rechnern ein.

Drei-Wellen-Angriff: von offensichtlichen Vorinstallationen bis hin zu versteckten Abhängigkeitsketten

Die Kampagne gegen diese React Native-Pakete verlief in drei deutlich voneinander abgegrenzten Wellen, wobei jede Iteration ausweichender war als die vorherige, während gleichzeitig dieselbe Kern-Malware wiederverwendet wurde. StepSecurity verfolgte die Entwicklung nahezu in Echtzeit und koordinierte sich mit dem Maintainer, doch der Angreifer erlangte oder behielt immer wieder Zugriff auf das kompromittierte npm-Konto.

Welle 1 (16. März 2026) konzentrierte sich auf die direkte preinstall Hook in beiden Paketen. Etwa fünf Minuten nach Veröffentlichung stufte die KI von StepSecurity die neuen Versionen als kritisch ein, und es wurden Probleme auf GitHub gemeldet: #165 für react-native-international-phone-number und Nr. 11 für react-native-country-selectDer Entwickler reagierte umgehend, entfernte die schädlichen Versionen und veröffentlichte eine bereinigte Version. react-native-country-select@0.4.0Die gesamte Zeitspanne von der Veröffentlichung bis zur Abschaffung betrug etwa 2 Stunden und 21 Minuten – für ein Ökosystem schnell.

Trotzdem verlor der Angreifer nie die Kontrolle über die npm-Zugangsdaten, was am 17. März zur zweiten Angriffswelle führte. Anstatt erneut ein offensichtliches Skript in die Hauptpakete einzufügen, platzierte der Angreifer zwei neue, abgegrenzte Pakete, die als versteckte Infrastruktur dienten:

• @usebioerhold8733/s-format@2.0.1 – ein hohler Klon von string-format mit einem postinstall: "node init.js" Skript, aber es fehlt das init.js Datei, daher schlägt der Hook stillschweigend fehl.
• @agnoliaarisian7180/string-argv@0.3.0 – ein nahezu leeres Paket (README, LICENSE, package.json), dessen einziger Zweck darin bestand, von etwas abhängig zu sein @usebioerhold8733/s-format, mit einer auf ProtonMail basierenden Wartungsadresse.

Später am selben Abend, react-native-international-phone-number@0.12.1 wurde veröffentlicht mit @agnoliaarisian7180/string-argv@0.3.0 wurde als neue Abhängigkeit hinzugefügt, wiederum ohne jegliche GitHub Actions-Aktivität. Zu diesem Zeitpunkt war die Kette zwar vorbereitet, aber inaktiv und wartete darauf, dass die Nutzlast aktiviert wurde. Als StepSecurity die Anomalie meldete, bestätigte der Maintainer, was bereits aus den Artefakten ersichtlich war: „Mein npm-Konto wurde angegriffen und die Bibliothek übernommen.“

In Welle 3 (18. März) wurde die vorbereitete Infrastruktur in eine aktive, mehrschichtige Malware-Verbreitungskette umgewandelt und anschließend in rascher Folge verfeinert. Neue Versionen sowohl der Relay-Pakete als auch der Hauptbibliothek wurden innerhalb von weniger als einer Stunde veröffentlicht, wobei der Angreifer die Art und Weise, wie die Payload gestartet wurde, iterativ verbesserte.

Die endgültige Kette sah folgendermaßen aus:

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)

Der Angreifer aktivierte die Nutzlast zuerst in @usebioerhold8733/s-format@2.0.2 durch Hinzufügen eines großen, verschleierten init.js Datei, die Byte für Byte mit der vorherigen identisch war install.js aus Welle 1. Dann änderten sie die postinstall anrufen child.js statt init.js, veröffentlicht 2.0.3 ohne Skript (ein weiterer Testlauf) und schließlich ausgeliefert 2.0.4 mit einem winzigen child.js Loader, der einfach prüft init.js und führt es aus über child_process.exec unter Verwerfen von Fehlern und stderr-Ausgabe.

Gleichzeitig, @agnoliaarisian7180/string-argv@0.3.1 verlagerte seine Abhängigkeit auf s-format von einer angehefteten Version zu "latest" und react-native-international-phone-number@0.12.2 tat das gleiche mit string-argv. Dadurch entstand eine sich selbst aktualisierende schädliche Kette, bei der jede Installation des Hauptpakets automatisch die neueste Payload-Version herunterlud.

Schließlich haben react-native-international-phone-number@0.12.3 Der nun überflüssige Preinstall-Hook wurde entfernt (um die Darstellung übersichtlicher zu gestalten), die schädliche Abhängigkeitskette wurde beibehalten und die E-Mail-Adresse des npm-Maintainers wurde auf ein weiteres ProtonMail-Konto geändert, das nicht dem ursprünglichen Autor gehört. Das war ein klares Zeichen dafür, dass der Angreifer die dauerhafte Kontrolle über die npm-Identität festigte und nicht nur opportunistisch ein durchgesickertes Token wiederverwendete.

Im Inneren der von Solana unterstützten Malware, die es auf React Native-Entwickler abgesehen hat

Im Inneren handelte es sich bei der in allen drei Wellen laufenden Nutzlast um dieselbe ausgeklügelte, mehrstufige Malware, die die Solana-Blockchain als dynamischen Kommando- und Kontrollkanal missbraucht. Der Übermittlungsmechanismus änderte sich ständig, aber die „Waffe“ blieb über alle Iterationen hinweg identisch, bis hin zur Tatsache, dass es sich Byte für Byte um dieselbe Datei handelte, wenn sie von Wave 1 in die Wave 3-Infrastruktur übertragen wurde.

Das Skript beginnt mit einer bewussten Verzögerung von 10 Sekunden. setTimeout, ein klassischer Sandbox-Vermeidungstrick. Viele automatisierte Sandboxes und Sicherheitstools geben Skripten nur ein kurzes Ausführungsfenster, bevor sie feststellen, dass nichts Verdächtiges passiert ist. Daher wartet die Malware einfach ab, bevor sie etwas Interessantes tut.

Anschließend wird ein Geofilter durchgeführt, um eine Infektion von Systemen in Russland und Teilen der GUS zu vermeiden. Es untersucht Umgebungsvariablen wie LANG, LANGUAGE, LC_ALLInformationen zum Hostbenutzer, die Systemzeitzone und sogar rohe UTC-Offsets werden gesucht, um Werte zu finden, die auf ein russisches Gebietsschema hinweisen (wie z. B. ru_RU or Russianoder eine der aufgeführten russischen/GUS-Zeitzonen. Trifft eine dieser Zeiten zu, beendet sich das Skript sofort und ohne Fehlermeldung.

Nur wenn die Umgebung diese Prüfung besteht, beginnt die Malware mit der Solana-Blockchain zu kommunizieren. Es enthält eine fest codierte Wallet-Adresse und fragt diese über die getSignaturesForAddress Die JSON-RPC-Methode wird über neun verschiedene Solana-RPC-Endpunkte genutzt, die von unterschiedlichen Anbietern gehostet werden. Dieses Design bietet Angreifern hohe Verfügbarkeit und macht einfache Domain- oder IP-Sperrungen wirkungslos.

Der Trick besteht darin, dass der Angreifer die URL der nächsten Payload-Stufe im Memo-Feld von Solana-Transaktionen an diese Wallet versteckt. Das Memo speichert einen Blob von Base64-kodiertem JSON, dessen link Das Feld enthält die URL der nächsten Stufe. Durch das Erstellen einer neuen Transaktion kann der Betreiber die Payload-URL jederzeit ändern, ohne die veröffentlichten npm-Pakete zu modifizieren.

Sobald die URL extrahiert wurde, sendet die Malware eine HTTP-Anfrage an den Server des Angreifers unter http://45.32.150.251/, wobei der Betriebssystemtyp in einem benutzerdefinierten Format gesendet wird os Header, damit der C2-Server plattformspezifische Binärdateien zurückgeben kann. Der Antworttext enthält die verschlüsselte Nutzlast, aber der zum Entschlüsseln benötigte AES-256-Schlüssel und Initialisierungsvektor werden nur in den HTTP-Headern gesendet (secretkey , ivbase64Daher sind alle zwischengespeicherten oder abgefangenen Körperdaten für sich genommen nutzlos.

Die entschlüsselte zweite Stufe berührt niemals die Festplatte; sie wird im Arbeitsspeicher ausgeführt. eval(atob(...)) auf Unix-ähnlichen Systemen oder über vm.Script unter Windows mit vollem Zugriff auf die internen Abläufe von Node.js. Anschließend hinterlässt die Schadsoftware eine ~/init.json Eine Markerdatei speichert einen Zeitstempel und eine eindeutige Kennung, um zu verhindern, dass ein Rechner mehr als einmal alle 48 Stunden erneut infiziert wird. Diese Ratenbegrenzung reduziert Störungen drastisch und bietet den Angreifern weniger Anhaltspunkte für Verhaltensindikatoren.

Die von Forschern durch Wiederholung der gleichen Solana- und HTTP-Schritte wiederhergestellte, AES-entschlüsselte Nutzlast der dritten Stufe ist ein Windows-zentrierter Credential- und Wallet-Stealer mit Loader. Es etabliert Beständigkeit mit schtasks und der Run Registrierungsschlüssel, lädt zusätzliche verschlüsselte Module herunter von 45.32.150.251und leitet die so gewonnene Beute an eine IP-Adresse im Bereich 217.69.3.x weiter.

Diese Payload spürt Daten von Desktop-Wallets und Browsererweiterungen wie MetaMask, Phantom, Exodus, Atomic, Guarda, Coinomi, Daedalus, OKX Wallet, Trust Wallet, Braavos und anderen auf, indem sie nach dem erzwungenen Schließen von Chrome und Firefox Browserprofilordner und lokale Wallet-Verzeichnisse durchsucht. Darüber hinaus werden npm-Token und GitHub-Zugangsdaten direkt aus lokalen Konfigurations- und Anmeldeinformationshilfsfunktionen extrahiert, wodurch kompromittierte Entwicklerrechner zu perfekten Ausgangspunkten für weitere Lieferkettenangriffe werden.

Bemerkenswerterweise lädt die Malware sogar ihre eigenen Node.js-Laufzeitumgebungen (v22.9.0) sowohl für x86 als auch für x64 herunter. %APPDATA%\_node_x86 , %APPDATA%\_node_x64, Dadurch wird sichergestellt, dass eine konsistente Ausführungsumgebung vorhanden ist, auch wenn Node auf dem Zielsystem nicht installiert ist.

Links zu ForceMemo und dem GlassWorm-Bedrohungsakteur

Die technischen Merkmale dieses React Native npm-Vorfalls stimmen nahezu perfekt mit einer früheren Kampagne namens „ForceMemo“ überein, bei der Hunderte von Python-Repositories auf GitHub kompromittiert wurden. Beide Operationen nutzten Solana als Dead-Drop-C2-Server, dieselbe Gruppe von neun RPC-Endpunkten, dasselbe JSON-Memo-Format mit einem link Feld, identische Geofilterlogik für Russland/GUS, dasselbe ~/init.json Persistenzsperre und sogar ähnliche Infrastrukturbereiche, die auf Vultr gehostet werden.

Obwohl sich die Solana-Wallet-Adressen in den beiden Kampagnen unterscheiden, deutet alles andere auf einen einzigen, äußerst fähigen Akteur hin, bei dem es sich vermutlich um die Gruppe GlassWorm handelt. ForceMemo zielte über manipulierte GitHub-Repositories auf Entwickler ab, während der React-Native-Vorfall über npm-Pakete und deren Abhängigkeitsketten erfolgte. Die Strategie ist klar: Ein ausgeklügeltes, modulares Malware-Framework wird wiederverwendet und über verschiedene Vertriebskanäle so verbreitet, dass möglichst viele Entwicklungsumgebungen erreicht werden.

Weitere bösartige npm-Kampagnen im Zusammenhang mit React Native und JavaScript

Der AstroOnauta-Kompromittierungsfall ist nur ein Teil einer umfassenderen Welle von npm-basierten Angriffen, die React Native-Apps direkt oder indirekt betreffen. Mehrere Sicherheitsanbieter haben parallele Kampagnen dokumentiert, die sich auf React Native UI-Bibliotheken, zentrale CLI-Tools und sogar generische Build-Plugins konzentrieren, von denen viele React Native-Codebasen abhängen.

Aikido Security deckte im Juni 2025 eine groß angelegte Lieferkettenoperation auf, die mindestens 16 React Native-bezogene Pakete mit Hintertüren versehen hatte. @react-native-aria/* Zielfernrohr plus @gluestack-ui/utilsDie App verzeichnet insgesamt rund eine Million Downloads pro Woche. Der erste Sicherheitsverstoß ereignete sich am 6. Juni 2025 und begann mit @react-native-aria/focus@0.2.10und wurde dann am 7. Juni schnell auf weitere Fokus-, Overlay-, Interaktions-, Umschalter-, Checkbox-, Radio-, Button-, Menü-, Listbox-, Tab-, Combobox-, Disclosure-, Slider- und Separator-Pakete sowie die GlueStack-Dienstprogramme ausgeweitet.

Bei der Malware dieser Kampagne handelte es sich um einen Remote-Access-Trojaner (RAT), der speziell für Windows-Umgebungen entwickelt wurde und unter anderem %LOCALAPPDATA%\Programs\Python\Python3127 und die Verbindung zu C2-Servern bei 136.0.9[.]8 , 85.239.62[.]36. Zu seinen Funktionen gehörten die Ausführung beliebiger Befehle, das Hoch- und Herunterladen von Dateien sowie der langfristige Fernzugriff. Aufgrund seiner Persistenz reichte ein einfaches Upgrade auf eine saubere Version der React Native-Bibliothek nicht aus, um bereits infizierte Rechner zu säubern.

Eine weitere, seit längerer Zeit laufende Kampagne, die vom Threat Research Team von Socket aufgedeckt wurde, nutzte Typosquatting und Mimikry, um zerstörerische Pakete zu platzieren, die gezielt beliebte JavaScript-Frameworks wie React, Vue, Vite und Quill ins Visier nahmen. Der Bedrohungsakteur verwendet den npm-Alias xuxingfeng, veröffentlichte über zwei Jahre hinweg eine Mischung aus legitimen und schädlichen Paketen und erweckte so den oberflächlichen Eindruck, ein vertrauenswürdiger Maintainer zu sein.

Pakete wie vite-plugin-bomb, vite-plugin-bomb-extend, vite-plugin-react-extend, vite-plugin-vue-extend , vue-plugin-bomb Sie wurden nicht entwickelt, um Daten zu stehlen, sondern um Projekte aktiv zu korrumpieren oder zu zerstören. Sie führten mehrphasige Angriffe durch, die durch bestimmte Daten ausgelöst wurden, und löschten dabei kritische Framework-Dateien. node_modules (Vue, React, Vite, TypeScript, Ant Design Vue, Pinia, ECharts und mehr), manchmal in Verbindung mit erzwungenen Systemabschaltungen im Sekundentakt. shutdown -s -t 5.

Ein besonders übles Paket js-hood, manipulierten Kern-JavaScript-Prototypen wie Array.prototype.filter, map, push, pop und mehrere String MethodenSie werden durch Funktionen ersetzt, die zwar syntaktisch korrekt aussehen, aber zufällige Daten zurückgeben. Dies führt zu Anwendungen, die zwar weiterhin laufen, aber fehlerhafte, nicht-deterministische Ergebnisse liefern, die extrem schwer zu debuggen sind.

Das quill-image-downloader Die Serie schlug eine andere Richtung ein und konzentrierte sich auf Sabotageakte auf Clientseite. Es wurde eine Drei-Dateien-Architektur ausgeliefert, die nach einem festgelegten Aktivierungsdatum alle Schlüssel durchläuft. localStorage, sessionStorage Cookies werden dabei teilweise mit zufälligen Zeichen verschlüsselt, wobei die Struktur erhalten bleibt. Authentifizierungstoken, Warenkörbe, Benutzereinstellungen und der Browserstatus werden dadurch subtil beschädigt, was zu sporadischen Fehlern führt, die viele Teams zunächst Anwendungsfehlern zuschreiben würden.

Unabhängige Recherchen von OP Innovate deckten eine Gruppe von zehn bösartigen npm-Paketen auf, die bekannte Bibliotheken wie TypeScript, discord.js, ethers.js und nodemon imitierten. react-router-dom , zustand. Nach der Installation zeigen diese Pakete ein gefälschtes CAPTCHA-Fenster an, ermitteln den Host-Fingerabdruck und laden einen großen plattformübergreifenden Datendiebstahl von einem C2-Server herunter. 195.133.79.43wiederum mit expliziter Unterstützung für Windows, macOS und Linux.

Schließlich zeigte die von Aikido detailliert beschriebene CanisterWorm-Kampagne, wie weit Angreifer bereit sind zu gehen, um npm als Verbreitungsmedium auszunutzen. Über 135 Pakete eines kompromittierten Publisher-Kontos wurden mit Installationsskripten präpariert, die vor dem eigentlichen Anwendungscode oder Build-Schritten ausgeführt werden. Die nachfolgenden Phasen verhalten sich unterschiedlich, je nachdem, ob sie auf einem lokalen Entwicklungsrechner, einem CI-Prozess oder einem containerisierten Build-Knoten landen. Sie kommunizieren mit einem dezentralen Internet-Computer (ICP), der als getarnter C2-Server fungiert. Dadurch können die Angreifer das Verhalten dynamisch ändern, ohne jemals wieder auf die npm-Registry zugreifen zu müssen.

Kritische Sicherheitslücken in den React Native-Tools: die Community CLI RCE

Nicht alle Sicherheitsrisiken von React Native gehen von direkt bösartigen Paketen aus; einige resultieren aus schwerwiegenden Schwachstellen in weit verbreiteten Tools. Ein bemerkenswertes Beispiel ist CVE‑2025‑11953 in der React Native Community CLI, einem Paket, das wöchentlich millionenfach von Entwicklern unter Windows, macOS und Linux heruntergeladen wird.

Dieser Fehler ermöglichte die Ausführung von nicht authentifiziertem Remote-Code (RCE) durch speziell präparierte POST-Anfragen an den lokalen Entwicklungsserver, der über die Befehlszeile gestartet wurde. Da viele Entwickler ihre Metro-/Entwicklungsserver im Netzwerk zum Debuggen oder Testen auf Mobilgeräten freigeben, könnte ein Angreifer in der Nähe (oder jemand, der den Datenverkehr zu diesen Ports umleiten kann) beliebige Befehle auf dem Rechner des Entwicklers ausführen.

Die Auswirkungen reichen weit über einen einzelnen Entwicklerarbeitsplatz hinaus: Sobald ein Angreifer Code auf einem Entwicklungsrechner ausführen kann, kann er in Unternehmensnetzwerke eindringen, Zugangsdaten abgreifen, Builds manipulieren oder CI/CD-Pipelines, die von diesem Rechner synchronisiert werden, manipulieren. Dies ist ein Paradebeispiel dafür, wie selbst ein „lokales Entwicklungstool“ Teil der Angriffsfläche in der Produktionsumgebung werden kann, wenn man mit Cloud-Systemen arbeitet.

Die empfohlene Abhilfemaßnahme ist einfach, aber unabdingbar: Aktualisierung auf React Native Community CLI 12.5.1 oder höher, Überwachung der Protokolle auf verdächtige POST-Anfragen oder unerwartete Prozesse, die vom Entwicklungsserver gestartet werden, Einschränkung des Zugriffs auf lokale Server und Einbeziehung der Entwicklungswerkzeuge in Ihre Bedrohungserkennungsstrategie. Behandeln Sie jeden DevOps- oder Entwickler-Endpunkt als ein wertvolles Ziel, denn genau so sehen es moderne Angreifer.

Die Reaktion der Verteidiger: KI-Analyse, Abklingzeiten und verstärkte CI-Systeme.

Der positive Aspekt dieser Geschichten ist, dass die Sicherheitsgemeinschaft immer schneller und ausgefeilter darin wird, Bedrohungen der Lieferkette für React Native und den gesamten JavaScript-Bereich aufzudecken. Tools wie StepSecurity, Socket und Aikido Security investieren stark in Verhaltensanalyse, automatisierten Vergleich und Modelle des maschinellen Lernens, die neue npm-Releases innerhalb weniger Minuten nach der Veröffentlichung scannen.

Beim AstrOOnauta-Angriff erkannte der KI-Paketanalyst von StepSecurity bösartige Versionen in weniger als fünf Minuten, erstellte GitHub-Issues mit vollständigen technischen Analysen und meldete später die betroffenen Infrastrukturpakete des Angreifers an npm zur Entfernung. Das Team dokumentierte jede Welle, verfolgte die Git-Versionen, analysierte verschleierten Code, erbrachte Beweise für die Nutzung von Solana C2 und gab dem Maintainer eine schrittweise Anleitung zur Behebung des Problems.

Über die Erkennung hinaus gewinnen präventive Kontrollmechanismen in CI-Pipelines zunehmend an Bedeutung. StepSecuritys npm Package Cooldown Check ermöglicht es Unternehmen beispielsweise, Abhängigkeiten zu blockieren, die erst vor wenigen Stunden veröffentlicht wurden. Dadurch gewinnen Scanner und Mitarbeiter Zeit, diese zu überprüfen. Die Überprüfung auf kompromittierte Updates gleicht diese mit einer ständig aktualisierten Liste bekanntermaßen schädlicher Pakete ab und lehnt Pull Requests ab, die versuchen, diese hinzuzufügen oder zu aktualisieren.

Netzwerkfähige Tools wie Harden-Runner beschränken ausgehende Verbindungen in GitHub Actions und anderen CI-Jobs auf eine Zulassungsliste erwarteter Endpunkte. In einer Welt, in der Malware Nutzdaten von Solana-RPC-Knoten, Google-Kalender-URLs, Vultr-IP-Bereichen oder ICP-Kanistern abruft, kann die Absicherung des ausgehenden Datenverkehrs aus Ihren Build-Systemen den Unterschied zwischen einem fehlerhaften Paketvergleich und einem ausgewachsenen Einbruch ausmachen.

Auf der Reaktionsseite helfen Funktionen wie die organisationsweite Paketsuche und Bedrohungszentren den Teams dabei, den Explosionsradius schnell zu erfassen. Sobald ein kompromittiertes React Native-Paket oder -Plugin identifiziert ist, können Sicherheitsteams sehen, welche Repositories, Branches und Lockfiles es enthalten, welche Jobs es ausgeführt haben und welche Maschinen mit verdächtigen IPs kommuniziert haben – und dann die Behebung entsprechend in Dutzenden oder Hunderten von Codebasen priorisieren.

Praktische Maßnahmen für React Native-Teams, die mit npm-Malware konfrontiert sind

Für React Native-Entwickler und Sicherheitsingenieure gleichermaßen geht es bei der Abwehr von Angriffen auf npm-Ebene darum, Hygiene auf einzelnen Rechnern mit Schutzmechanismen in CI/CD und Abhängigkeitsmanagement zu kombinieren. Keine einzelne Kontrollmaßnahme wird Sie retten, aber ein mehrschichtiges Verteidigungssystem verringert die Wahrscheinlichkeit, dass ein Schadprogramm zu einer vollständigen Kompromittierung führt, dramatisch.

Falls Sie die zuvor erwähnten kompromittierten Pakete verwenden, müssen Sie umgehend einige Überprüfungen durchführen. Zum AstroOnauta-Vorfall, Pin react-native-international-phone-number zur Version 0.11.7 , react-native-country-select zu 0.4.0, wobei alle als schädlich gekennzeichneten Versionen vermieden werden oder die Auflösung zu @latest Dies entspricht aktuell einer kompromittierten Version.

Überprüfen Sie Ihr Home-Verzeichnis auf eine Datei mit dem Namen init.json unter dem Benutzerprofil (zum Beispiel ~/init.json auf Unix und ~\init.json unter Windows). Seine Präsenz deutet darauf hin, dass die Solana-basierte Malware mindestens einmal ausgeführt wurde. Überprüfen Sie außerdem die ausgehenden Netzwerkprotokolle von Entwickler-Workstations und CI-Runnern auf Verbindungen zu 45.32.150.251, die in den Kampagnen verwendeten Solana-RPC-Endpunkte oder die anderen zuvor genannten C2-Adressen (z. B. 136.0.9[.]8, 85.239.62[.]36, 195.133.79.43, 217.69.3.152).

Überprüfen Sie Ihre node_modules und Sperrdateien für verräterische Abhängigkeiten wie @agnoliaarisian7180/string-argv, @usebioerhold8733/s-format und das Bösartige @react-native-aria/* or @gluestack-ui/utils In den Sicherheitshinweisen aufgeführte Versionen. Wenn Sie einen dieser Einträge finden, behandeln Sie den Rechner als potenziell kompromittiert und ändern Sie alle sensiblen Zugangsdaten: npm-Tokens, GitHub-Zugriffstokens, SSH-Schlüssel, Cloud-Anbieterschlüssel und alle darin enthaltenen Geheimnisse. .env oder Konfigurationsdateien zum Installationszeitpunkt.

Mit Blick auf die Zukunft sollten Sie Ihre Lieferkettenstrategie für React Native-Projekte optimieren: Sperrdateien immer festschreiben und erzwingen (package-lock.json, yarn.lock, pnpm-lock.yamlAktivieren Sie die Zwei-Faktor-Authentifizierung für alle npm-Konten mit Veröffentlichungsrechten und konfigurieren Sie Ihre CI so, dass Builds fehlschlagen, wenn neue Abhängigkeiten ohne Überprüfung hinzugefügt werden. Erwägen Sie die Ausführung mit --ignore-scripts bei der Installation von Drittanbieterpaketen in nicht vertrauenswürdigen Kontexten und beim Einbinden von Abhängigkeits-Scanning-Tools sowohl in lokale Workflows als auch in CI.

Schließlich sollten Sie Entwicklungsumgebungen – insbesondere solche, die für React Native-Apps verwendet werden, welche mobile, Web- und Backend-APIs verbinden – als Teil Ihrer Angriffsfläche in der Produktionsumgebung betrachten. Ob es sich bei der Bedrohung um eine Kontoübernahme handelt, bei der Solana-basierte Malware in eine Eingabekomponente eines Telefons eingeschleust wird, oder um ein durch Typosquatting manipuliertes Vite-Plugin, das React löscht node_modulesOb es sich nun um eine bösartige Quill-Integration handelt, die den clientseitigen Speicher verschlüsselt, oder um eine Remote Code Execution (RCE) in der React Native Community CLI – der gemeinsame Nenner ist, dass Angreifer Entwicklerwerkzeuge mittlerweile als einen der effizientesten Wege zu den Kronjuwelen Ihres Unternehmens betrachten.