- CVE-2025-55182 w React i CVE-2025-66478 w Next.js umożliwiają zdalne wykonywanie kodu bez uwierzytelniania za pośrednictwem protokołu React Server Components Flight.
- Błąd wynika z niebezpiecznej deserializacji ładunków RSC, w wyniku której domyślne konfiguracje React i Next.js pozostają widoczne i nie można wprowadzać żadnych zmian w kodzie.
- Badacze ds. bezpieczeństwa informują o niemal stuprocentowej niezawodności wykorzystania luk i ostrzegają, że w miarę analizowania poprawek prawdopodobne są masowe ataki.
- Jedynym skutecznym środkiem zaradczym jest natychmiastowa aktualizacja do udoskonalonych wersji React i Next.js, zwłaszcza w środowiskach chmurowych, gdzie narażonych na atak może być nawet 40% użytkowników.
Ujawnienie CVE-2025-55182 w React i jego bliźniaczy problem CVE-2025-66478 w Next.js rzucił światło na to, jak kruche mogą być stosy JavaScript po stronie serwera, gdy protokoły niskiego poziomu zawodzą. Zamiast niszowego błędu, jest to wada o najwyższym stopniu zagrożenia, umożliwiająca zdalne wykonanie kodu, która uderza w rdzeń komponentów React Server i Protokół lotu od których po cichu zależy wiele nowoczesnych aplikacji.
To, co czyni tę sprawę szczególnie niepokojącą, to fakt, że domyślne ustawienia są widoczne. Prosta aplikacja Next.js wygenerowana za pomocą create-next-app, stworzony do produkcji i wdrożony bez żadnych nietypowych opcji, może zostać naruszony przez nieuwierzytelnione żądanie HTTP. Bez wymyślnej błędnej konfiguracji, bez egzotycznej wtyczki — po prostu standardowy stos, który wiele zespołów wdraża każdego dnia.
Jak odkryto luki CVE-2025-55182 i CVE-2025-66478
Przyczyną problemu jest implementacja react-server, która obsługuje komponenty React Server Components (RSC)Ten pakiet stanowi podstawę protokołu Flight, który służy do przesyłania zserializowanych danych komponentów między klientem a serwerem. Kiedy badacz ds. bezpieczeństwa Lachlan Davidson podejrzane zachowanie zgłoszono w programie Bug Bounty Meta pod koniec listopada, co wywołało szybką reakcję zespołów React i Meta.
Według ostrzeżeń publicznych, luka została ujawniona w środę i łatki awaryjne wysłano w ciągu około czterech dniTo niezwykle szybki czas reakcji w przypadku problemu dotyczącego tak dużego ekosystemu i podkreśla, jak poważna jest ta wada: osoby odpowiedzialne za utrzymanie Reacta oceniły go na Wynik CVSS 10.0, maksymalna możliwa.
Równolegle, Vercel — firma stojąca za Next.js — przeanalizowano, jak ten sam błąd wpłynął na jego strukturę. Ponieważ Next.js korzysta z tego samego protokołu RSC Flight na serwerze, odziedziczył tę słabość i otrzymał własny identyfikator, CVE-2025-66478Vercel wydał ostrzeżenie i udostępnił poprawki tego samego dnia, w którym opublikowano ostrzeżenie React, mając na celu maksymalne skrócenie czasu, w którym atakujący mogą podjąć działanie.
Pomimo szybkiej reakcji, dostawcy rozwiązań zabezpieczających i badacze zaczęli ostrzegać, że atakujący prawdopodobnie dokonają inżynierii wstecznej poprawek bardzo szybko, jak widać w ataki na łańcuch dostaw na npm. Gdy poprawiony kod zostanie upubliczniony, znacznie łatwiej będzie wywnioskować, gdzie znajdował się błąd i stworzyć działające exploity.
Co dokładnie jest nie tak w protokole React Flight?
Na poziomie technicznym zarówno CVE-2025-55182, jak i CVE-2025-66478 sprowadzają się do niebezpieczna deserializacja danych kontrolowanych przez atakującego w ramach protokołu Flight. Komponenty serwera React wysyłają i odbierają ustrukturyzowane ładunki, które następnie serwer dekoduje i wykorzystuje do sterowania przepływem wykonania.
Wrażliwa logika w react-server pakiet nie przeprowadzono ścisłej weryfikacji struktury i zawartości przychodzących ładunków RSCWysyłając celowo zniekształcony, ale starannie opracowany ładunek Flight do punktu końcowego funkcji serwera React, atakujący może wpłynąć na działanie serwera podczas deserializacji tych danych. Zamiast po prostu rekonstruować łagodny stan komponentu, ścieżka kodu może zostać skierowana do wykonania. uprzywilejowany JavaScript na serwerze.
Ponieważ błąd wpływa na sposób dekodowania protokołu, nie jest wymagane uwierzytelnianieZdalny atakujący musi mieć możliwość wysyłania żądań HTTP do dowolnego dostępnego punktu końcowego RSC lub funkcji serwera. To zmienia lukę w prosty, nieuwierzytelniony wektor RCE: wyślij spreparowane żądanie, poczekaj na niebezpieczną deserializację, a ładunek może zostać wykonany w zapleczu.
Naukowcy z Wiz, którzy niezależnie przeanalizowali ten problem, opisują go jako luka w zabezpieczeniach deserializacji logicznej a nie prosty błąd parsowania. Podczas testów udało się uzyskać w pełni działający exploit proof-of-concept niezawodność bliska 100% w wyzwalaniu wykonania kodu na podatnych celach.
Dlaczego domyślne wdrożenia React i Next.js są zagrożone
Jednym z najbardziej niepokojących aspektów tych CVE jest to, że wpływają na konfiguracje gotowe do użyciaW przypadku wielu problemów bezpieczeństwa, ich wykorzystanie wymaga użycia specjalnej flagi funkcji, rzadko używanej wtyczki lub niestandardowego trybu wdrożenia. W tym przypadku tak nie jest.
Komponenty React Server i ich protokół Flight stały się integralnymi elementami nowoczesnych architektur React 19 i Next.js. W rezultacie standardowa wersja produkcyjna wygenerowana przez create-next-app może być podatny na ataki bez konieczności dodawania dodatkowego kodu przez programistę aplikacji. Atakujący nie musi zgadywać niestandardowych tras ani logiki biznesowej; wystarczy nadużycie ogólnych punktów końcowych RSC.
Wada nie ogranicza się do samego Next.js. Każdy framework lub narzędzie, które łączy lub ponownie implementuje protokół RSC Flight na serwerze mogą być podatne. Publiczne ostrzeżenia i raporty dotyczące bezpieczeństwa wskazują na kilka zagrożonych ekosystemów:
- Next.js, najbardziej znana struktura, na którą wpłynął dalszy rozwój
- Wtyczka Vite RSC (
@vitejs/plugin-rsc) - Wtyczka Parcel RSC (
@parcel/rsc) - Podgląd React Router RSC
- RedwoodSDK (często określane jako
rwsdk) - waku i innych łańcuchów narzędzi obsługujących RSC
W samym Reactie błąd ma wpływ wersje 19.0, 19.1.0, 19.1.1 i 19.2.0 odpowiednich pakietów. Opiekunowie stwierdzają, że aktualizacja do wersji 19.0.1, 19.1.2 lub 19.2.1 Zapewnia wzmocnione zachowanie i usuwa lukę w zabezpieczeniach. Next.js ma odpowiednie, poprawione wersje, które integrują poprawioną logikę serwera React.
Niektórzy dostawcy infrastruktury doprecyzowali granice wpływu. Na przykład Google stwierdził, że publiczne obrazy systemu operacyjnego dla Compute Engine domyślnie nie są podatne na atakiponieważ nie dostarczają gotowych bibliotek React lub Next.js; ryzyko pojawia się, gdy użytkownicy wdrażają podatne na ataki wersje tych frameworków na obrazach bazowych.
Jaki jest promień wybuchu w chmurze?
Skala problemu staje się oczywista, gdy spojrzymy na to, jak szeroko React i Next.js są wykorzystywane w środowisku produkcyjnym. React stanowi podstawę interfejsów użytkownika dla głównych platform, takich jak Facebook, Instagram, Netflix, Airbnb, Shopify, Walmart, Asana i wiele innychPonadto niezliczona ilość mniejszych aplikacji i wewnętrznych pulpitów nawigacyjnych jest tworzona przy użyciu tych samych komponentów i struktur.
Zespoły ds. wywiadu zagrożeń w firmie Wiz przeanalizowały dane telemetryczne ze środowisk chmurowych i odkryły, że około 39–40% wdrożeń w chmurze zawiera podatne na ataki instancje React lub Next.js. Tylko w przypadku Next.js framework pojawia się w przybliżeniu 69% badanych środowiski około 61% z nich to aplikacje publiczne działające na jego bazie. Gdy połączymy te procenty, oznacza to, że mniej więcej 44% wszystkich obserwowanych środowisk chmurowych hostuje publicznie dostępne instancje Next.js, niezależnie od dokładnej wersji frameworka.
To nakładanie się popularności i podatności na ataki alarmuje obrońców. Gdy szeroko wdrożony stos ma błąd RCE o maksymalnej wadze i nieuwierzytelnionym działaniu z niezawodną ścieżką ataku, niemal pewne jest, że po tym nastąpią ataki oportunistyczne i ukierunkowaneNawet organizacje, które szybko wdrażają poprawki, mogą mieć do czynienia z krótkim czasem, w którym narażone punkty końcowe mogą zostać zbadane i naruszone.
W momencie pierwszych ujawnień, nie zgłoszono publicznie żadnego potwierdzonego przypadku eksploatacji na wolnościJednak wielu badaczy ds. bezpieczeństwa, w tym eksperci z Rapid7 i watchTowr, podkreślili, że można realistycznie założyć, że osoby stwarzające zagrożenie już teraz dokonują inżynierii wstecznej poprawek, skanują niezałatane usługi i budują zautomatyzowane łańcuchy ataków.
Co mówią badacze i dostawcy na temat ryzyka związanego z eksploatacją
Oświadczenia społeczności zajmującej się bezpieczeństwem przedstawiają spójny obraz: to nie jest problem teoretyczny, a bariera wejścia dla atakujących jest niska. Benjamin Harris, dyrektor generalny watchTowr, opisał tę lukę jako poważne ryzyko dla użytkowników jednego z najpopularniejszych na świecie frameworków internetowych i podkreślił, że do eksploatacji potrzeba „niewielu warunków wstępnych”.
Naukowcy z Wiz potwierdzili tę ocenę po przetestowaniu zarówno wersji podatnych na ataki, jak i załatanych. Ich wewnętrzne eksperymenty wykazały, że zmodyfikowane ładunki wykorzystywane do wykorzystania niebezpiecznej deserializacji osiągnęły wskaźnik sukcesu bliski 100% w wywołaniu pełnego zdalnego wykonania kodu na dotkniętych serwerach. Zauważyli również, że atak jest całkowicie zdalny i nieuwierzytelniony, sterowane wyłącznie przez specjalnie skonstruowane żądania HTTP.
Z perspektywy Rapid7 oczekiwanie jest takie, że opisy techniczne i dowody koncepcji dotyczące luk w zabezpieczeniach pojawią się, gdy wystarczająca liczba osób przeanalizuje poprawkiTo z kolei może doprowadzić do nasilenia szerszych prób skanowania i masowej eksploatacji luk w zabezpieczeniach, zwłaszcza w środowiskach chmurowych z wieloma aplikacjami skierowanymi do Internetu.
Nawet poza społecznością dostawców, media branżowe przedstawiły te CVE jako zagrożenie dla znacznej części InternetuRaporty podkreśliły nie tylko samą skalę problemu, ale także liczbę dużych witryn konsumenckich, platform SaaS i zapleczy API, które opierają się na React i Next.js w zakresie front-endów i renderowania po stronie serwera.
Kroki zaradcze: co użytkownicy React i Next.js powinni teraz zrobić
W przypadku zespołów korzystających z React lub Next.js w środowisku produkcyjnym, wskazówki od konserwatorów i badaczy sprowadzają się do jednego prostego punktu: jedynym ostatecznym rozwiązaniem jest aktualizacja do poprawionej wersjiNie ma przełączników konfiguracji ani ogólnych reguł WAF, które mogłyby w pełni rozwiązać problem niebezpiecznego zachowania deserializacji w protokole Flight.
Zespół React zaleca wszystkim użytkownikom gałęzi dotkniętych problemem przechodzi na utwardzone wersje 19.0.1, 19.1.2 lub 19.2.1, upewniając się, że react-server Pakiet jest zawarty w aktualizacji. Dla Next.js firma Vercel opublikowała poprawiono kompilacje, które integrują poprawioną obsługę RSCAdministratorzy powinni zapoznać się z oficjalnym poradnikiem Next.js, aby określić minimalną bezpieczną wersję dla wybranej linii wydań.
Organizacje, które polegają na innych Ramy obsługujące RSC — takie jak Redwood, Waku, React Router's RSC preview lub wtyczki Vite i Parcel RSC — są zalecane sprawdź odpowiednie notatki dotyczące wydania i kanały bezpieczeństwaW wielu przypadkach te projekty po prostu opakowują lub pakują komponenty serwerowe React, dlatego wymagana jest aktualizacja samego Reacta, a następnie pobranie najnowszej wersji frameworka.
Oprócz prostego łatania, do tego celu wykorzystuje się narzędzia skoncentrowane na chmurze. polowanie na podatne przypadki na dużą skalęKlienci Wiz mogą na przykład skorzystać z zapytań i ostrzeżeń w Centrum Zagrożeń Wiz, aby dowiedzieć się, gdzie w ich środowiskach wdrożone są zagrożone wersje React lub Next.js. Inne organizacje korzystają z inwentaryzacji zasobów, danych SBOM i skanowania kontenerów, aby uzyskać podobną widoczność.
Jeżeli istnieje jakiekolwiek wskazanie, że systemy mogły już zostać zaatakowane lub naruszone za pomocą tych luk bezpieczeństwa (CVE), zalecane jest wsparcie w zakresie reagowania na incydentyNiektórzy dostawcy zachęcają klientów, którzy podejrzewają wykorzystanie luk CVE-2025-55182 lub CVE-2025-66478, do kontaktu z ich zespołami ds. IR w celu uzyskania pomocy w selekcji, zabezpieczeniu i dochodzeniu.
Co to ujawnia na temat ekosystemu internetowego JavaScript
Chociaż poprawki React i Next.js zamykają bezpośrednią lukę, incydent ten podnosi szersze pytania dotyczące tego, w jaki sposób frameworki JavaScript po stronie serwera obsługują niezaufane daneProtokoły takie jak Flight są ukryte głęboko w stosie, za abstrakcjami, których programiści rzadko sprawdzają bezpośrednio. Oznacza to, że wady mogą mieć daleko idące konsekwencje, zanim zostaną zauważone.
Fakt, że podatne zachowanie dostarczane w domyślnych, mocno promowanych konfiguracjach Podkreśla również napięcie między doświadczeniem programisty a projektowaniem z domyślnym zabezpieczeniem. Funkcje ułatwiające tworzenie nowoczesnych aplikacji – takie jak komponenty serwerowe i płynna serializacja między klientem a serwerem – mogą dyskretnie wprowadzać złożone obszary ataku.
Dla zespołów ds. bezpieczeństwa sprawa ta stanowi kolejne przypomnienie, że luki na poziomie struktury mogą natychmiast przekształcić się w narażenie całej organizacjiPojedynczy błąd w popularnym komponencie open source może być przyczyną dziesiątek oddzielnych aplikacji, mikrousług i narzędzi wewnętrznych, zwłaszcza gdy ponownie wykorzystuje się kontenery i szablony.
Pozytywną stroną jest reakcja opiekunów Reacta, Meta i Vercel, która pokazuje, że skoordynowane ujawnianie informacji i szybkie opracowywanie poprawek są możliwe nawet w dużych ekosystemachPrzejrzyste ostrzeżenia, poprawki wersji i współpraca z dostawcami zabezpieczeń pomogły obrońcom nadać priorytet temu problemowi wśród wielu konkurujących ze sobą luk.
Patrząc w przyszłość, wielu obserwatorów spodziewa się dalszej kontroli serializacja, deserializacja i logika analizy protokołów w frameworkach internetowychJeśli luki CVE-2025-55182 i CVE-2025-66478 spowodują bardziej systematyczne testowanie i ściślejszą walidację komponentów takich jak Flight, w przypadku poważnego incydentu mogą pojawić się pewne długoterminowe korzyści w zakresie bezpieczeństwa.
Na razie zespoły korzystające ze stosów React lub Next.js ścigają się między wdrażanie poprawek i automatyzacja atakujących. Biorąc pod uwagę maksymalny poziom zagrożenia RCE wpływający na domyślne konfiguracje, rozległą obecność w chmurze i niezawodne techniki eksploatacji, które zostały już udowodnione w badaniach, utrzymanie bezpieczeństwa tych środowisk sprowadza się do tego, jak szybko organizacje potrafią zidentyfikować obszary narażone na ataki i przenieść wszystko do wzmocnionych wersji.
