Wprowadzenie do problemu / definicja luki
CVE-2025-11953 (często opisywana jako „Metro4Shell”) to krytyczna podatność typu OS Command Injection w Metro Development Server uruchamianym przez React Native Community CLI. Błąd pozwala nieautoryzowanemu atakującemu z sieci wysłać specjalnie przygotowany żądanie POST i doprowadzić do wykonania poleceń/uruchomienia programu na maszynie, która wystawia Metro. Szczególnie niebezpieczne jest to, iż Metro bywa uruchamiane na stacjach deweloperskich i w CI, a w praktyce zdarza się, iż zostaje omyłkowo wystawione na interfejsy zewnętrzne.
W skrócie
- Co to jest: RCE/OS command injection w Metro Dev Server (React Native Community CLI).
- Skala / popularność: dotyczy elementu ekosystemu React Native używanego powszechnie w dev/test.
- Status zagrożenia: obserwowano eksploatację in-the-wild m.in. od 21 grudnia 2025, z kolejnymi falami m.in. 4 i 21 stycznia 2026.
- Poprawka: aktualizacja @react-native-community/cli-server-api do 20.0.0+ (oraz ograniczenie ekspozycji usługi).
Kontekst / historia / powiązania
Podatność została opisana publicznie na początku listopada 2025 r. w analizie JFrog (z CVSS 9.8), a w krótkim czasie pojawiły się PoC.
Kluczowy zwrot nastąpił, gdy VulnCheck wskazał, iż to nie jest już „teoretyczny” problem: ich obserwacje telemetryczne/honeypotowe potwierdziły realne wykorzystanie podatności przeciwko wystawionym serwerom Metro, a aktywność utrzymywała się w kolejnych tygodniach.
Analiza techniczna / szczegóły luki
Sedno problemu to połączenie dwóch elementów:
- Ekspozycja Metro na sieć
Metro Development Server może zostać uruchomiony w sposób, który powoduje bindowanie do interfejsów zewnętrznych (zamiast wyłącznie localhost), co zwiększa powierzchnię ataku. - Niebezpieczny endpoint /open-url i wstrzyknięcie poleceń
Zgodnie z opisem JFrog i NVD, endpoint obsługuje żądania POST, w których wartość wejściowa może trafić w sposób niebezpieczny do mechanizmu otwierania zasobów (funkcja open() z pakietu open), co umożliwia wykonanie poleceń/systemowych akcji.
Różnice platformowe (ważne dla IR):
- Windows: atakujący może wykonywać dowolne polecenia OS (pełna kontrola argumentów powłoki).
- Linux/macOS: możliwe jest uruchamianie programów z ograniczoną kontrolą parametrów (w praktyce przez cały czas wystarcza do „droppera”/loadera).
Zaobserwowane TTP z kampanii in-the-wild (przykłady):
VulnCheck/SecurityWeek/The Hacker News opisują scenariusze, w których po wstępnym wykonaniu dochodziło do etapowego ładunku, m.in. skryptów PowerShell oraz prób osłabiania ochron (np. poprzez działania pod Microsoft Defender) i pobrania kolejnego payloadu (w opisywanych przypadkach również w Rust).
Praktyczne konsekwencje / ryzyko
Najważniejsze: to nie jest „bug w aplikacji mobilnej na produkcji”, tylko wektor wejścia w łańcuch dev → CI/CD → repo/sekrety → supply chain.
Realne skutki przejęcia stacji deweloperskiej lub runnera CI:
- kradzież tokenów (GitHub/GitLab), kluczy SSH, sekretów z .env, access keys do chmur,
- podmiana zależności, wstrzyknięcie backdoora do buildów, przejęcie podpisywania artefaktów,
- lateral movement do zasobów firmowych przez VPN/SSO,
- instalacja malware i trwałość (persistence) na hostach developerskich.
Dodatkowy problem: Metro/CLI bywa uruchamiane „na szybko” w sieci biurowej, coworku, a czasem na publicznym IP (VM/test). To dokładnie ten typ podatności, gdzie jeden błąd ekspozycji robi z narzędzia developerskiego usługę podatną na atak z Internetu.
Rekomendacje operacyjne / co zrobić teraz
Jeśli w organizacji używacie React Native:
- Zidentyfikuj ekspozycję Metro
- sprawdź, czy gdziekolwiek Metro Dev Server jest osiągalny spoza localhost/VPN (stacje dev, serwery testowe, build-agenty),
- przeskanuj segmenty sieci pod kątem usług developerskich wystawionych na portach używanych w RN/Metro (w praktyce: kontrola firewall + inwentaryzacja procesów).
- Zaktualizuj podatny komponent
- podnieś @react-native-community/cli-server-api do 20.0.0 lub nowszej (w każdym projekcie, gdzie dependency występuje).
- Wymuś bezpieczne bindowanie
- jeżeli nie możesz od razu zaktualizować: uruchamiaj Metro jawnie z bindowaniem do 127.0.0.1 (np. --host 127.0.0.1).
- Wykrywanie i IR (minimum)
- przejrzyj logi/proxy pod nietypowe POST-y do ścieżek typu /open-url,
- zweryfikuj, czy na hostach nie pojawiły się nietypowe procesy potomne (np. powershell, cmd, nieznane binarki w katalogach tymczasowych),
- rotuj sekrety, jeżeli istnieje podejrzenie ekspozycji Metro na sieć i brak pewności, czy endpoint był wykorzystywany.
Różnice / porównania z innymi przypadkami
CVE-2025-11953 jest podręcznikowym przykładem klasy ryzyk „dev tooling exposed to network”: serwery developerskie i endpointy „ułatwiające życie” (np. otwieranie URL, debug tooling) są projektowane jako lokalne, a w praktyce bywają routowalne w sieci. Gdy dojdzie do wystawienia poza localhost, choćby prosta podatność (lub „feature”) zamienia się w krytyczny RCE.
Wyróżnik „Metro4Shell” to praktyczna, wieloplatformowa ścieżka initial access oraz potwierdzona eksploatacja w czasie, gdy część dyskusji publicznej przez cały czas traktowała temat jako hipotetyczny.
Podsumowanie / najważniejsze wnioski
- To aktywnie wykorzystywana luka RCE (OS command injection) w Metro Dev Server, powiązana z React Native Community CLI.
- Ryzyko dotyczy przede wszystkim stacji developerskich i CI, czyli miejsc, gdzie znajdują się sekrety i dostęp do pipeline’ów.
- Najszybsza i najlepsza redukcja ryzyka: aktualizacja do 20.0.0+ oraz twarde ograniczenie ekspozycji (localhost/firewall).
Źródła / bibliografia
- BleepingComputer — „Hackers exploit critical React Native Metro bug to breach dev systems” (03.02.2026). (BleepingComputer)
- JFrog — „Critical RCE Vulnerability CVE-2025-11953 Puts React Native Developers at Risk” (04.11.2025). (JFrog)
- VulnCheck — „Metro4Shell: Exploitation of React Native’s Metro Server in the Wild” (03.02.2026). (VulnCheck)
- NVD (NIST) — CVE-2025-11953 (rekord CVE, opis i wektory/CVSS od CNA). (nvd.nist.gov)
- SecurityWeek — „Critical React Native Vulnerability Exploited in the Wild” (03.02.2026). (SecurityWeek)
