Kritiek lek in React Server Components, ontwikkelaar vraagt direct te updaten

Er zit een kritiek lek in recente versies van React Server Components van Meta. Het bedrijf vraagt gebruikers van de software om onmiddellijk te updaten naar een gepatchte versie. Het lek krijgt een score van 10/10.

Het gaat om CVE 2025-55182 en die maakt het uitvoeren van willekeurige code op het systeem van het slachtoffer mogelijk, meldt Meta. Het bedrijf wil niet veel zeggen over de details van het lek, maar een aanvaller kan met een kwaadaardig HTTP-request naar een React Server-endpoint ervoor zorgen dat die willekeurige code kan uitvoeren op die server.

De kwetsbaarheid zit in versies 19.0, 19.1.0, 19.1.1, en 19.2.0 van React Server Components. Meta raadt gebruikers aan om goed te checken of ze dat gebruiken, omdat ook andere toepassingen als bijvoorbeeld Next.js gebruik maken van React Server Components. De patch zit in versie 19.0.1, 19.1.2 en 19.2.1, zo zegt het bedrijf.

Reacties (36)

[Stetsed]

Ik denk persoonlijk dat dit zelfs een groter probleem is dan de eerdere Log4Shell. Op het gebied van classificatie is het hetzelfde, namelijk Remote, Geen user interaction of authorization en het geeft arbitrary code execution. En het probleem is dat dit over het hele web wordt gebruikt, het is echt gigantisch als ik het me goed herinner de meest gebruikte web framework op het internet op dit moment

Dit gaat interessant worden… ik heb zelf vanochtend een trivy scan over het hele homelab gedraaid, gelukkig draai ik geen applicaties die er door getast worden maar nog steeds dit is echt gevaarlijk.

Ook is het belangrijk te noteren dat dit NIET een app is die jij installeert, maar het is een app die op de server kant draait het zit ook in de server framework. Ik zou zeggen voor degene die niet NPM gebruikt maar het via package manager doet om tijdelijk apps stop te zetten, of naar de NPM versie te stappen tot er een update is.

Hiernaast zag ik op HN bijvoorbeeld dat mensen referenceren naar bepaalde PoC’s, deze zijn NIET accuraat, en vaak doen ze all gevaarlijke dingen om een fout te creëren, er is nog geen officiële PoC en wordt zoals in het artikel gezegd express op dit moment niet vrij gemaakt.

[Reactie gewijzigd door Stetsed op 4 december 2025 16:10]

[Coolstart]

Ik denk persoonlijk dat dit zelfs een groter probleem is dan de eerdere Log4Shell.

Nee: Log4Shell is gelijkaardig maar die exploid was veel (100x) explosiever omdat er meer onbeheerde en oude servers Java draaien die ook effectief kwetsbaar waren.

Dit is nog steeds heel erg maar minder erg omdat er simpelweg minder React servers zijn.Ook zijn oude onbeheerde React servers veilig.

De Impactperiode nu is ‘beperkt’ tot 1jaar dus de nieuwere apps die al React 19 + Server Components gebruikten. Alle ouderen servers zijn veilig. Bij Log4Shell ging het over 8 jaar! Dus alles van de afgelopen 8 jaar was toen vatbaar.

Veel Java servers die vatbaar waren voor Log4Shell draaide lokaal en was met het internet verbonden. Je begrijpt het verschil.

Ook kan je is dit door devs makkelijker patchen dan Log4shell omdat react vooral op cloud servers draait en dus direct door admins te patchen valt.

Log4Shell draaide dus op heel erg veel (ook oudere) systemen (niet in de cloud) die je ook handmatig moest patchen. Veel bedrijven wisten zelfs niet dat ze ergens Log4j gebruikten en het zat ook in end of life systemen die sowieso geen updates meer kregen. Dus die gaten bleven open = 100x erger.

Ook is elke server die achter een beveiligingssysteem zoals Cloadflare al beschermd. Dat ging bijna instant.

Wat niet wil zeggen dat er geen malware op uw server zit. Dus je gaat sowieso alles nog moeten scannen.

Sowieso kunnen eindgebruikers niets doen omdat de aanval uitsluitend op de server-side zit. Dus al wie zich zorgen maakt: De exploit kan geen code uitvoeren op uw telefoon of PC. Client side is dus gevrijwaard. Dus als je op een linkt klikt nemen ze uw PC niet over.

Maar react servers die gehackt zijn, zijn wel gevaarlijk. Het kan dus best zijn dat een recente react web-service zonder updates nog steeds data kan stelen.

[Reactie gewijzigd door Coolstart op 4 december 2025 22:10]

[R4gnax]

De exploit kan geen code uitvoeren op uw telefoon of PC. Client side is dus gevrijwaard. Dus als je op een linkt klikt nemen ze uw PC niet over.

Met dat soort stellige beweringen zou ik oppassen.
Als men middels een RCE in React Server Components code in de Node.js sandbox uit kan voeren, betekent dat dat de applicatie aangepast kan worden om malware uit te gaan serveren die op zijn beurt kan gaan proberen uit de browser sandbox te ontsnappen en willekeurige code op de PC van bezoekers te draaien.

Dit type aan elkaar knopen van exploits in ketens is gemeengoed.

[joost00719]

Veel HTTP vulnerabilities zijn tegen te houden met een reverse proxy. Nginx heeft een module "Block Common Exploits" dat dingen zoals Path Traversal (../../../../../../../../../etc/passwd) tegen houdt.

Ik weet niet precies hoe gecompliceerd deze attack is. Maar misschien is dit ook op deze manier te mitigaten.

[sticman]

Als het voor thuis gebruik is kan je ook een mesh VPN service gebruiken zoals Tailscale. Bv al mijn web apps zitten achter een reverse proxy. Enkel die reverse proxy is verbonden met het Tailnet. Voordeel is dat je dus ook geen poorten moet openzetten en de apps niet publiek beschikbaar zijn.

Je moet dan wel elk client device verbinden met dat Tailnet. Maar hier heb ik nog geen enkel probleem mee ondervonden.

[!GN!T!ON]

Heb dezelfde opzet, met authentik aan de apps gekoppeld voor 2FA en uniforme accounts, en apps die geen SAML/OIDC ondersteunen via de proxy met forward auth. Aantal dingen zoals Jellyfin, Subsonic, etc deel ik met familie / vrienden door de proxy te delen naar hun eigen tailnet, blijft dat ook mooi gescheiden van elkaar. In mijn public dns heb ik een wildcard dns record die naar het tailnet IP van mijn proxy verwijst. Zo lekt er niks naar 'buiten', kennissen kunnen normale URL's gebruiken (zolang ze verbonden zijn met hun tailnet) en eigen apparaten schakelen zo automatisch om van tailscale naar lokaal als ik met de thuis-wifi verbind.

[latka]

Klinkt als complexer dan een client-cert uitgeven voor die kenissen die je toegang wilt verlenen die ze vervolgens installeren.

[!GN!T!ON]

Voor 1–2 technische mensen met een beperkt aantal apparaten is mTLS met client-certs prima te doen. Maar voor een groep veelal niet IT ingestelde famile/vrienden met:

• telefoons
• tablets
• laptops
• smart TV / Chromecast / whatever
• Waar er constant apparaten bijkomen en weggaan
• Je mensen niet elke keer via een half uur schermdelen door cert-install flows wilt loodsen
• Makkelijk toegang intrekken of delen (ook naar hún eigen tailnet)

Dan wordt client-cert distributie en lifecycle ineens:

• Cert genereren
• Veilig distribueren
• Installatie uitleggen op iOS / Android / Windows / macOS / GoogleTV / AppleTV en ga maar door (elk anders, vaak verstopt, soms extra stappen nodig om het ook echt voor de browser te laten gelden)
• Bij sleutelcompromis / verlies:
  • revoken
  • nieuwe pushen
  • weer iedereen lastigvallen
• Geen SSO, geen 2FA, geen gebruiksvriendelijke “ik log gewoon in met mijn account” UX

Tailscale daarentegen:

• Eén keer: “installeer Tailscale, log in met <provider>”
• Klaar. Nieuw apparaat? Zelfde stappen, geen werk voor mij, geen wachten voor hun.
• Toegang intrekken = ACL aanpassen of share terugtrekken
• Je kunt netjes per user / per tailnet segmenteren
• Combineert lekker met (toch al bestaande) Authentik + reverse proxy + wildcard DNS setup

Het moet voor mij ook nog beheersbaar blijven :p

[latka]

Op die chromecast moet je ook wel even pielen met side-loading denk ik zo. Anyhoe, cert sturen. ww. mailen. Veel success met dubbelklikken en het certificaat is geladen is mijn ervaring. Als je je root-cert verliest:tsja, dan ben je even zuur. Als een client-cert verloren is: revoken idd (en publiceren op de crl). Key-management/CA functies zitten o.a. in OPNSense op een redelijke wijze ingebakken en het is redelijk eenvoudig klikken in mijn ervaring.

Grootste voordeel wat ik gemerkt heb: geen software nodig en geen cloud-afhankelijkheid naar een 3e partij (tailscale control plane). Maar ieder zijn ding.

[!GN!T!ON]

Voor een paar laptops/pc’s in een redelijk gecontroleerde omgeving ben ik het met je eens: mTLS + client-certs is prima te doen en zeker mooi spul.

Mijn scenario is alleen wat anders:
– familie/vrienden die niet IT-vast zijn
– phones, tablets, laptops, smart-tv’s / Chromecast-achtige dingen
– devices die continu bijkomen/wegvallen
– ik wil niet bij elk nieuw apparaat weer een halve avond meekijken om ergens verstopt in iOS/Android/GoogleTV een cert-store goed in te richten.

In dat soort setups merk ik dat “even een client-cert mailen en dubbelklikken” in de praktijk niet bestaat, zeker niet op tv-kastjes en telefoons (nog los van het feit dat ik cert + wachtwoord via mail verspreiden security-wise een beetje meh vind ). En als er een cert kwijt of gelekt is, mag ik de boel weer uitzoeken, revoken, opnieuw uitrollen en iedereen opnieuw lastigvallen.

Met Tailscale is het voor hun: app installeren → inloggen → klaar. Voor mij: ACL/shares beheren en eventueel Authentik erachter voor 2FA/SSO. Ja, dat brengt een cloud-control-plane met zich mee, maar het houdt het voor mij wél beheersbaar zonder full-time PKI-beheerderschap en mocht het ooit stoppen dan zou ik altijd nog naar headscale kunnen gaan, plus het feit dat ik zo nul poorten open hoef te zetten vind ik persoonlijk ook prettig.

Voor mijn use case is dat simpelweg de betere trade-off. Voor jouw gebruik lijkt mTLS/mutual certs inderdaad logischer – daar verschillen onze scenario’s gewoon.

[Reactie gewijzigd door !GN!T!ON op 5 december 2025 00:13]

[latka]

Grootste voordeel wat ik gemerkt heb is dat het over alle kanalen werkt: niemand blokkeert poort 443 (tailscale kan over port 443, maar doet liever UDP).

Ik snap alleen je punt over 'intrekken en iedereen lastigvallen: ik geef individuen een certficaat, niet 1 client-cert voor iedereen. Caddy als reverse proxy (UI tegenwoordig ook in OPNSense) en je hebt een alles-in-1 oplossen (firewall, CA en reverse proxy) met een Web-UI die super eenvoudig is. Geen client-software nodig en certificaten worden (gelukkig) nog steeds breed ondersteunt (ook op tv kastjes ;-) Maar inderdaad, het is vaak ook een kwestie van wat je al kent bij dit soort oplossingen, want het is eens in de 2 maanden weer eens wat doen en dan is alles weggezakt als je niet oppast.

Zal tailscale eens bekijken, maar als het inloggen met username/password dan weet ik niet of ik dat een strak plan vind ;-)

[keejoz]

Ik doe dit met ZeroTier (Free) met een CF reverse proxy om mijn home assistant via mijn telefoon te kunnen bereiken.


Draait ondertussen al jaren vlekkeloos.

[Reactie gewijzigd door keejoz op 4 december 2025 18:23]

[Streetshadow]

https://pangolin.net/ is ook een interessante alternatief.

[Stetsed]

Hier heb je waarschijnlijk een WAF voor nodig als het complexer wordt dan wat alleen in de request staat bijvoorbeeld als het een manipulated body is.

[Hydranet]

Mod-Security houd dat soort dingen volgens mij ook tegen.

[RobbieB]

Een beetje fatsoenlijke WAF is voldoende om hier tegen te beschermen, zie ook: https://blog.cloudflare.com/waf-rules-react-vulnerability/

en verder gewoon patchen. Dit is echt niet vergelijkbaar met log4j.

[Argantonis]

De Log4j bug was wel iets moeilijker en conditioneler te misbruiken. Het zal hiermee vooral wel loslopen omdat React Sever Components aanzienlijk minder wordt gebruikt

[hello123456]

Indien je gebruik maakt van Next.JS, dan zijn de volgende versies kwetsbaar:

• Next.js 15.x
• Next.js 16.x
• Next.js 14.3.0-canary.77 and later canary releases - Note: Enkel dus canary releases later dan dit, de stable van 14.x is niet getroffen.

Versies waarin het is opgelost:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

Verder: Next.js 13.x, Next.js 14.x stable, Pages Router applications, en the Edge Runtime bevatten de kwetsbaarheid niet.

Meer info: https://nextjs.org/blog/CVE-2025-66478

Mocht je applicatie achter Cloudflare zitten, dan ben je automatisch beschermd door Cloudflare: https://blog.cloudflare.com/waf-rules-react-vulnerability/

[Reactie gewijzigd door hello123456 op 4 december 2025 16:17]

[Aloy]

Voor de NextJS gebruikers onder ons, de getroffen versies zijn:

• 15.x
• 16.x
• 14.3.0-canary.77 en nieuwere canary (unstable) releases

De gefixte versies zijn:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

https://nextjs.org/blog/CVE-2025-66478

[Luchtbakker]

Vreemd genoeg als ik apt update & apt upgrade op debian uitvoer, krijg ik All packages are up to date, ondanks dat ik react server components gebruik.

Meer mensen last van?

[ZoidbergNL]

ehh.. zijn dat geen npm packages? Ik gebruik react niet zelf

[nassau]

Ik zou zelf ook NPM gebruiken maar ubuntu bijvoorbeeld levert ze ook via apt

[nassau]

Zit nog wel eens vertraging in .deb packages qua beschikbaarheid. Ook een beetje afhankelijk van welke distro release je gebruikt.

Als je via NPM installeert/update zou je direct de laatste versies moeten krijgen.

[Reactie gewijzigd door nassau op 4 december 2025 15:59]

[Cyw00d]

Je bent in de war tussen het package management systeem van linux en die van nodejs.

Zorg dat je react update via je node package manager.

[TheNephilim]

Het zijn inderdaad packages van NPM, dus je zult waarschijnlijk je applicatie moeten bijwerken (npm update && npm run build oid.).

[latka]

Welke package had je verwacht dan (debian gebruiker hier)

[Gamebuster]

Het zijn npm packages, je moet je node project updaten. Check je package-lock of yarn.lock of je de relevante packages gebruikt.

Om het snel te checken, kan je Roo Code gebruiken in je project(en) als volgt. Roo Code zal dan automatisch relevante lock-files checken.

[quote]
This vulnerability was disclosed as CVE-2025-55182 and is rated CVSS 10.0.

The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of:

react-server-dom-webpack
react-server-dom-parcel
react-server-dom-turbopack

are my apps safe?
[/quote]

[Reactie gewijzigd door Gamebuster op 4 december 2025 22:40]

[telenut]

Probeer nu maar eens te achterhalen op welke servers in het netwerk dit allemaal staat ( als die niet allemaal in eigen beheer zijn).

[Guyon]

In een beetje moderne organisatie (en als je RSC/next.js gebruikt is dat waarschijnlijk het geval) gaat het om applicaties die onder gitops uitgerold zijn. Je kan vrij eenvoudig een vulnerability scanner (bijv. Dependabot van Github) op je organisatie loslaten die kijkt welke repositories een kwetsbare dependency bevatten. Laat de betreffende teams de applicatie updaten en uitrollen, en je bent in no time weer veilig.

[telenut]

Ik hoop dat Rapid7 of Microsoft Defender hetzelfde doet dan :-)

[Mellow Jack]

Als je beetje fatsoenlijke scanner draait vind je het vrij snel. Meestal worden die dingen relatief snel geupdate met signatures om embedded implementaties te vinden

[R4gnax]

Probeer nu maar eens te achterhalen op welke servers in het netwerk dit allemaal staat ( als die niet allemaal in eigen beheer zijn).

Wat dacht je van alle lokale ontwikkelaarssystemen?

De development runtime zal dezelfde fout bevatten en dus zal elke ontwikkelmachine die een getroffen versie van één van de getroffen implementaties van React Server Components lokaal draait om aan lukraak enig project te werken, ook vatbaar zijn terwijl de applicatie draaiende is.

Dat is dankzij de ondersteuning voor hot reloading en live code aanpassen terwijl de applicatie draaiende is, waarschijnlijk praktisch de hele kantoordag. Enige wat er dan nodig is, is een HTTP verzoek richting de juiste poort (veelal standaard ingesteld vanuit een project template!) op localhost en de rapen zijn gaar.

En het is héél normaal voor een ontwikkelaar om gelijktijdig in de browser andere tabs dan de applicatie zelf open te hebben staan om bijv. framework documentatie te lezen, of zaken op te zoeken in fora of issue trackers. Een gecompromiteerde advertentie op één van die pagina's en je kunt de bok zijn.

[Reactie gewijzigd door R4gnax op 6 december 2025 11:32]

[mr.DJ95]

Dit kan potentieel net zo groot worden als, of zelfs groter dan Log4Shell (Log4J).

Als ik het goed begrijp zijn de React server components onderdeel van software waardoor je niet alleen afhankelijk bent van Meta om het lek in React te dichten maar ook van alle leveranciers/uitgegevers/ontwikkelaars die gebruik maken van React.

[demianmonteverd]

De javascript wereld zit meer achter cloudflare en andere third party providers zoals vercel, dus hopelijk valt het mee. Het is qua gemak voor de aanvaller super gemakkelijk dit lek. Erg gevaarlijk.

[TheAncientDovah]

Ik kreeg inderdaad ook een update voor Umami (self-hosted analytics). Umami gebruikt Next.js, en die gebruiken React Server Components. Heerlijk al die transitieve dependencies...

[Hardfreak]

Voor de geïntereseerden, de AWS WAF voorziet ook in de nodige bescherming voor dit issue: https://aws.amazon.com/security/security-bulletins/AWS-2025-030/

The default version (1.24) of the AWS WAF "AWSManagedRulesKnownBadInputsRuleSet" now includes the updated rule for this issue.