- CVE-2025-55182 w React i CVE-2025-66478 w Next.js umożliwiają zdalne wykonywanie kodu bez uwierzytelniania za pośrednictwem protokołu „Flight” komponentów serwera React.
- Błąd powstaje w wyniku niebezpiecznej deserializacji zmodyfikowanych ładunków RSC i wpływa na wiele struktur w ich domyślnej konfiguracji.
- Badacze zaobserwowali niemal 100% niezawodność wykorzystania luk w zabezpieczeniach i szacują, że około 39–40% środowisk chmurowych korzysta z podatnych na ataki instancji React/Next.js.
- Jedynym skutecznym rozwiązaniem jest natychmiastowa aktualizacja udoskonalonych wersji React i Next.js, a dostawcy już udostępniają poprawki i wytyczne.
W ciągu ostatnich kilku dni zespoły ds. bezpieczeństwa na całym świecie intensywnie pracowały nad oceną dwóch niedawno ujawnionych błędów w ekosystemie React: CVE-2025-55182 w komponentach React Server i CVE-2025-66478 w Next.jsTe luki otwierają drzwi do całkowicie zdalnego wykonania kodu na serwerach i wywołały alarm, ponieważ mogą zostać wywołane bez uwierzytelniania i przy minimalnym wysiłku ze strony atakującego.
Problem ten dotyka sedna nowoczesnej infrastruktury JavaScript. React i Next.js napędzają wszystko, od małych projektów pobocznych po platformy wykorzystywane przez duże przedsiębiorstwa, a znaczna część obciążeń chmurowych na nich polega. Naukowcy ostrzegają przed nieuchronna masowa eksploatacja i niemalże doskonała niezawodność eksploatacjiZespoły ds. rozwoju i operacji zostały wezwane do przeniesienia wdrażania poprawek na szczyt listy zadań.
Czym właściwie są CVE-2025-55182 i CVE-2025-66478
Sednem problemu jest Protokół „Flight” komponentów serwera React (RSC), mechanizm wprowadzony do obsługi przepływów renderowania sterowanych przez serwer. CVE-2025-55182 to identyfikator przypisany do luki w zabezpieczeniach w React react-server pakiet, podczas gdy CVE-2025-66478 obejmuje odpowiednią lukę w Next.js, który osadza i rozszerza ten protokół.
Luka jest zasadniczo błąd deserializacji logicznej w sposobie przetwarzania ładunków RSCGdy serwer otrzymuje specjalnie spreparowany, wadliwy ładunek Flight, implementacja nie weryfikuje dokładnie struktury przed podjęciem na nim działania. To niedopatrzenie pozwala atakującemu na przedostanie się danych kontrolowanych przez atakującego do miejsc, w których mogą one wpłynąć na działanie po stronie serwera.
W praktyce oznacza to, że atakujący może wysłać pojedynczy spreparowane żądanie HTTP do funkcji serwera React lub punktu końcowego RSCGdy serwer deserializuje ładunek, można zmusić go do uruchomienia dowolnego kodu JavaScript z uprawnieniami procesu serwera, zmieniając proste żądanie w pełnoprawne zdalne wykonanie kodu (RCE).
Zespoły ds. bezpieczeństwa i dostawcy opisują oba luki CVE jako posiadające maksymalny wynik CVSS 10.0, najwyższa możliwa ocena. Odzwierciedla to połączenie zdalnej dostępności, braku wymagań uwierzytelniania i potencjalnego całkowitego naruszenia bezpieczeństwa środowiska.
Dlaczego domyślne konfiguracje są ujawniane
Jednym ze szczegółów, który budzi szczególne obawy, jest to, że błędy te wpływają standardowe konfiguracje bez nietypowych konfiguracjiTypowa aplikacja Next.js wygenerowana za pomocą create-next-app, skompilowane do produkcji i wdrożone z domyślnymi opcjami mogą być podatne na ataki od samego początku.
To samo dotyczy wielu innych Ramy i narzędzia obsługujące RSC, które łączą w sobie react-server realizacjaPonieważ przyjęli protokół Flight w formie zaprojektowanej przez React, odziedziczyli niebezpieczne zachowanie deserializacji. Programiści nie muszą dodawać żadnych egzotycznych funkcji ani niestandardowej logiki analizy składniowej, aby luka była możliwa do wykorzystania.
To domyślne narażenie zwiększa ryzyko, że atakujący mogą przeszukaj internet w poszukiwaniu punktów końcowych RSC lub funkcji serwera i szybko trafiają na potencjalne cele. Nie potrzeba skradzionych danych uwierzytelniających ani wcześniejszego dostępu: jeśli odpowiednie punkty końcowe są dostępne z publicznego internetu i korzystają z podatnych wersji, znajdują się w strefie zagrożenia.
Badacze ds. bezpieczeństwa podkreślają, że nawet organizacje posiadające dojrzałe programy bezpieczeństwa mogą być narażone na ataki, ponieważ RSC jest często włączane niejawnie poprzez aktualizacje struktury i szablony, a niektóre zespoły mogą nie zdawać sobie sprawy, że używają go w środowisku produkcyjnym.
Zakres wpływu na ekosystemy React i Next.js
Wiele analiz zbiega się w tym samym wniosku: skala potencjalnego promienia wybuchu jest niezwykle duża. Dane z Wiz Research sugerują, że około Od 39% do 40% środowisk chmurowych zawiera wystąpienia React lub Next.js podatne na ataki CVE-2025-55182 i/lub CVE-2025-66478To jest znaczna część warstwy aplikacji publicznego Internetu.
Problem nie ogranicza się do samodzielnych instalacji React. W szczególności Next.js jest niezwykle rozpowszechniony: pojawia się w blisko 69% obserwowanych środowisk w niektórych zbiorach danych, a większość z nich korzysta z publicznych aplikacji Next.js. Ta kombinacja oznacza, że znaczna część środowisk chmurowych bezpośrednio wystawia podatne punkty końcowe na niezaufany ruch.
W odniesieniu do poszczególnych komponentów problem dotyczy React 19.0, 19.1.0, 19.1.1 i 19.2.0 seria zawierająca wadliwe react-server Wdrożenie. Po stronie frameworka, kilka popularnych narzędzi integrujących RSC jest również zaangażowanych. Chociaż dokładny wpływ jest różny, lista technologii powiązanych z podatnym protokołem obejmuje:
- Next.js
- Wtyczka Vite RSC (
@vitejs/plugin-rsc) - Wtyczka Parcel RSC (
@parcel/rsc) - Podgląd React Router RSC
- RedwoodSDK
- waku
Naukowcy podkreślają, że wszelkie struktury lub biblioteki zawierające problem react-server realizacja prawdopodobnie będzie w zakresie, nawet jeśli nie jest wyraźnie wymieniony we wczesnych komunikatach. Organizacjom zaleca się inwentaryzację wykorzystania RSC w narzędziach do kompilacji, wersjach zapoznawczych i projektach pilotażowych, a nie tylko w aplikacjach produkcyjnych o dużym natężeniu ruchu.
Dostawcy usług chmurowych również zaczęli reagować. Na przykład jeden z dostawców zauważył, że domyślne publiczne obrazy systemu operacyjnego dla maszyn wirtualnych nie są dostarczane z domyślnie włączonymi podatnymi na ataki komponentami React, choć nie chroni to obciążeń, w przypadku których klienci sami instalują i konfigurują React lub Next.js.
Jak działa eksploatacja i dlaczego niezawodność jest tak wysoka
Chociaż dostawcy celowo ukrywają niektóre szczegóły dotyczące eksploatacji luk w zabezpieczeniach niskiego poziomu, aby dać obrońcom czas na załatanie luk, ogólny zarys jest publiczny. Ogólnie rzecz biorąc, atakujący musi jedynie… utworzyć żądanie HTTP zawierające określony, wadliwy ładunek RSC skierowany do punktu końcowego serwera, który analizuje dane React Flight.
Ponieważ podatna ścieżka kodu jest częścią standardowej logiki deserializacji, ofiara nie musi klikać w nic, logować się ani wykonywać wieloetapowego procesu. Dopóki atakujący ma dostęp do punktu końcowego funkcji serwera lub RSC, może próbować… wywołać niebezpieczną deserializację i skierować wykonywanie w stronę własnego ładunku.
Zespoły ds. bezpieczeństwa zgłosiły podczas testów, że wykorzystanie luk w zabezpieczeniach wykazało „wysoka wierność” ze wskaźnikiem sukcesu zbliżającym się do 100% po zrozumieniu konfiguracji celu. Taka niezawodność jest rzadkością w przypadku zdalnych ataków i zwiększa prawdopodobieństwo, że atakujący zautomatyzują skanowanie i dokonają ataku na dużą skalę.
Eksperci ostrzegają również, że obecnie publiczne poprawki i ostrzeżenia skutecznie służą jako plan działania w zakresie inżynierii wstecznejNawet jeśli kod exploita nie został jeszcze szeroko udostępniony, sprawcy zagrożeń mogą badać różnice między wersjami podatnymi na ataki a wersjami naprawionymi, aby odtworzyć podatną na ataki logikę i przekształcić ją w broń, podobnie jak w przypadku cadena de suministro de npm.
Według najnowszych raportów nie odnotowano żadnych potwierdzonych przypadków powszechnego wykorzystania luki w zabezpieczeniach, jednak wielu dostawców rozwiązań zabezpieczających i badaczy spodziewa się, że sytuacja ta szybko się zmieni, atakujący ścigają się, aby wykorzystać niezałatane systemy zanim organizacje zakończą działania naprawcze.
Odpowiedzi dostawców i dostępne poprawki
Odkrycie CVE-2025-55182 przypisuje się badacz bezpieczeństwa Lachlan Davidson, który zgłosił problem za pośrednictwem programu nagród za błędy Meta. Od pierwszego ujawnienia do wydania poprawek, czas reakcji był niezwykle szybki, co odzwierciedlało powagę błędu i jego zasięg w całym ekosystemie internetowym.
Zespół React wysłał wzmocnione wersje dotkniętych pakietówW przypadku biblioteki głównej opiekunowie wskazują na aktualizacje takie jak React 19.0.1, 19.1.2 i 19.2.1 oraz równoważne załatane warianty powiązanych komponentów, zamykające konkretną lukę deserializacji w protokole Flight.
Po stronie ramowej, Vercel, który utrzymuje Next.js, przypisał CVE-2025-66478 na dalszy wpływ tej samej luki w RSC i wydał zaktualizowane wersje Next.js, które zawierają poprawione zachowanie komponentów React Server. W swoim komunikacie bezpieczeństwa wyjaśniono, że luka wynika ze sposobu, w jaki React dekoduje ładunki przeznaczone dla… Punkty końcowe funkcji serwera a poprawka ta wzmacnia procedury dekodowania.
Inni autorzy frameworków i wtyczek, którzy korzystają z RSC, tacy jak twórcy wtyczek Redwood, Waku i RSC dla Vite i Parcel, zaczęli wydawać własne wytyczne i aktualizacje wersji zgodne z poprawioną wersją react-server kodUżytkownicy powinni postępować zgodnie z ogłoszeniami dotyczącymi danego projektu oraz instrukcjami aktualizacji.
Odpowiedziało również kilku komercyjnych dostawców usług bezpieczeństwa. Na przykład: Wiz opublikował wstępnie skonfigurowane zapytanie i poradę w swoim Centrum Zagrożeń, dzięki czemu klienci mogą wykrywać podatne na ataki przypadki w swoich środowiskach, podczas gdy inni dostawcy twierdzą, że niektóre zapory sieciowe aplikacji internetowych mogą blokować niektóre próby wykorzystania luk w zabezpieczeniach Jeśli ruch React jest przez nie prawidłowo kierowany. Niemniej jednak, osoby odpowiedzialne za utrzymanie systemu jasno stwierdzają, że poprawki konfiguracji lub reguły WAF nie zastąpią prawidłowego stosowania poprawek.
Ocena ryzyka: kto powinien się najbardziej martwić?
Krótka odpowiedź jest taka każda organizacja korzystająca w środowisku produkcyjnym z frameworków React 19 lub zależnych od RSC Powinniśmy traktować to poważnie, ale niektóre wzorce wdrożeń wyróżniają się jako szczególnie narażone. Na przykład aplikacje Next.js skierowane do użytkowników publicznych stanowią kuszący cel, ponieważ często są bezpośrednio połączone z internetem i domyślnie mają włączone funkcje RSC.
Organizacje intensywnie wykorzystujące Funkcje serwera, routing sterowany serwerem, podglądy lub eksperymentalne funkcje oparte na RSC są szczególnie narażone. W takich konfiguracjach ładunki lotnicze są częściej przetwarzane, co daje przeciwnikom wiele możliwości testowania ładunków i udoskonalania exploitów.
Środowiska współdzielone lub wielodostępne rodzą dodatkowe obawy. Jeśli podatna na ataki usługa React działa z szerokim dostępem do zasobów wewnętrznych, udane RCE może stać się punktem zwrotnym do ruchu poziomego w głąb sieci lub przekraczania granic klientów.
Analitycy wskazują również, że zakres adopcji Reacta przez firmy takie jak Meta, Netflix, Airbnb, Shopify, Walmart i wiele innych— oznacza, że rzeczywisty wpływ nie ogranicza się do czysto technicznych kalkulacji ryzyka. Kompromis w głównym stosie aplikacji może mieć efekt domina dla użytkowników, partnerów i ekosystemów downstream.
Wreszcie, nawet zespoły, które uważają, że nie polegają w dużym stopniu na RSC, powinny zweryfikować to założenie. Ponieważ narzędzia i szablony mogą dyskretnie włączać funkcje RSC, niektóre projekty mogą być bardziej narażone, niż ich opiekunowie zdają sobie z tego sprawę na pierwszy rzut oka.
Praktyczne kroki łagodzące dla użytkowników React i Next.js
We wszystkich ostrzeżeniach konsekwentnie powtarza się jeden punkt: jedynym ostatecznym rozwiązaniem jest aktualizacja do poprawionej wersjiNie ma żadnej flagi konfiguracyjnej ani drobnej zmiany, która całkowicie neutralizowałaby niebezpieczne zachowanie deserializacji bez aktualizowania odpowiednich pakietów.
W przypadku organizacji korzystających bezpośrednio z React, opiekunowie zalecają przechodzenie na utwardzone wersje, takie jak 19.0.1, 19.1.2, 19.2.1 lub nowsze, wraz z zaktualizowanymi react-server i powiązane pakiety RSCZespoły powinny zapoznać się z oficjalnym komunikatem bezpieczeństwa React, aby potwierdzić dokładne wersje, które odnoszą się do luki CVE-2025-55182 w ich drzewie zależności.
Projekty Next.js powinny działać podobnie zaktualizuj do poprawionych wersji frameworka, które zawierają poprawkę dla CVE-2025-66478Ponieważ domyślna kompilacja Next.js jest wystarczająca, aby wywołać problem, na uwagę zasługują nawet małe witryny i wewnętrzne panele sterowania, a nie tylko flagowe aplikacje.
W przypadku środowisk korzystających z innych struktur obsługujących RSC, takich jak Redwood, Waku lub wtyczki RSC dla programów pakujących, takich jak Vite i Parcel, zaleca się uważnie śledzić ogłoszenia dostawców i wdrażać wszelkie aktualizacje, które obejmują wzmocnione react-server realizacja Gdy tylko będą dostępne. W miarę możliwości należy korzystać ze środowisk testowych w celu walidacji działania aplikacji przed wdrożeniem poprawek do produkcji. gestión segura de secretos w GitHub Actions.
Równolegle z łataniem, zespoły ds. bezpieczeństwa mogą skanowanie w poszukiwaniu podatnych wersji i narażonych punktów końcowychNarzędzia od dostawców, takich jak Wiz, mogą pomóc w identyfikacji lokalizacji podatnych na ataki instancji React lub Next.js, natomiast skanery bezpieczeństwa sieci i inwentaryzacje zasobów mogą mapować, które usługi są dostępne z Internetu, a które są ograniczone do sieci wewnętrznych.
Na co obrońcy powinni zwrócić uwagę w najbliższym czasie
Ujawnienie luk CVE-2025-55182 i CVE-2025-66478 ilustruje znany schemat: krytyczny błąd w powszechnie używanym komponencie pojawia się na powierzchni, poprawki szybko trafiają, a następnie rozpoczyna się wyścig między obrońcami a atakującymi. W tym przypadku połączenie Wynik CVSS 10.0, nieuwierzytelniony RCE i narażenie na niewykonanie zobowiązania sprawia, że wyścig ten jest szczególnie intensywny.
Badacze ds. bezpieczeństwa przewidują, że następna faza obejmie szybka inżynieria wsteczna poprawek przez atakujących. Nawet bez opublikowania szczegółowego kodu proof-of-concept, porównanie starych i nowych wersji dostarcza doświadczonemu atakującemu wystarczających wskazówek, aby zrekonstruować podatną na ataki logikę.
Organizacje powinny spodziewać się wzrostu skanowanie punktów końcowych React i Next.js, a także bardziej dociekliwe żądania HTTP skierowane do funkcji serwera i adresów URL RSC. Systemy rejestrowania i monitorowania mogą tu odgrywać rolę: anomalie lub nieprawidłowe ładunki Flight, nieoczekiwane błędy podczas deserializacji i gwałtowne wzrosty liczby żądań do określonych punktów końcowych mogą być wczesnymi wskaźnikami próby wykorzystania luk w zabezpieczeniach, a także narzędzia do sprawdzania, takie jak… Współpracownik Burp pueden ayudar może odtwarzać wektory.
Niektórzy obrońcy również ponownie rozważają kontrola obrony w głąb wokół wdrożeń React. Może to obejmować kierowanie ruchu przez zapory sieciowe aplikacji internetowych, ograniczanie narażenia sieci na ataki usług wewnętrznych oraz egzekwowanie bardziej rygorystycznych konfiguracji uprawnień minimalnych uprawnień dla uprawnień środowiska wykonawczego aplikacji, aby w przypadku naruszenia bezpieczeństwa nie nastąpiło automatyczne przyznanie szerokiego dostępu.
Zaleca się, aby zespoły reagowania na incydenty: przygotuj się na potencjalne dochodzenia dotyczące tych CVEMoże to wymagać aktualizacji podręczników, zapewnienia, że odpowiednie dzienniki są przechowywane wystarczająco długo, aby umożliwić analizę podejrzanego zachowania, oraz nawiązania kontaktu z dostawcami usług lub dostawcami oprogramowania zabezpieczającego, którzy mogą udzielić pomocy w przypadku podejrzenia naruszenia bezpieczeństwa.
Ogólnie rzecz biorąc, przesłanie badaczy, dostawców i dostawców usług w chmurze jest spójne: chociaż nie potwierdzono jeszcze publicznie powszechnego wykorzystania tego zjawiska, warunki techniczne sprawiają, że jest to atrakcyjny cel, czekanie na wprowadzenie poprawki znacznie zwiększa okno ryzyka.
W przypadku krytycznych błędów umożliwiających zdalne wykonywanie kodu, takich jak CVE-2025-55182 w React i CVE-2025-66478 w Next.js, praktyczne wnioski są proste: zakładaj, że podatne punkty końcowe RSC zostaną zbadane, nadaj priorytet uaktualnieniom do wersji wzmocnionych i użyj dostępnych narzędzi do lokalizowania i ochrony narażonych instancjiW przypadku stosu stron internetowych, który w dużej mierze opiera się na React i powiązanych z nim frameworkach, szybka naprawa teraz prawdopodobnie się opłaci w postaci mniejszej liczby sytuacji awaryjnych w przyszłości.
