- 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.
- Problem wynika z niebezpiecznej deserializacji zmodyfikowanych ładunków RSC, co ma wpływ na domyślne konfiguracje w popularnych frameworkach.
- Badacze informują o niemal 100-procentowej niezawodności wykorzystania luk i szacują, że około 39–40% środowisk chmurowych obejmuje podatne na ataki instancje.
- Jedynym skutecznym środkiem zaradczym jest natychmiastowa aktualizacja wersji React i Next.js; osoby odpowiedzialne za obronę powinny również przeprowadzić audyt wszelkich struktur obsługujących RSC.
W ciągu ostatnich kilku dni ekosystem JavaScript zmagał się z parą problemów luki w zabezpieczeniach o maksymalnym stopniu zagrożenia w React i Next.js, które otwierają drzwi do zdalnego wykonywania kodu na dotkniętych serwerach. Luki, oznaczone jako CVE-2025-55182 dla React i CVE-2025-66478 w przypadku Next.js skupimy się na tym, w jaki sposób komponenty React Server obsługują specjalistyczny ruch sieciowy w tzw. protokole Flight.
Ponieważ te problemy mają wpływ domyślne konfiguracje frameworka i można je uruchomić jedynie za pomocą spreparowanego żądania HTTP, szybko znalazły się na szczycie list poprawek wielu zespołów ds. bezpieczeństwa. Dostawcy, badacze i dostawcy usług chmurowych są teraz zgodni: natychmiast wdrażaj poprawki, oceniaj ryzyko i przygotuj się na szeroko zakrojone próby skanowania i wykorzystania luk w zabezpieczeniach.
Czym właściwie są CVE-2025-55182 i CVE-2025-66478
Sednem problemu jest wada w pakiet react-server, komponent, który obsługuje React Server Components (RSC) i protokół Flight. W wersjach podatnych na ataki serwer akceptuje specjalnie ukształtowane ładunki RSC i deserializuje je bez odpowiedniej walidacji, umożliwiając atakującemu przejęcie kontroli nad danymi i zakłócenie logiki działającej na serwerze.
To zachowanie zmienia to, co powinno być danymi strukturalnymi, w pojazd do wykonywania uprzywilejowanego JavaScript w zapleczu. Gdy żądanie HTTP atakuje punkt końcowy RSC lub Server Function ze złośliwym ładunkiem Flight, niebezpieczna ścieżka deserializacji może zostać wykorzystana w celu nieuwierzytelnionego zdalnego wykonania kodu (RCE). Nie jest wymagany żaden wcześniejszy dostęp, poświadczenia ani interakcja użytkownika.
Strona React problemu jest śledzona jako CVE-2025-55182, oceniony na szczycie skali z wynikiem CVSS 10.0. Ponieważ Next.js implementuje RSC i protokół Flight na tych prymitywach, dziedziczy tę samą podstawową słabość: wpływ na dalsze działanie jest przypisywany CVE-2025-66478 i ma taki sam stopień ważności.
W ostrzeżeniach dotyczących bezpieczeństwa błąd ten jest opisany jako luka w zabezpieczeniach deserializacji logicznej a nie klasyczny problem bezpieczeństwa pamięci. Błąd tkwi w sposobie analizowania i uwierzytelniania danych, a nie w obsłudze bufora niskiego poziomu. Niemniej jednak, wynik jest równie poważny: zdalny atakujący może sterować wykonywaniem po stronie serwera.
Które konfiguracje React i Next.js są podatne na ataki
Wpływ podatności Stos po stronie serwera React 19 w kilku powszechnie wdrażanych wersjach. Konserwatorzy wskazali wydania takie jak 19.0, 19.1.0, 19.1.1 i 19.2.0 jako podatne na react-server Pakiet i jego implementacja protokołu Flight. Poprawione gałęzie są dystrybuowane jako 19.0.1, 19.1.2 i 19.2.1, które wprowadzają zaostrzoną logikę deserializacji.
Po stronie ramowej, Next.js jest domyślnie dotknięty. Typowa aplikacja wygenerowana za pomocą create-next-app, stworzony do produkcji i wdrożony z domyślnymi ustawieniami, może być podatny na ataki bez konieczności dodawania dodatkowego kodu przez dewelopera. W związku z tym Vercel, firma stojąca za Next.js, wydała własne ostrzeżenie o numerze CVE-2025-66478 i udostępniła zaktualizowane wersje frameworka, które wykorzystują poprawione pakiety React.
Wpływ nie ogranicza się wyłącznie do Next.js. Każdy komponent ekosystemu, który łączy lub podłącza do komponentów serwera React Protokół Flight jest prawdopodobnie narażony na ataki. Obejmuje to między innymi narzędzia i struktury, takie jak:
- Next.js
- @vitejs/plugin-rsc (Wtyczka Vite RSC)
- @parcel/rsc (Wtyczka Parcel RSC)
- Podgląd React Router RSC
- RedwoodSDK / rwsdk
- waku
Zespoły badawcze podkreśliły, że domyślne konfiguracje są na ogół zagrożoneInnymi słowy, nawet jeśli programista nie włączył celowo żadnych flag eksperymentalnych ani nietypowych ustawień, ich wdrożenie nadal może być podatne na ataki, jeśli używa podatnej wersji komponentów React Server.
Jak łatwo jest wykorzystywać i dlaczego obrońcy się martwią
Społeczność zajmującą się bezpieczeństwem zaniepokoiła się tym, że niska bariera eksploatacjiWiele grup badawczych donosi, że atak na te luki wymaga jedynie wysłania specjalnie spreparowanego żądania HTTP do dostępnego punktu końcowego RSC lub funkcji serwera. Nie ma potrzeby uwierzytelniania, skomplikowanych warunków wstępnych ani interakcji użytkownika, co czyni ten scenariusz szczególnie atrakcyjnym dla zautomatyzowanych ataków.
W kontrolowanych testach zespoły takie jak Wiz Research stworzyły działające prototypy exploitów i zaobserwowały niezawodność bliska 100% w wyzwalaniu RCE w podatnych konfiguracjach. Chociaż te pełne ładunki nie zostały jeszcze opublikowane, panuje konsensus, że podstawowe zachowanie jest na tyle proste, że inni mogą zrekonstruować działające exploity, analizując publiczne poprawki.
Biorąc pod uwagę popularność React i Next.js, wielu ekspertów uważa, że masowe skanowanie i uzbrojenie to tylko kwestia czasuIstnieją wczesne porównania do innych poważnych luk po stronie serwera, których wykorzystanie wzrosło, gdy szczegóły techniczne i przykładowy kod zostały udostępnione społecznościom podziemnym lub publicznym repozytoriom.
Naukowcy podkreślają również, szerokość potencjalnych celówReact stanowi podstawę witryn i aplikacji w dużych organizacjach, w tym w mediach społecznościowych, e-commerce, streamingu, SaaS i innych. Frameworki takie jak Next.js są szeroko stosowane zarówno w aplikacjach wewnętrznych, jak i skierowanych do klientów, co oznacza, że podatne na ataki infekcje mogą pojawić się zarówno głęboko w sieciach korporacyjnych, jak i w publicznych interfejsach użytkownika.
W czasie, gdy publikowano wiele ostrzeżeń, istniało brak potwierdzonych doniesień o eksploatacji na wolnościAnalitycy twierdzą jednak, że można założyć, iż sprawcy zagrożeń już teraz dokonują inżynierii wstecznej poprawek i mapują hosty, które są dostępne i nieprawidłowo skonfigurowane.
Jak szerokie jest narażenie w środowiskach chmurowych
Kilka punktów danych ze skanów w chmurze ilustruje skalę problemu. Łowcy zagrożeń z Wiz podają, że około 39% środowisk chmurowych Przeanalizowali przypadki React lub Next.js działające w wersjach podatnych na CVE-2025-55182 i/lub CVE-2025-66478. Inne analizy przybliżają tę liczbę do 40%, gdy obie technologie są liczone razem.
Jeśli przyjrzeć się bliżej Next.js, sam framework pojawia się w przybliżeniu 69% środowisk w ich zbiorze danych. Zdecydowana większość z nich jest gospodarzem aplikacje publicznie dostępne zbudowany na Next.js. Inaczej mówiąc, ich telemetria sugeruje, że około 44% wszystkich środowisk chmurowych mieć co najmniej jedną instancję Next.js dostępną w Internecie, niezależnie od tego, czy jest ona obecnie załatana.
To połączenie wysoka gęstość rozmieszczenia i ekspozycja publiczna To właśnie tego szukają atakujący, wybierając luki w zabezpieczeniach, w które warto zainwestować. Pojedynczy łańcuch ataków można wykorzystać na dużą skalę przeciwko wielu celom o podobnej konfiguracji, a zautomatyzowane narzędzia mogą przeszukiwać całe zakresy adresów IP w celu znalezienia niezałatanych serwerów.
Niektórzy dostawcy pracują nad zawężeniem promienia rażenia. Na przykład Google wskazał, że domyślne publiczne obrazy systemu operacyjnego używane w ramach rozwiązania Compute Engine platformy Google Cloud nie są od razu podatne na ataki, jednak klienci nadal muszą przeprowadzać audyt i naprawiać błędy w aplikacjach wdrażanych na tych obrazach.
Oferta dostawców Zapory aplikacji internetowych (WAF) Również włączają się do dyskusji. Na przykład Cloudflare zasugerowało, że jego WAF może pomóc chronić niektóre aplikacje React przed próbami wykorzystania luk w zabezpieczeniach, gdy ruch jest w pełni kierowany przez usługę, choć takie zabezpieczenia najlepiej postrzegać jako dodatkową warstwę, a nie jako zamiennik aktualizacji oprogramowania bazowego.
Oś czasu, odkrycie i odpowiedź dostawcy
Ciąg zdarzeń wokół CVE-2025-55182 i CVE-2025-66478 rozwijał się szybko. Badacz ds. bezpieczeństwa Lachlan Davidson zidentyfikował problem w sposobie, w jaki React dekoduje ładunki przeznaczone dla punktów końcowych funkcji serwera React i zgłosił go za pośrednictwem programu bug bounty Meta pod koniec listopada.
React, pierwotnie opracowany w Meta, a obecnie stanowiący podstawę wielu nowoczesnych stosów internetowych, szybko zareagował po potwierdzeniu doniesień. W ciągu około czterech dniZespół React we współpracy z Meta wydał awaryjne aktualizacje dla dotkniętych problemem linii 19.x, a także komunikat dotyczący bezpieczeństwa nakazujący natychmiastową aktualizację.
Tego samego dnia, Vercel ogłosił własne ostrzeżenie dla Next.js w ramach CVE-2025-66478. Twórcy frameworka opublikowali poprawione wersje, wskazówki dla użytkowników oraz szczegółowe informacje o tym, jak implementacja RSC w Next.js dziedziczy podatność z bibliotek serwerowych React.
Wiele z publicznych opisów jest celowo pomiń szczegółowe informacje o eksploicie krok po kroku Na razie. Zamiast tego skupiają się na wyjaśnieniu ryzyka, wymienieniu zagrożonych komponentów i wersji oraz wskazaniu użytkownikom zaktualizowanych kompilacji. Celem jest danie obrońcom czasu na wdrożenie poprawek, jednocześnie spowalniając mniej zaawansowanych atakujących.
Głosy przedstawicieli branży, w tym badaczy z firm takich jak watchTowr i Rapid7, powtarzają, że jest to problem o wysokim priorytecie dla każdego, kto korzysta z React lub Next.js w środowisku produkcyjnymi że czas, jaki upływa zanim exploity staną się publicznie widoczne, może być krótki.
Co zespoły powinny zrobić teraz
Dla organizacji korzystających z komponentów React Server, Next.js lub dowolnych wtyczek i frameworków obsługujących RSC najwyraźniejszą wskazówką jest to, że jedynym całkowitym rozwiązaniem jest aktualizacja do wersji wzmocnionychNie ma przełącznika konfiguracji, który bezpiecznie neutralizowałby błąd, pozostając jednocześnie na podatnych na ataki wersjach.
W przypadku React oznacza to przejście z dotkniętych tym problemem kompilacji 19.x, takich jak 19.0, 19.1.0, 19.1.1 i 19.2.0, 19.0.1, 19.1.2 lub 19.2.1, w zależności od gałęzi, do której przypięty jest projekt. Te wersje zawierają bardziej rygorystyczne kontrole dotyczące ładunków protokołu Flight i eliminują niebezpieczne zachowanie deserializacji.
Dla użytkowników Next.js zaleca się: aktualizacja poprawionych wersji frameworka ogłoszone w ostrzeżeniu Vercela, gwarantujące, że drzewo zależności pobierze stałe pakiety serwera React. Nawet projekty, które nie używają jawnie RSC w swoim kodzie, mogą nadal być narażone, jeśli framework umożliwia korzystanie z komponentów serwera w tle.
Zespoły korzystające z innych stosów obsługujących RSC, w tym Redwood, Waku, wersji zapoznawczej React Router RSC oraz wtyczek RSC dla Vite i Parcel, powinny monitoruj kanały oficjalne z tych projektów. Wiele z nich dołącza własne kopie środowiska wykonawczego serwera React, więc ich opiekunowie publikują szczegółowe instrukcje aktualizacji i numery wersji, na które należy zwrócić uwagę.
Dla organizacji z rozległą infrastrukturą chmurową ustalenie, gdzie znajdują się wszystkie podatne elementy, może być trudne. Niektórzy dostawcy rozwiązań bezpieczeństwa, tacy jak Wiz, oferują wstępnie skonfigurowane zapytania i ostrzeżenia na swoich platformach, aby pomóc klientom w identyfikacji zainfekowanych instancji React i Next.js w różnych środowiskach. Inni udostępniają logikę wykrywania i reguły skanowania, aby wewnętrzne zespoły ds. bezpieczeństwa mogły się do nich dostosować.
Co to oznacza dla szerszego ekosystemu internetowego
Pojawienie się luk CVE-2025-55182 i CVE-2025-66478 wywołuje szerszą dyskusję na temat tego, jak frameworki JavaScript po stronie serwera obsługują złożone formaty serializacjiRSC i protokół Flight to potężne narzędzia do tworzenia nowoczesnych aplikacji, ale ta sama elastyczność, która umożliwia korzystanie z zaawansowanych funkcji, może również stwarzać subtelne możliwości ataku, jeśli logika analizy składniowej nie zostanie starannie zabezpieczona.
Dla programistów ten odcinek jest przypomnieniem, że Poleganie na domyślnym zachowaniu frameworka nie gwarantuje bezpieczeństwa i znaczenie ochrony przed ataki na łańcuch dostaw na npmW tym przypadku zwykłe, szablonowe konfiguracje wystarczyły, aby narazić aplikację na nieuwierzytelnione RCE. Nadążanie za ostrzeżeniami dotyczącymi bezpieczeństwa, przypinanie zależności i szybkie wdrażanie aktualizacji stają się nieuniknionymi zadaniami dla zespołów dostarczających usługi oparte na React lub Next.js.
Z punktu widzenia obronnego organizacje wykorzystują to wydarzenie do przeglądu swoich strategie ochrony warstwowej. Łatanie luk jest priorytetem, ale wiele osób myśli również o zaostrzeniu kontroli dostępu do punktów końcowych administracyjnych lub wewnętrznych, wdrożeniu reguł WAF w celu wykrywania podejrzanego ruchu protokołu Flight oraz poprawie możliwości obserwacji błędów po stronie serwera, które mogą wskazywać na próby wykorzystania luk w zabezpieczeniach.
Sytuacja ta uwydatnia również, jak bardzo Internet opiera się obecnie na stosunkowo niewielkiej grupie współdzielone komponenty typu open sourcePojedynczy błąd w powszechnie stosowanej bibliotece może rozprzestrzenić się na dostawców usług chmurowych, platformy SaaS i środowiska korporacyjne w ciągu zaledwie kilku dni. Skoordynowane ujawnianie informacji, szybka reakcja dostawców i jasna komunikacja stają się kluczowe, gdy problem dotyczy tak wielu organizacji jednocześnie.
Na razie skupiamy się na instalowaniu podatnych na ataki instalacji React i Next.js w wersjach stałych przed eksploatacja staje się rutynąW związku z tym, że badacze zgłaszają niemal idealną niezawodność luk w zabezpieczeniach, domyślne konfiguracje są podatne na ataki, a znaczna część środowisk chmurowych korzysta z wersji, których dotyczy luka, luki te szybko przestały być niejasnymi szczegółami protokołu i stały się pilnym problemem operacyjnym dla zespołów utrzymujących nowoczesne aplikacje JavaScript.
