![\"\"](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/03-Blog-inner-main-img-863X300.png\")
<\/p>\n<\/p>\n
Update vom 9.\u00a0Februar\u00a02026<\/strong>\u00a0\u2013 Unterschied bei den Auswirkungen vor Version 17.0.0 und ab Version 17.0.0 wurde klargestellt<\/p>\n Das JFrog Security Research Team hat vor Kurzem CVE-2025-11953 entdeckt und offengelegt\u00a0\u2013 eine kritische (CVSS 9.8<\/a>) Sicherheitsl\u00fccke, die das \u00e4u\u00dferst beliebte NPM-Paket @react-native-community\/cli<\/a> betrifft, das ungef\u00e4hr 2\u00a0Mio. w\u00f6chentliche Downloads hat.<\/p>\n Die Schwachstelle erm\u00f6glicht es nicht authentifizierten Angreifern aus der Ferne, die Ausf\u00fchrung beliebiger Betriebssystembefehle auf dem Rechner einfach auszul\u00f6sen, auf dem der Entwicklungsserver von react-native-community\/cli ausgef\u00fchrt wird, was f\u00fcr Entwickler ein erhebliches Risiko darstellt.<\/p>\n React Native ist ein beliebtes Framework f\u00fcr die Entwicklung plattform\u00fcbergreifender mobiler Apps mit JavaScript. Die Schwachstelle befindet sich in einem Paket, das Teil des umfassenderen Projekts React Native Community CLI<\/a> ist, das vor einigen Jahren aus der zentralen React-Native-Codebasis ausgegliedert wurde, um die Wartbarkeit zu verbessern. Die CLI ist eine Sammlung von Befehlszeilentools, die Entwickler bei der Erstellung von React-Native-Mobilanwendungen unterst\u00fctzen. Sie wird offiziell zum Erstellen von React-Native-Mobil-Apps ohne Verwendung eines Frameworks<\/a> sowie von React Native f\u00fcr Windows<\/a>, React Native f\u00fcr macOS und mehr verwendet.<\/p>\n Im Gegensatz zu typischen Schwachstellen in Entwicklungsservern, die nur vom lokalen Rechner eines Entwicklers aus ausnutzbar sind, setzt eine zweite Sicherheitsl\u00fccke<\/strong>, die das Team in der Kerncodebasis von React Native entdeckt hat, den Entwicklungsserver externen Netzwerkangriffen aus<\/strong>\u00a0\u2013 wodurch die erstgenannte Schwachstelle zu einem \u00e4u\u00dferst kritischen Problem wird.<\/p>\n Wir m\u00f6chten dem Sicherheitsteam und den Ingenieuren von Meta f\u00fcr die umgehende Bearbeitung der Schwachstelle CVE-2025-11953<\/a> danken.<\/p>\n Entwickler, die ihr React Native-Projekt mit einer anf\u00e4lligen Version von @react-native-community\/cli initiiert haben und den Metro-Entwicklungsserver ausf\u00fchren<\/strong>, indem sie einen der folgenden oder \u00e4hnliche Befehle verwenden, sind f\u00fcr CVE-2025-11953 anf\u00e4llig:<\/p>\n \u00a0der Entwicklungsserver (Metro) von react-native l\u00e4uft<\/span><\/i><\/p>\n W\u00e4hrend die Schwachstelle standardm\u00e4\u00dfig angreifbar ist, wenn ein React-Native-Projekt mit @react-native-community\/cli initiiert wird, ist es wichtig zu verstehen, dass nicht jeder Entwickler, der diese Bibliothek als Abh\u00e4ngigkeit installiert hat, zwangsl\u00e4ufig angreifbar ist.<\/p>\n Insbesondere sind Entwickler, die React Native mit einem Framework verwenden, das Metro nicht als Entwicklungsserver nutzt, in der Regel nicht gef\u00e4hrdet.<\/p>\n Die Schwachstelle betrifft direkt das Paket @react-native-community\/cli-server-api in den Versionen 4.8.0 bis 20.0.0-alpha.2, und ist seit Version 20.0.0 behoben.<\/p>\n In den Versionen 4.8.0 bis 17.0.0 kann die Schwachstelle nicht authentifizierten Remote-Angreifern erm\u00f6glichen, ausf\u00fchrbare Dateien auszuf\u00fchren, die sich bereits auf einem Remote-Rechner befinden (ohne dass Argumente angegeben werden m\u00fcssen).Dies ist f\u00fcr Angreifer von Nutzen, die auf andere Weise manipulierte ausf\u00fchrbare Dateien auf den Remote-Rechner hochladen k\u00f6nnen.In den Versionen 17.0.0 bis 20.0.0-alpha.2 wird die Schwachstelle noch kritischer<\/strong> und kann zu einer vollst\u00e4ndigen nicht authentifizierten Remote-Ausf\u00fchrung von Betriebssystembefehlen f\u00fchren, deren Details wir hier vorstellen werden.<\/p>\n So pr\u00fcfen Sie, ob das anf\u00e4llige Paket in einem bestimmten NodeJS-Projekt vorhanden ist:<\/p>\n Das Paket kann auch systemweit auf Ihrem System installiert sein. Dies k\u00f6nnen Sie \u00fcberpr\u00fcfen, indem Sie Folgendes ausf\u00fchren:<\/p>\n Beachten Sie, dass das betroffene Paket \u00fcblicherweise zusammen mit @react-native-community\/cli in passenden Versionen geb\u00fcndelt wird. Daher sind Projekte, die @react-native-community\/cli in den Versionen 4.8.0 bis 20.0.0\u2011alpha.2 verwenden, wahrscheinlich von anf\u00e4lligen Versionen von @react-native-community\/cli-server-api betroffen.<\/p>\n Unter Windows haben wir nachgewiesen, dass diese Schwachstelle zur Ausf\u00fchrung beliebiger Betriebssystembefehle (Shell-Befehle mit vollst\u00e4ndiger Parameterkontrolle) f\u00fchrt. Unter macOS und Linux f\u00fchrt die Schwachstelle zur Ausf\u00fchrung beliebiger ausf\u00fchrbarer Dateien mit eingeschr\u00e4nkter Parameterkontrolle. Die Ausf\u00fchrung beliebiger Betriebssystembefehle auf diesen Plattformen k\u00f6nnte mit weiteren Untersuchungen m\u00f6glich sein.<\/p>\n Durch die Durchf\u00fchrung der folgenden Schritte l\u00e4sst sich die Sicherheitsl\u00fccke CVE-2025-11953 beheben:<\/p>\n Der Metro-Entwicklungsserver, der von @react-native-community\/cli gestartet wird, stellt standardm\u00e4\u00dfig eine Verbindung zu externen Schnittstellen her (was an sich schon ein kleines Sicherheitsrisiko darstellt).Der Endpunkt Dadurch kann ein nicht authentifizierter Netzwerkangreifer eine POST-Anfrage an den Server senden und beliebige Shell-Befehle mit vom Angreifer kontrollierten Parametern ausf\u00fchren.<\/p>\n Bei der Erstellung eines React-Native-Projekts k\u00f6nnen Entwickler w\u00e4hlen, ob sie ein bestehendes Framework verwenden<\/span><\/a>, wie etwa Expo, das die CLI des Frameworks verwendet und nicht anf\u00e4llig ist, oder ihre App ohne Framework erstellen<\/span><\/a>\u00a0\u2013 wie wir es hier tun werden\u00a0\u2013, wenn sie lieber ihr eigenes Framework schreiben m\u00f6chten oder bestimmte Einschr\u00e4nkungen haben, mit denen ein bestimmtes Framework kollidiert.<\/p>\n Der Entwicklungsprozess beginnt in der Regel mit der Verwendung der @react-native-community\/cli, um mit dem Befehl Beim Ausf\u00fchren von node-modules\/react-native\/react-native.config.js<\/strong>\u00a0\u2013 f\u00fcgt Die Datei react-native.config.js importiert startCommand<\/b><\/a> aus @react-native\/community-cli-plugin\u00a0\u2013 diese Funktion ist f\u00fcr das Ausf\u00fchren des Entwicklungsservers zust\u00e4ndig.<\/p>\n Snippet aus der Datei index.js<\/span><\/a> des Startbefehls<\/em><\/p>\n Wenn der start<\/strong>-Befehl ausgef\u00fchrt wird, ruft er runServer.js<\/span><\/a> auf:<\/p>\n Vereinfachte Version von runServer.js<\/span><\/a><\/em><\/p>\n runServer.js<\/span> f\u00fchrt Folgendes aus:<\/p>\n Sehen wir uns nun den openURLMiddleware<\/strong> -Handler an, der im Rahmen von communityMiddleware<\/strong> zum Server hinzugef\u00fcgt wurde:<\/p>\n Vereinfachtes Snippet der openURLMiddleware-Funktion aus openURLMiddleware.ts<\/span><\/i><\/a><\/em><\/p>\n Diese Funktion wird mit einem HTTP-Anfrageparameter req<\/strong> aufgerufen, bei dem es sich um eine JSON-POST-Anfrage mit einem Zeichenfolgenfeld url<\/strong> handelt. Sie nimmt den Wert des Felds url<\/strong>, bei dem es sich um eine nicht bereinigte Zeichenfolge handelt, die direkt vom Benutzer stammt<\/strong>, und verwendet ihn als Parameter f\u00fcr den Aufruf W\u00e4hrend der Befehl Im Fall von Dies f\u00fchrt zur Ausf\u00fchrung von calc.exe.<\/p>\n Um einen beliebigen Befehl auszuf\u00fchren, k\u00f6nnten wir den Parameter React Native CVE\u00a0\u2013 image5 Im Gegensatz zu Windows nutzt der Befehl open, wie oben gezeigt, unterschiedliche Codepfade auf macOS und Linux und f\u00fchrt dabei jeweils Dar\u00fcber hinaus werden beide Befehle ohne Shell ausgef\u00fchrt. In Kombination mit der Tatsache, dass wir nur eine einzige Zeichenfolge (url) kontrollieren, lassen diese Faktoren es nicht ohne Weiteres zu, beliebige Befehle auf macOS und Linux auszuf\u00fchren.<\/p>\n Sowohl xdg-open als auch open bestimmen, ob die Eingabezeichenfolge eine Datei oder ein URI ist, und handeln (verteilen) entsprechend.<\/p>\n Die Angriffsfl\u00e4che zur Erzielung von Codeausf\u00fchrung in diesen Betriebssystemen kann von der Konfiguration des Systems abh\u00e4ngen und umfasst typischerweise:<\/p>\n Zusammenfassend l\u00e4sst sich sagen, dass die Ausf\u00fchrung beliebiger Betriebssystembefehle auf diesen Plattformen mit weiteren Untersuchungen m\u00f6glich sein k\u00f6nnte.<\/p>\n Wie wir bereits gezeigt haben, wird beim Ausf\u00fchren des Metro-Entwicklungsservers ausdr\u00fccklich angegeben, dass er \u00fcber die localhost-Schnittstelle gestartet wird:<\/p>\n In der Realit\u00e4t sehen wir jedoch, dass der Server auf allen Schnittstellen lauscht! (0.0.0.0 und IPv6 [::]):<\/p>\n Wie bereits erw\u00e4hnt, liegt dies an einer weiteren Schwachstelle, die wir in @react-native\/community-cli-plugin<\/a> entdeckt und offengelegt haben und die als \u201eInformative\u201c eingestuft wurde.<\/p>\n Durch Ausf\u00fchren von npx react-native start<\/strong> gelangt der Code zur Funktion runServer.js::runServer<\/a> :<\/p>\n Relevante Teile der runServer<\/a> -Funktion aus runServer.js<\/em><\/p>\n Wir gehen davon aus, dass der Startbefehl mit den Standardwerten und ohne optionale Parameter aufgerufen wird. Gehen wir die einzelnen Schritte im obigen Codebeispiel durch:<\/span><\/p>\n Sp\u00e4ter verwendet der Code von Metro f\u00fcr runServer<\/a> diesen undefinierten Parameter beim Aufruf von Aus der Dokumentation von node zu server.listen von http<\/a> geht hervor, dass sich diese Funktion wie server.listen<\/a> von net.Server verh\u00e4lt, wo es hei\u00dft:<\/p>\n \u201eWenn host weggelassen wird, akzeptiert der Server Verbindungen auf der nicht angegebenen IPv6-Adresse (::), wenn IPv6 verf\u00fcgbar ist, oder andernfalls auf der nicht angegebenen IPv4-Adresse (0.0.0.0). In den meisten Betriebssystemen kann das Lauschen auf der nicht angegebenen IPv6-Adresse (::) dazu f\u00fchren, dass net.Server auch auf der nicht angegebenen IPv4-Adresse (0.0.0.0) lauscht.\u201c<\/p>\n Die explizite \u00dcbergabe von undefined<\/strong> ist funktional gleichbedeutend mit dem Weglassen des Parameters. Daher lauscht der Server standardm\u00e4\u00dfig auf externe Verbindungen.<\/strong><\/p>\n Infolgedessen sind die HTTP-Endpunkte, die nur f\u00fcr die Entwicklung bestimmt sind, f\u00fcr Netzwerkangreifer<\/strong> zug\u00e4nglich.<\/p>\n Diese Sicherheitsl\u00fccke zeigt, dass selbst unkomplizierte Schwachstellen zur Remotecodeausf\u00fchrung, etwa die \u00dcbergabe von Benutzereingaben an die System-Shell, in realer Software weiterhin vorkommen, insbesondere wenn sich die gef\u00e4hrliche Sink-Funktion tats\u00e4chlich in Drittanbietercode befindet\u00a0\u2013 in diesem Fall die importierte Funktion \u201eopen\u201c. Sie erinnert daran, dass Verfahren f\u00fcr sicheres Coding und automatisiertes Sicherheitsscanning unerl\u00e4sslich sind, um diese leicht ausnutzbaren Schwachstellen zu verhindern, bevor sie in die Produktionsumgebung gelangen.<\/p>\n Eine gute M\u00f6glichkeit, diese und \u00e4hnliche Sicherheitsl\u00fccken im eigenen Code zu vermeiden, besteht im Einsatz des SAST-Scannings von JFrog Advanced Security<\/a>, das Entwicklern erm\u00f6glicht, Sicherheitsprobleme fr\u00fch im Entwicklungsprozess zu erkennen und zu beheben. Ohne erforderliche Konfiguration integriert sich JFrog SAST<\/a> nahtlos \u00fcber IDE-Plug-ins und CLI-Tools in bestehende Workflows und erm\u00f6glicht Entwicklern einfachen Zugriff auf umsetzbare Erkenntnisse, ohne ihren Arbeitsfluss zu unterbrechen.<\/p>\n So sehen wir beispielsweise im folgenden Screenshot, wie JFrog SAST die oben genannte Sicherheitsl\u00fccke beim Scannen als Erstanbietercode direkt in Visual Studio Code erkennt:<\/p>\nWer ist von CVE-2025-11953 betroffen?<\/h2>\n
npm start\r\n npm run [start|android|ios|windows|macos]\r\n npx react-native [start|run-android|run-ios|run-windows|run-macos]\r\n npx @react-native-community\/cli [start|run-android|run-ios|run-windows|run-macos]\r\n<\/code><\/pre>\n![\"\"](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/React-Native-CVE-image1.png\")
<\/p>\n cd \r\n npm list @react-native-community\/cli-server-api\r\n<\/code><\/pre>\n npm list -g @react-native-community\/cli-server-api\r\n<\/code><\/pre>\nWie kann CVE-2025-11953 behoben werden?<\/h2>\n
\n
npx react-native start --host 127.0.0.1\r\n npx @react-native-community\/cli start --host 127.0.0.1\r\n<\/code><\/pre>\nZusammenfassung von CVE-2025-11953<\/h2>\n
\/open-url<\/code> des Servers verarbeitet eine POST-Anfrage, die einen vom Benutzer eingegebenen Wert enth\u00e4lt, der an die unsichere Funktion open()<\/code>\u00a0\u00fcbergeben wird, die vom Open-NPM-Paket bereitgestellt wird und zur Ausf\u00fchrung von Betriebssystembefehlen f\u00fchrt.<\/p>\n![\"<code](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/React-Native-CVE-image3.png\")
\" width=\"400\" height=\"364\" \/>calc.exe wird als Ergebnis unseres Exploits ausgef\u00fchrt<\/em><\/code><\/p>\nCVE-2025-11953: Technische Details<\/h2>\n
npx @react-native-community\/cli init MyApp<\/code> ein neues Projekt zu initialisieren, wodurch die erforderliche Projektstruktur, Abh\u00e4ngigkeiten und Konfigurationsdateien eingerichtet werden. W\u00e4hrend der aktiven Entwicklung verlassen sich Entwickler auf die CLI, um den Metro-Entwicklungsserver auszuf\u00fchren (mit Befehlen wie npx react-native start<\/code>), der das JavaScript-Bundle an die laufende App (auf einem Emulator oder Mobilger\u00e4t) bereitstellt und wesentliche Entwicklungsfunktionen wie Hot Reloading und Fast Refresh f\u00fcr schnelle Iterationen erm\u00f6glicht.<\/p>\nnpx react-native start<\/code> leitet die cli.js von react-native den Befehl an das Paket @react-native-community\/cli weiter (eine optionale Abh\u00e4ngigkeit von react-native), das seine Funktion build\\index.js::setupAndRun()<\/code> ausf\u00fchrt. Diese Funktion l\u00e4dt die CLI-Befehle (d.\u00a0h. start-Befehl<\/code>), indem sie loadConfigAsync<\/code> aufruft, wodurch w\u00e4hrend des Vorgangs die Datei node-modules\/react-native\/react-native.config.js<\/code> gefunden und verwendet wird.<\/p>\n const commands = [];\r\n const {\r\n bundleCommand,\r\n startCommand,\r\n } = require('@react-native\/community-cli-plugin');\r\n commands.push(bundleCommand, startCommand);\r\n<\/code><\/pre>\nstartCommand<\/code> zu einer exportierten Befehlsliste hinzu, die dann zur CLI-Befehlsliste hinzugef\u00fcgt wird.<\/em><\/p>\n import runServer from '.\/runServer';\r\n \/* ... *\/\r\n const startCommand: Command = {\r\n name: 'start',\r\n func: runServer,\r\n description: 'Start the React Native development server.',\r\n<\/code><\/pre>\n \/* ... *\/\r\n\r\n import {createDevServerMiddleware} from '.\/middleware'; \/* *** 1 *** *\/\r\n\r\n \/* ... *\/\r\n\r\n \/* *** 2 *** *\/\r\n const { middleware: communityMiddleware<\/strong> } = createDevServerMiddleware({\r\n host: hostname,\r\n port,\r\n watchFolders,\r\n });\r\n\r\n \/* ... *\/\r\n\r\n \/* *** 3 *** *\/\r\n await Metro.runServer<\/strong>(metroConfig, {\r\n host: args.host,\r\n secure: args.https,\r\n secureCert: args.cert,\r\n secureKey: args.key,\r\n unstable_extraMiddleware: [communityMiddleware<\/strong>, middleware],\r\n websocketEndpoints: {\r\n ...communityWebsocketEndpoints,\r\n ...websocketEndpoints,\r\n },\r\n });\r\n<\/code><\/pre>\n\n
async function openURLMiddleware(req: IncomingMessage, ...) {\r\n if (req.method === 'POST') {\r\n\r\n \/* ... *\/\r\n\r\n const {url} = req.body as {url: string};\r\n\r\n await open(url);\r\n\r\n \/* ... *\/\r\n\r\n }\r\n next();\r\n }\r\n export default connect().use(json()).use(openURLMiddleware);\r\n<\/code><\/pre>\nopen()<\/code>.<\/p>\n\n
open()<\/code> wird aus dem npm-Paket \u201aopen\u2018<\/span><\/a> in Version 6.4.0 importiert.<\/li>\nopen(url)<\/code> f\u00fchrt auf Windows-Rechnern Folgendes aus:\n\n
Befehl<\/code> auf \u201ecmd\u201c<\/li>\ncliArguments<\/code>: ['\/c', 'start', '\"\"', '\/b']<\/code><\/li>\nZiel-String<\/code>, der die von uns angegebene URL ist.<\/li>\ntarget<\/code> zu den cliArguments<\/code> hinzu<\/li>\n
\nchildProcess.spawn(command, cliArguments, childProcessOptions);<\/code><\/code><\/li>\n<\/ol>\n<\/li>\n<\/ol>\nstart<\/code> aufgrund seines HTTP-URI-Schemas einen einzigen URL-Parameter akzeptieren und diesen im Standardbrowser \u00f6ffnen kann, akzeptiert er auch das folgende Format zum Ausf\u00fchren von Befehlen:
\nstart \u201ctitle\u201d \/b command optional_command_parameters<\/code><\/p>\nopen(\u201ccalc.exe\u201d)<\/code> wird der folgende neue Prozess gestartet:<\/p>\n cmd \/c start \u201c\u201d \/b calc.exe\r\n<\/code><\/pre>\nurl<\/code> von open auf einen cmd \/c <\/code> -Befehl setzen. Zum Beispiel mit dem folgenden Ergebnis:<\/p>\n cmd \/c start \"\" \/b cmd \/c echo abc > c:\\temp\\pwned.txt\r\n<\/code><\/pre>\n![\"React](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/React-Native-CVE-image5.png\")
\nEine neue Datei pwned.txt, die als Ergebnis unseres Befehls cmd.exe \/c in C:\\temp erstellt wurde\u00a0\u2013 was beweist, dass die Ausf\u00fchrung eines beliebigen Codes erfolgreich war.<\/em><\/p>\nAngriffsfl\u00e4chen auf verschiedenen Betriebssystemen<\/h3>\n
open <\/code> und xdg-open <\/code> aus. Bei unix\u00e4hnlichen Betriebssystemen erwartet der erzeugte Prozess, dass jedes Argument eine separate Zeichenfolge in cliArguments<\/code> ist, was sich von Windows unterscheidet, wo der erzeugte Prozess eine einzelne Argumentzeichenfolge lpCommandLine<\/code> erwartet, die zusammengef\u00fcgt wird<\/a>, bevor der Aufruf von CreateProcess<\/code> erfolgt.<\/p>\n\n
\n
\n
Sollte der Entwicklungsserver nicht nur an \u201elocalhost\u201c gebunden sein?<\/h3>\n
![\"React](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/React-Native-CVE-image4.png\")
<\/pre>\n![\"React](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/React-Native-CVE-image2.png\")
<\/pre>\n async function runServer(\r\n _argv: Array,\r\n cliConfig: Config,\r\n args: StartCommandArgs,\r\n ) {\r\n\r\n \/* ... *\/\r\n\r\n const hostname = args.host?.length ? args.host : 'localhost'; \/\/ *** 1 ***\r\n\r\n \/* ... *\/\r\n\r\n const protocol = args.https === true ? 'https' : 'http';\r\n const devServerUrl = url.format({protocol, hostname, port}); \/\/ *** 2 ***\r\n\r\n \/* ... *\/\r\n\r\n console.info(`Starting dev server on ${devServerUrl}\\n`); \/\/ *** 3 ***\r\n\r\n \/* ... *\/\r\n\r\n await Metro.runServer(metroConfig, {\r\n host: args.host, \/\/ *** 4 ***\r\n<\/code><\/pre>\n\n
\n
hostname<\/code> enth\u00e4lt den Parameter host<\/code>, sofern angegeben, andernfalls \"localhost\"<\/code>.<\/li>\ndevServerUrl<\/code> wird unter Verwendung des Hostnamens gebildet.<\/li>\n\u201cStarting dev server on http:\/\/localhost:8081\u201d<\/code> wird ausgegeben.<\/li>\nargs.host<\/code> aufgerufen, der undefined<\/strong> ist, anstatt die Variable hostname<\/code> zu verwenden.<\/li>\n<\/ol>\n<\/li>\n<\/ol>\nhttpServer.listen<\/code><\/p>\nZusammenfassung<\/h2>\n
![\"\"](\"https:\/\/jfrog.com\/wp-content\/uploads\/2025\/08\/JFrog-detects-React-Native-vulnerability.png\")
JFrog SAST erkennt die Schwachstelle und zeigt ihre Details zusammen mit Data Trace Evidence an (Klicken Sie auf das Bild, um es zu vergr\u00f6\u00dfern)<\/em><\/p>\n