Live data from Hacker News

RCE Vulnerability in React and Next.js

github.com

41–50 of 276 posts

Re: RCE Vulnerability in React and Next.js

#41
post #36

This vulnerability is basically the worst-case version of what people have been warning about since RSC/server actions were introduced. The server was deserializing untrusted input from the client directly into module+export name lookups, and then invoking whatever the client asked for (without verifying that metadata.name was an own property). return moduleExports[metadata.name] We can patch hasOwnProperty and tight…

For the layperson, does this mean this approach and everything that doesn't use it is not secure? Building a private, out of date repo doesn't seem great either.

Not quite. This isn’t saying React or Next.js are fundamentally insecure in general.

The problem is this specific "call whatever server code the client asks" pattern. Traditional APIs with defined endpoints don’t have that issue.

Re: RCE Vulnerability in React and Next.js

#42
post #24

till this day, I don't know the substantial benefits of React Server Components over say classically rendered html pages + using htmx ? mind you react in 2017 paid my rent. now cz of the complexity I refuse to work with react.

You can optionally enhance it and use React on the client. Doing that with HTMX is doable with "islands" but a bit more of a pain in the ass - and you'll struggle hard if you attempt to share client state across pages. Actually there are just a lot of little gotchas with the htmx approach

I mean it's a lot of complexity but ideally you shouldn't bring it in unless you actually need it. These solutions do solve real problems. The only issue is people try to use it everywhere. I don't use RSC, standard SPAs are fine for my projects and simpler

Re: RCE Vulnerability in React and Next.js

#43
post #25

> Projects hosted on Vercel benefit from platform-level protections that already block malicious request patterns associated with this issue. https://vercel.com/changelog/cve-2025-55182 > Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/

Same for Netlify: https://www.netlify.com/changelog/2025-12-03-react-security-...

and Deno Deploy/Subhosting: https://deno.com/blog/react-server-functions-rce

Re: RCE Vulnerability in React and Next.js

#45

Anyone know how Tanstack Start isn't affected?

TanStack Start has its own implementation of Server Functions: https://tanstack.com/start/latest/docs/framework/solid/guide.... It doesn't use React Server Functions, in part because it intends to be agnostic of the rendering framework (it currently supports React and Solid).

To be fair, they also haven't released (even experimental) RSC support yet, so maybe they lucked out on timing here.

Re: RCE Vulnerability in React and Next.js

#46
post #27
post #25

> Projects hosted on Vercel benefit from platform-level protections that already block malicious request patterns associated with this issue. https://vercel.com/changelog/cve-2025-55182 > Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/

We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue. We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.

Does AWS WAF have a mitigation in place?

Re: RCE Vulnerability in React and Next.js

#47
post #26
post #4

The CVE says the that flaw is in React Server Components, which implies strongly that this is a RCE on the backend (!!), not the client.

Where else would it be? What would an RCE of the client even mean?

it would be an RCE on your own machine :D

Re: RCE Vulnerability in React and Next.js

#48
post #29

Earlier quoted context omitted.

It sounds related to me. The react.dev blog post [1] says that the vulnerability is > a flaw in how React decodes payloads sent to React Server Function endpoints and the react.dev docs for React Server Functions [2] say that > Server Components can define Server Functions with the "use server" directive [...] Client Components can import Server Functions from files that use the "use server" directive So it certainly…

No. You cannot find all vulnerable code by grepping for ”use server”, for instance.

So that’s your “it’s not related to use server” argument?

That seems like it could be a quote from their hardening guide.

Post reply on HN