- CVE-2025-55182 i React og CVE-2025-66478 i Next.js muliggør uautoriseret fjernudførelse af kode via React Server Components Flight-protokollen.
- Problemet stammer fra usikker deserialisering af fremstillede RSC-nyttelaster, hvilket påvirker standardkonfigurationer i populære frameworks.
- Forskere rapporterer en udnyttelsessikkerhed på næsten 100 % og anslår, at omkring 39-40 % af cloudmiljøer indeholder sårbare instanser.
- Øjeblikkelige opgraderinger til forstærkede React- og Next.js-udgivelser er den eneste definitive afhjælpning; forsvarere bør også revidere ethvert RSC-aktiveret framework.
I løbet af de seneste par dage har JavaScript-økosystemet kæmpet med et par sikkerhedssårbarheder med maksimal alvorlighed i React og Next.js, der åbner døren for fjernudførelse af kode på berørte servere. Fejlene, der er tildelt som CVE-2025-55182 til React og CVE-2025-66478 For Next.js, fokus på hvordan React Server Components håndterer specialiseret netværkstrafik i den såkaldte Flight-protokol.
Fordi disse problemer påvirker standard framework-konfigurationer og kan udløses med intet andet end en håndlavet HTTP-anmodning, er de hurtigt steget til tops på mange sikkerhedsteams' patchlister. Leverandører, forskere og cloududbydere er nu enige om det samme budskab: patch med det samme, vurder eksponering og forbered dig på omfattende scannings- og udnyttelsesforsøg.
Hvad CVE-2025-55182 og CVE-2025-66478 egentlig er
Kernen i problemet er en fejl i react-server-pakke, den komponent, der driver React Server Components (RSC) og Flight-protokollen. I sårbare versioner accepterer serveren specielt formede RSC-nyttelaster og deserialiserer dem uden tilstrækkelig validering, hvilket tillader angriberkontrollerede data at forstyrre den logik, der kører på serveren.
Denne adfærd forvandler det, der burde være strukturerede data, til en køretøj til at udføre privilegeret JavaScript på backend. Når en HTTP-anmodning er rettet mod et RSC- eller Server Function-slutpunkt med en ondsindet Flight-nyttelast, kan den usikre deserialiseringssti misbruges til at opnå uautoriseret fjernkodeudførelse (RCE). Der kræves ingen forudgående adgang, legitimationsoplysninger eller brugerinteraktion.
React-siden af problemet spores som CVE-2025-55182, vurderet øverst på skalaen med en CVSS-score på 10.0. Fordi Next.js implementerer RSC og Flight-protokollen oven på disse primitiver, arver den den samme kerne-svaghed; den downstream-påvirkning er tildelt CVE-2025-66478 og har samme alvorlighedsgrad.
Sikkerhedsvejledninger beskriver fejlen som en sårbarhed i logisk deserialisering snarere end et klassisk hukommelsessikkerhedsproblem. Fejlen ligger i, hvordan nyttelast analyseres og har tillid til, ikke i håndteringen af lavbuffer. Ikke desto mindre er resultatet lige så alvorligt: en fjernangriber kan styre server-side-udførelsen.
Hvilke React- og Next.js-opsætninger er sårbare
Sårbarhedens konsekvenser React 19's server-side stak i flere almindeligt anvendte versioner. Vedligeholdere har udpeget udgivelser som 19.0, 19.1.0, 19.1.1 og 19.2.0 som sårbare for react-server pakke og dens Flight-protokolimplementering. De patchede grene distribueres som 19.0.1, 19.1.2 og 19.2.1, som introducerer hærdet deserialiseringslogik.
På rammesiden, Next.js er påvirket direkte fra startenEn typisk applikation genereret med create-next-app, bygget til produktion og implementeret med standardindstillinger, kan udnyttes uden ekstra kode tilføjet af udvikleren. Vercel, virksomheden bag Next.js, har derfor udsendt sin egen meddelelse under CVE-2025-66478 og udgivet opdaterede framework-versioner, der bruger de rette React-pakker.
Virkningen er ikke begrænset til Next.js alene. Enhver økosystemkomponent, der bundter eller tilsluttes React Server-komponenter og Flight-protokollen er sandsynligvis eksponeret. Dette omfatter blandt andet værktøjer og frameworks såsom:
- Next.js
- @vitejs/plugin-rsc (Vite RSC-plugin)
- @parcel/rsc (Parcel RSC-plugin)
- React Router RSC-forhåndsvisning
- RedwoodSDK / rwsdk
- Waku
Forskerhold har understreget, at Standardkonfigurationer er generelt i fareMed andre ord, selvom en udvikler ikke bevidst har aktiveret eksperimentelle flag eller usædvanlige indstillinger, kan deres implementering stadig være udnyttelig, hvis den bruger en berørt version af React Server Components.
Hvor let udnyttelse er, og hvorfor forsvarere er bekymrede
Det, der har alarmeret sikkerhedssamfundet, er lav barriere for udnyttelseFlere forskergrupper rapporterer, at det kun kræver at sende en specialudformet HTTP-anmodning til et tilgængeligt RSC- eller Server Function-slutpunkt for at kunne angribe disse fejl. Der er ikke behov for godkendelse, komplekse forudsætninger eller brugerinteraktion, hvilket gør scenariet særligt attraktivt for automatiserede angreb.
I kontrolleret testning har teams som Wiz Research bygget fungerende proof-of-concept exploits og observeret næsten 100% pålidelighed ved at udløse RCE på sårbare opsætninger. Selvom disse fulde nyttelaster ikke er blevet frigivet endnu, er der enighed om, at den underliggende adfærd er ligetil nok til, at andre kan rekonstruere fungerende exploits ved at studere de offentlige patches.
I betragtning af populariteten af React og Next.js mener flere eksperter, at Massescanning og bevæbning er kun et spørgsmål om tidDer findes tidlige sammenligninger med andre server-sidefejl med stor indflydelse, hvor udnyttelse steg, da tekniske detaljer og eksempelkode blev cirkuleret i undergrundsfællesskaber eller offentlige arkiver.
Forskerne fremhæver også bredden af potentielle målReact understøtter websteder og apps i store organisationer på tværs af sociale medier, e-handel, streaming, SaaS og mere. Frameworks som Next.js bruges i vid udstrækning til både interne og kundevendte applikationer, hvilket betyder, at sårbare instanser kan dukke op dybt inde i virksomhedsnetværk såvel som på offentligt vendte frontends.
På det tidspunkt, hvor mange af vejledningerne blev offentliggjort, var der ingen bekræftede rapporter om udnyttelse i naturenAnalytikere siger dog, at det er rimeligt at antage, at trusselsaktører allerede er i gang med at reverse engineere rettelserne og kortlægge, hvilke værter der er tilgængelige og fejlkonfigurerede.
Hvor udbredt eksponeringen er på tværs af cloudmiljøer
Adskillige datapunkter fra cloud-skala scanninger illustrerer problemets omfang. Trusselsjægere hos Wiz rapporterer, at omkring 39% af cloudmiljøer De analyserede indeholder forekomster af React eller Next.js, der kører versioner, som er sårbare overfor CVE-2025-55182 og/eller CVE-2025-66478. Andre opdelinger placerer tallet tættere på 40 %, når begge teknologier tælles sammen.
Hvis man specifikt ser på Next.js, fremstår selve frameworket omtrentligt 69% af miljøerne i deres datasæt. Af disse var en betydelig majoritet vært offentligt tilgængelige applikationer bygget på Next.js. Med andre ord antyder deres telemetri, at ca. 44% af alle cloud-miljøer have mindst én interneteksponeret Next.js-instans, uanset om den i øjeblikket er opdateret.
Denne kombination af høj implementeringstæthed og offentlig eksponering er præcis, hvad angribere leder efter, når de vælger, hvilke sårbarheder de vil investere indsats i. En enkelt angrebskæde kan genbruges i stor skala mod mange mål med lignende opsætninger, og automatiserede værktøjer kan scanne hele IP-områder for at finde ikke-patchede servere.
Nogle udbydere arbejder på at indsnævre eksplosionsradiusen. For eksempel har Google angivet, at standardaftryk af offentlige OS der bruges på Google Clouds Compute Engine, er ikke sårbare fra starten, selvom kunderne stadig skal revidere og opdatere alle applikationer, de implementerer oven på disse billeder.
Leverandører tilbyder Web Application Firewalls (WAF'er) deltager også i diskussionen. Cloudflare har for eksempel antydet, at deres WAF kan hjælpe med at beskytte nogle React-applikationer mod angrebsforsøg, når trafikken er fuldt ud dirigeret gennem tjenesten, selvom sådan beskyttelse bedst ses som et ekstra lag snarere end en erstatning for opdatering af den underliggende software.
Tidslinje, opdagelse og leverandørrespons
Hændelsesforløbet omkring CVE-2025-55182 og CVE-2025-66478 udfoldede sig hurtigt. Sikkerhedsforsker Lachlan Davidson identificerede problemet i den måde, React afkoder nyttelast, der er bundet til React Server Function-slutpunkter, og rapporterede det via Metas bug bounty-program i slutningen af november.
React, oprindeligt udviklet hos Meta og nu en hjørnesten i mange moderne webstacks, udviklede sig hurtigt, da rapporten blev bekræftet. Inden for cirka fire dage, udsendte React-teamet, i samarbejde med Meta, nødopdateringer til de berørte 19.x-linjer sammen med en sikkerhedsadvarsel, der opfordrede til øjeblikkelige opgraderinger.
Samme dag Vercel annoncerede sin egen rådgivning for Next.js under CVE-2025-66478. Framework-vedligeholderne udgav patched-udgivelser, vejledning til brugere og detaljer om, hvordan RSC-implementeringen i Next.js arver den sårbare adfærd fra Reacts serverbiblioteker.
Mange af de offentlige artikler er bevidst udelad trinvise angrebsdetaljer for nu. I stedet fokuserer de på at forklare risikoen, liste berørte komponenter og versioner og henvise brugerne til opdaterede builds. Målet er at give forsvarere tid til at implementere rettelser, samtidig med at mindre sofistikerede angribere bremses.
Branchefolk, herunder forskere fra virksomheder som watchTowr og Rapid7, har gentaget budskabet om, at dette er en et højprioriteret problem for alle, der kører React eller Next.js i produktion, og at vinduet, før udnyttelser dukker op offentligt, kan være kort.
Hvad holdene bør gøre lige nu
For organisationer, der bruger React Server Components, Next.js eller et af de RSC-aktiverede plugins og frameworks, er den klareste vejledning, at opgradering til forstærkede versioner er den eneste komplette afhjælpningDer er ingen konfigurationsknap, der sikkert neutraliserer fejlen, mens sårbare udgivelser forbliver aktive.
På React-siden betyder det at gå fra berørte 19.x-builds som 19.0, 19.1.0, 19.1.1 og 19.2.0 til 19.0.1, 19.1.2 eller 19.2.1, afhængigt af hvilken gren et projekt er fastgjort til. Disse versioner inkorporerer strengere kontroller omkring Flight-protokolnyttelast og lukker for den usikre deserialiseringsadfærd.
For Next.js-brugere er anbefalingen at opdatering til de opdaterede framework-udgivelser annonceret i Vercels meddelelse, der sikrer, at afhængighedstræet henter de faste React-serverpakker. Selv projekter, der ikke eksplicit bruger RSC i deres egen kode, kan stadig blive eksponeret, hvis frameworket aktiverer serverkomponenter under motorhjelmen.
Teams, der er afhængige af andre RSC-aktiverede stakke – herunder Redwood, Waku, React Router RSC-forhåndsvisningen og RSC-plugins til Vite og Parcel – bør overvåge officielle kanaler fra disse projekter. Mange af dem samler deres egne kopier af React-serverens runtime, så deres vedligeholdere udgiver specifikke opdateringsinstruktioner og versionsnumre, som de skal holde øje med.
For organisationer med store cloud-tilstedeværelser kan det være svært at vide, hvor alle de sårbare dele befinder sig. Nogle sikkerhedsleverandører, såsom Wiz, tilbyder præbyggede forespørgsler og rådgivning inden for deres platforme for at hjælpe kunder med at identificere berørte React- og Next.js-instanser på tværs af miljøer. Andre stiller detektionslogik og scanningsregler til rådighed, som interne sikkerhedsteams kan tilpasse.
Hvad dette betyder for det bredere webøkosystem
Fremkomsten af CVE-2025-55182 og CVE-2025-66478 giver anledning til en bredere diskussion om, hvordan JavaScript-frameworks på serversiden håndterer komplekse serialiseringsformaterRSC og Flight-protokollen er effektive værktøjer til at bygge moderne applikationer, men den samme fleksibilitet, der muliggør avancerede funktioner, kan også introducere subtile angrebsflader, hvis parsinglogikken ikke er omhyggeligt låst fast.
For udviklere er denne episode en påmindelse om, at At stole på standard framework-adfærd garanterer ikke sikkerhed og vigtigheden af at beskytte mod forsyningskædeangreb mod npmI dette tilfælde var almindelige standardopsætninger nok til at udsætte en applikation for uautoriseret RCE. At holde sig ajour med sikkerhedsrådgivning, fastlåse afhængigheder og hurtigt implementere opdateringer er ved at blive ufravigelige opgaver for teams, der leverer React- eller Next.js-baserede tjenester.
Fra et defensivt synspunkt bruger organisationer denne begivenhed til at gennemgå deres lagdelte beskyttelsesstrategierPatching er i højsædet, men mange undersøger også mulighederne for at stramme adgangskontrollerne til administrative eller interne slutpunkter, implementere WAF-regler for at opdage mistænkelig Flight-protokoltrafik og forbedre observerbarheden omkring serversidefejl, der kan indikere forsøg på udnyttelse.
Situationen fremhæver også, hvor meget af internettet nu afhænger af et relativt lille sæt af delte open source-komponenterEn enkelt fejl i et bredt anvendt bibliotek kan sprede sig gennem cloud-udbydere, SaaS-platforme og virksomhedsmiljøer på blot et par dage. Koordineret afsløring, hurtig leverandørrespons og klar kommunikation bliver afgørende, når så mange organisationer er berørt på én gang.
For nuværende er fokus på at få sårbare React- og Next.js-installationer over på rette udgivelser før udnyttelse bliver rutineDa forskere rapporterer næsten perfekt pålidelighed af angreb, standardkonfigurationer er sårbare, og en betydelig del af cloud-miljøer kører berørte versioner, er disse CVE'er hurtigt gået fra at være obskure protokoldetaljer til et presserende operationelt problem for teams, der vedligeholder moderne JavaScript-applikationer.
