RCE Vulnerability in React and Next.js

Posted by rayhaanj 12/3/2025

RCE Vulnerability in React and Next.js(github.com)

628 points | 258 commentspage 4

udev4096 12/4/2025|

I am betting it would be exploited in the wild in the next few days, buckle up!

dacodaco1 12/5/2025||

[dead]

dacodaco1 12/5/2025||

[dead]

mohamed_altyb 12/4/2025||

[dead]

dizlexic 12/3/2025||

[flagged]

cluckindan 12/3/2025|

This is not related to ”use server”. That’s used to mark Server Actions / Server Functions, and it is not necessarily used in files with Server Components.

ptx 12/3/2025||

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 sounds like the vulnerability is related to React Server Functions which are related to "use server".

[1] https://react.dev/blog/2025/12/03/critical-security-vulnerab...

[2] https://react.dev/reference/rsc/server-functions

cluckindan 12/3/2025||

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

dizlexic 12/3/2025|||

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

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

ptx 12/4/2025||||

I think the top-level comment was criticizing the entire feature (server functions) enabled by "use server". The vulnerability is in this feature, so (as I understand it) you're correct that grepping for "use server" won't find the vulnerable code, but if there was no such thing as "use server" the vulnerability wouldn't exist.

jazzypants 12/4/2025|||

I'm sorry, but you're incorrect. That is genuinely how this CVE works. All (and only) code with "use server" was vulnerable.

vinnymac 12/4/2025||

The official blog post disagrees.

> Even if your app does not implement any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.

jazzypants 12/4/2025||

Oops, yeah. My bad, you're right. It makes sense that any flight server that is capable of interpreting server functions would be vulnerable whether the codebase used them or not. It's an issue in the transport mechanism and not the actual RPC implementation.

spoctrial 12/4/2025||

POC: https://github.com/Ashwesker/Blackash-CVE-2025-55182/

danabramov 12/4/2025|

This doesn't look real to me. I don't believe a `_next/static/chunks/react-flight` endpoint even exists.

ashishb 12/4/2025|

JavaScript is meant to be run in a browser. Not on a backend server [1].

Those who are choosing JS for the backend are irresponsible stewards of their customers' data.

1- https://ashishb.net/tech/javascript/

tills13 12/4/2025||

Sorry you feel that way.

odie5533 12/4/2025||

TypeScript is really nice though.

ashishb 12/4/2025|||

> TypeScript is really nice though.

Even if that's true, it is irrelevant.

  - You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ...
  - You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources.
  - You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible changes, combined with outrageous security issues

steve_adams_86 12/4/2025||

If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits.

Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use.

Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.

ashishb 12/4/2025||

> If you use deno you can consume dependencies much more securely

How would Deno have prevented the RCE issue with React+Next.js?

steve_adams_86 12/5/2025||

It wouldn't. I was responding to your concerns about the TypeScript ecosystem more generally.

You avoid the RCE by recognizing that React—and more recently Vercel's—management is a bit of a tire fire, and you should choose better tools with more responsible maintainers.

Part of what bothers me about this situation is that React appears to be a view library, and to many people using it that is what it functions as... But it's now a framework which extends well beyond the browser and entails all kinds of security risks that aren't intuitive at a glance, at all. A lot of people using Next probably have no idea about the security implications of the framework or how React fits into them. It's a mess.

Deno definitely can't fix that.

int_19h 12/4/2025|||

... if your baseline is JavaScript.