TL; DR
React2Shell (CVE-2025-55182) skaper en kritisk RCE-risiko tvers React Server-komponenter (RSC) og rammeverk som bygger dem inn, inkludert Next.jsFordi sårbarheten ligger inni RSC serialiserings- og deserialiseringslaget, angripere kan sende en utformet HTTP-forespørsel og utløse uautorisert ekstern kodekjøring, selv når team kjører standard rammeverkkonfigurasjoner. Next.js søknader får størst eksponering fordi de godtar og behandler Reagerer fly nyttelaster over HTTP som standard.
Feilen påvirker flere versjoner av React-serverpakker, og angripere trenger ikke tilpasset applikasjonslogikk for å utnytte den. Sikkerhetsforskere viser nesten 100 % pålitelighet, og tidlige skanninger avslører at mange skymiljøer kjører sårbare Next.js tilfeller. Lagene må oppdatere umiddelbart og validere hele økosystemet deres for å krympe React2Shell (CVE-2025-55182) RCE-risiko.
En kritisk sårbarhet rapportert gjennom Metas bug bounty-program 29. november har utløst umiddelbare responser på tvers av JavaScript-økosystemet.
Dedikert CVE-2025-55182, offentliggjort 3. desember, nå omtalt som React2Shell er en sårbarhet med maksimal alvorlighetsgrad som påvirker React Server-komponenter sammen med rammeverk som innlemmer dem. I utgangspunktet ble en separat Next.js-sårbarhetsidentifikator (CVE-2025-66478) tildelt, men NVD konsoliderte den senere inn i den primære React CVE som en duplikatoppføring.
Det underliggende problemet er det samme, usikker håndtering av serialiserte RSC-nyttelaster som kan utløses via en HTTP-forespørsel. Dette åpner døren for at en ondsinnet aktør kan sende en manipulert HTTP-forespørsel som resulterer i at vilkårlig JavaScript kjører på serveren etter å ha blitt deserialisert av React.
CVE-2025-55182 Oversikt
React Server-komponenter er dypt integrert i moderne rammeverk, og i mange tilfeller er de aktivert som standard. På grunn av dette kan applikasjoner bli utsatt for React2Shell (CVE-2025-55182) selv om de aldri eksplisitt definerer et Server Function-endepunkt. RSC-implementeringen er fortsatt til stede, og det alene er nok til å aktivere sårbare kodebaner og skape en betydelig RCE-risiko.
Feilen stammer fra måten React Flight-protokollenl behandler visse strukturerte nyttelaster. Eldre versjoner forsøkte å gå objektbaner som er oppgitt i nyttelasten uten å bekrefte at strukturen var gyldig eller forventet. En angriper kunne manipulere denne prosessen og til slutt nå kodekjøring på serveren. Ingen autentisering, ingen spesiell konfigurasjon og ingen appspesifikk logikk kreves. Siden problemet eksisterer i standardkonfigurasjoner, standard distribusjoner eksponeres uten at det kreves noen uvanlige forhold.
Utnyttelse skjer når angripere sender ondsinnede HTTP POST-forespørsler som misbruker «vm.runInThisContext”-mekanismen gjennom serverhandlinger. Selv om React ikke direkte eksponerer det sårbare endepunktet, gjør Next.js det, og skaper dermed en ekte ekstern angrepsvektor.
Next.js aksepterer Flight-nyttelaster fra enhver forespørsel, behandler dem uten skikkelig validering og sender dem til Reacts deserialiseringsprogram. Systemet behandler disse eksterne inndataene som klarerte, slik at angripere kan oppnå ekstern kjøring av kode gjennom offentlig tilgjengelige endepunkter med fulle Node.js-prosessrettigheter på målserveren.
Alvorlighetsgraden øker betydelig fordi standardkonfigurasjoner fortsatt er sårbare for React2Shell (CVE-2025-55182) og det resulterende RCE-risiko. A standard Next.js-applikasjonen du lager med create-next-app eksponerer seg selv uten å kreve noen tilpasset kode eller konfigurasjonsendringer. Sikkerhetsforskere bekrefter nesten 100 % pålitelighet for utnyttelse og rapporterer at 39 % av skymiljøer kjører sårbare instanser, mens 44 % av alle miljøer kjører offentlig eksponerte Next.js-applikasjoner som er påvirket av React2Shell.
Forstå eksponering for React2Shell
De sårbare versjonene strekker seg over flere utgivelser:
| Komponent | Berørte versjoner |
|---|---|
| react-server-dom-webpack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-pakke | 19.0, 19.1.0, 19.1.1, 19.2.0 |
| react-server-dom-turbopack | 19.0, 19.1.0, 19.1.1, 19.2.0 |
Fordi mange rammeverk har RSC-støtte i kjernen, arver applikasjoner ofte den sårbare koden uten å være klar over det. Ethvert rammeverk eller pakkepakke som sender disse pakkene, kan eksponere applikasjonen for React2Shell (CVE-2025-55182) og dens RCE-risiko. Det inkluderer:
- Next.js (App-ruter)
- Forhåndsvisning av React Router RSC
- Vite RSC-plugin
- Parcel RSC-plugin
- Redwood SDK
- Waku
- Expo
Next.js er spesielt påvirket fordi den bruker RSC-relaterte endepunkter over HTTP som standard. Versjoner som begynner med 14.3.0 canary-bygg, sammen med de fleste 15.x og tidlig 16.x utgivelser, inneholder den sårbare implementeringen. Alle som kjører canary 14.3.0-kanarifugl.77 eller senere bør gå tilbake til stabil 14.x grenen inntil en oppdatert canary-versjon er publisert.
Oppdaterte Next.js-versjoner inkludere:
| Komponent | Oppdaterte versjoner |
|---|---|
| Next.js | 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7 |
Offentlige PoC-er og pålitelig deteksjon
Etter at sårbarheten ble avslørt, begynte en rekke antatte konseptbevis å sirkulere. Mange av dem var enten unøyaktige eller basert på feilaktige antagelser. Den opprinnelige forfatteren av sårbarheten, Lachlan Davidson, bekreftet offentlig den react2shell at GitHub-poC-ene som sirkulerer ikke samsvarer med utnyttelsen som deles privat med React/Next.js-vedlikeholdere og oppga hans egen PoC.
Et stort problem med tidlige offentlige forsøk er at de ikke klarer å erkjenne at utnyttelse lykkes mot standard Next.js-distribusjoner uten at det kreves at spesifikk applikasjonslogikk eller serversidefunksjoner er til stede.
Sikkerhetsforskere fra flere organisasjoner har understreket at det å oppdage sårbarheten krever mer enn bare å identifisere om RSC er til stede. Assetnotes team publiserte en pålitelig deteksjonsmetode og en skanner i stand til å bekrefte problemet uten å bruke noen form for utnyttelseslogikk. Metasploit vil snart ha en tilgjengelig utnyttelse også for denne sårbarheten.
Deteksjonsmetoden utnytter hvordan React Server håndterer objektegenskapsreferanser ved hjelp av kolonskilletegn i ReactFlightClientConfigBundlerWebpack.js/requireModule() funksjon. Når sårbare versjoner behandler en spesialstrukturert flerdelt nyttelast som prøver å krysse ikke-eksisterende nestede objektbaner, utløser de forutsigbare feilresponser. En diagnostisk forespørsel sender et referansemønster som `$1:a:a` paret med et tomt objekt. Sårbare implementeringer prøver å løse dette som nestet egenskapstilgang på en udefinert verdi, noe som resulterer i et unntak. Serveren returnerer en 500-status med et særegent feilsammendragsmønster i svarinnholdet.
export function requireModule<T>(metadata: ClientReference<T>): T { let moduleExports = __webpack_require__(metadata[ID]); if (isAsyncImport(metadata)) { if (typeof moduleExports.then !== 'function') { // This wasn't a promise after all. } else if (moduleExports.status === 'fulfilled') { // This Promise should've been instrumented by preloadModule. moduleExports = moduleExports.value; } else { throw moduleExports.reason; } } if (metadata[NAME] === '*') { // This is a placeholder value that represents that the caller imported this // as a CommonJS module as is. return moduleExports; } if (metadata[NAME] === '') { // This is a placeholder value that represents that the caller accessed the // default property of this if it was an ESM interop module. return moduleExports.__esModule ? moduleExports.default : moduleExports; } return moduleExports[metadata[NAME]]; } Umiddelbare tiltak for organisasjoner som står overfor React2Shell (CVE-2025-55182) og RCE-risikoen
Gjennomfør en omfattende skanning av kodebasen og distribuerte applikasjoner for å finne sårbare pakkeversjoner. Vær spesielt oppmerksom på direkte React-serverpakkeavhengigheter, RSC-implementeringer på rammeverksnivå (Next.js, Waku, Redwood osv.), applikasjoner bygget med `create-next-app` eller lignende stillasverktøy og containeriserte applikasjoner som kan inneholde utdaterte basisbilder.
Analyse av programvarekomposisjon (SCA) verktøy som Xygenis SCA kan automatisk oppdage berørte avhengigheter i hele programvarebeholdningen din.
Oppdater umiddelbart:
Oppdatering til oppdaterte versjoner som React (19.0.1, 19.1.2, 19.2.1), Next.js (15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7) og eventuelle rammeverkspakker som inkluderer RSC. Disse oppdateringene introduserer streng validering for håndtering av RSC-nyttelast og forhindrer den usikre egenskapsreferansen som muliggjør utnyttelse.
Automatiserte utbedringsverktøy, som for eksempel Xygenis automatiske utbedringsfunksjon, kan akselerere prosessen på tvers av store kodebaser.
Implementer midlertidige WAF-beskyttelser:
Mens oppdateringer sprer seg gjennom distribusjonen din pipeline, aktiver regler for brannmur for nettapplikasjoner for umiddelbar beskyttelse. Store skyleverandører har gitt ut regelsett for nødstilfeller, CloudFlareAutomatisk beskyttelse for alle nivåer når React-trafikk brukes via proxy, samt AWS, Akamai, Fastly, Google Cloud ha lignende forsvarsregler tilgjengelig Aktiver disse kontrollene umiddelbart for å opprette et beskyttende lag i overgangsperioden.
Overvåk mistenkelig HTTP-trafikk:
Konfigurer logging og varsling for indikatorer på utnyttelsesforsøk: Misdannede eller uventede RSC Flight-protokollnyttelaster, uvanlige mønstre med 500 feil på RSC-endepunkter, POST-forespørsler med mistenkelige `Next-Action`- eller `Next-Router-State-Tree`-overskrifter, gjentatte forespørsler til `/_next/`-baner med flerdelte nyttelaster
Bekreft programvarens materialliste:
Mange rammeverk samler RSC-avhengigheter transparent, noe som gjør dem usynlige i avhengighetsgjennomganger på overflatenivå. Undersøk hele SBOM for å sikre at: Ingen transitive avhengigheter på sårbare React-serverpakker gjenstår, at rammeverksoppdateringer ikke utilsiktet har introdusert eldre RSC-implementeringer.
Lukke Thoughts
React2Shell er blant de mest alvorlige sårbarhetene i JavaScript-økosystemet de siste årene, ikke fordi utnyttelsen er kompleks, men fordi RSC kjører så dypt inn i dagens verktøy. Nå som oppdateringer er tilgjengelige på tvers av økosystemet, må teamene presse oppgraderinger inn i produksjon så raskt som mulig.
Hvis applikasjonen din bruker Reacts serverfunksjoner, enten direkte eller indirekte, må du behandle denne sårbarheten som en toppprioritetsrettelse.
