Top
Best
New

Posted by rayhaanj 10 hours ago

RCE Vulnerability in React and Next.js(github.com)
389 points | 120 commentspage 2
dzonga 8 hours ago|
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.

venturecruelty 1 hour ago||
React lets you inflate your salary.
leptons 7 hours ago|||
>now cz of the complexity I refuse to work with react.

What do you like to work with now?

TranquilMarmot 6 hours ago||
Right - you can NOT tell me that a sufficiently complex application using HTMX is easier to reason about than React. I've had to deal with a complex HTMX codebase and it is a nightmare.
ethanwillis 6 hours ago||
Right - you can NOT tell me that a sufficiently simple application using React is easier to reason about than HTMX. I've had to deal with a simple React codebase and it is a nightmare.

They don't address the exact same markets.

chatmasta 1 hour ago||
Yeah… one of them addresses a market populated by hundreds of thousands of developers with extensive professional experience in the framework, and the other addresses a niche of Python developers who refused to learn JavaScript until somebody hid it from them and called it hypermedia.
switz 7 hours ago|||
They lend you optionality of when and where you want your code to run. Plus it enables you to define the server/client network boundary where you see fit and cross that boundary seamlessly.

It's totally fine to say you don't understand why they have benefits, but it really irks me when people exclaim they have no value or exist just for complexity's sake. There's no system for web development that provides the developer with more grounded flexibility than RSCs. I wrote a blog post about this[0].

To answer your question, htmx solves this by leaning on the server immensely. It doesn't provide a complete client-side framework when you need it. RSCs allow both the server and the client to co-exist, simply composing between the two while maintaining the full power of each.

[0] https://saewitz.com/server-components-give-you-optionality

ptx 6 hours ago||
But is it a good idea to make it seamless when every crossing of the boundary has significant implications for security and performance? Maybe the seam should be made as simple and clear as possible instead.
paulhebert 6 hours ago||
Yep! It’s really hard to reason in Next about when things happen on the server vs client. This makes it harder to make things secure.

You can create clean separation in your code to make this easier to understand but it’s not well enforced by default.

AstroBen 7 hours ago|||
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

nonethewiser 8 hours ago||
easier/more reactivity, doesnt require your api responses to be text parsable to html
samdoesnothing 6 hours ago||
This is genuinely embarrassing for the Next.js and React teams. They were warned for years that their approach to server-client communication had risks, derided and ignored everyone who didn't provide unconditional praise, and now this.

I think their time as Javascript thought leaders is past due.

c-hendricks 7 hours ago||
Anyone know how Tanstack Start isn't affected?
serhalp 7 hours ago||
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.

dimitrisnl 7 hours ago||
They haven't implemented RSC yet.
bitbasher 9 hours ago||
It's almost like trying to magically wire up your frontend to the backend through magical functions is a bad idea.
division_by_0 5 hours ago||
This reminds me of the recent SvelteKit Remote Functions GH discussion:

> Even in systems that prevent server functions from being declared in client code (such as "use server" in React Server Components), experienced developers can be caught out. We prefer a design that emphasises the public nature of remote functions rather than the fact that they run on the server, and avoids any confusion around lexical scope. [0]

[0] https://github.com/sveltejs/kit/discussions/13897

beders 8 hours ago|||
One could get the impression that the only really really important non-functional requirement for such a thing is to absolutely ensure that you can only call the "good" functions with the "good" payload.
dizlexic 8 hours ago|||
ikr, no way this could have been predicted and warned about for months and months before now.
bossyTeacher 8 hours ago|||
CV driven development needs new ideas for resume padding regardless of whether the idea is good or bad. Then you get this
baiwl 9 hours ago||
Look at the money they’ve made to see if it was a bad idea or not.
bitbasher 9 hours ago||
I don't think money is a good proxy for idea quality. AI? Blockchain? Crime in general? Plenty of bad ideas make a whole lot of money.
dizlexic 8 hours ago||
Enron made boat loads.
javaking 7 hours ago||
I'm not a javascript person so I was trying to understand this. if i get it right this is basically a way to avoid writing backend APIs and manually calling them with fetch or axios as someone traditionally would do. The closest comparison my basic java backend brain can make is dynamically generating APIs at runtime using reflection, which is something I would never do... I'm lazy but not dumb
IceDane 6 hours ago||
Not even remotely similar.
wepple 6 hours ago|||
Care to elaborate on what it is like, then?
mvdtnz 6 hours ago|||
Actually he's more or less correct.
mvdtnz 6 hours ago||
There is a certain category of developers (a category that multiplied in size many times over around the same time as the boom in coding bootcamps, take that for what you will) who believe that there's virtue in running the same code on the client and the server, despite them being totally different paradigms with different needs. This kind of thing is the predictable result.
venturecruelty 1 hour ago|||
"You can run JavaScript on the frontend and the backend!" always struck me as the weakest marketing ever. I've been around the block, and which language the web application uses is hardly any sort of limiting factor in ease of development. (And ideally, your frontend has as little JavaScript as possible anyway.) There is very little that can't be programmed in a more web-friendly way, like POSTing forms and rendering HTML templates. Sure, I guess Google Maps can just be a fat application, but like... every eCommerce site doesn't need to be some big ball of React mud, I promise.
jacquesm 1 hour ago||
I think the main problem was that 'the standard' wasn't evolving fast enough to solve the bulk of the issues around input validation and UI building so we got this crap language that is powerful enough to hide a thousand footguns in a few lines of code. It will never be perfect so it will generate this kind of issue for the next century or so.

If instead, we would have gradually expanded the HTML standard without adding a fully functional programming language into the content stream we would have had better consistency between websites and applications and we would treat the browser like what it is: a content delivery mechanism, not an application programming platform. That's the core mistake as far as I'm concerned.

chasd00 5 hours ago||||
to be fair to bootcamp developers, i don't think they ever did "believe that there's virtue" in the setup, they were just told this is what you use and how you use it.
homebrewer 3 hours ago|||
It's just the latest take on what we had 20 years ago with .NET's WebForms and Java's JSF. Both of which tried to hide the network separation between client and server and were not fun to work with.

Those who don't learn history are bound to repeat it, and all that.

heldrida 6 hours ago||
Do you really need React Server Conponents or even Server Side Rendering?
henryfjordan 3 hours ago||
Before SSR (unless you were using PHP I guess) you had to ship a shell of a site with all the conditionals being decided only AFTER the browser has gotten all the HTML + JS pulled down. If you need to make any API calls, you've delayed rendering by hundreds of milliseconds or worse (round trip to your server)

With SSR, those round trips to the server could be down to single-digit milliseconds assuming your frontend server is in the same datacenter as your backend. Plus you send HTML that has actual content to be rendered right away.

A truly functional pageload can go from seconds to milliseconds, and you're transferring less data over the wire. Better all around at the expense of running a React Server instead of a static file host.

venturecruelty 1 hour ago|||
Yes. Web applications were impossible before these libraries.
jacquesm 1 hour ago||
No, they were not. They required a lot more round-trips to the server though, and rendering the results was a lot harder. But if you think of a browser as an intelligent terminal there is no reason why you couldn't run the application server side and display the UI locally, that's just a matter of defining some extra primitives. Graphical terminals were made first in the 60's or so.
quentindanjou 4 hours ago|||
It's very use-case dependent.

SSR can be a game-changer in domains like e-commerce. But completely useless for some other use case.

RSC advantages are a bit more complex to explain, because even a simple portfolio website would benefit from it. Contrary to the common belief created by long-term ReactJS dev, RSC simplifies a lot of the logic. Adapting existing code to RSC can be quite a mess and RSC is a big change of mindset for anybody used to ReactJS.

gloosx 5 hours ago||
Of course you do, in certain cases making less round-trips to the server is just straight more efficient
kachapopopow 6 hours ago||
static builds save the day.
ajross 9 hours ago||
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.
heisenbit 5 hours ago||
I suspect client developers are also affected at least to the extent that they need to explain this RCE to CVE driven management.
IceDane 6 hours ago|||
Bravo.
padjo 8 hours ago||
Where else would it be? What would an RCE of the client even mean?
cyptus 6 hours ago|||
it would be an RCE on your own machine :D
ajross 5 hours ago|||
The term is always ambiguous. But react is generally understood as a client library and client-side vulnerabilities are hardly a new thing. XSS exists as a whole subfield of study precisely because of the difficulty of keeping site code from getting fooled by malicious input.

Basically you're technically correct with your quip, but engaging in some pretty awful security analysis. IMHO most people reading this headline are not going to understand that they need to audit their server dependencies.

nickthegreek 9 hours ago||
dupe: https://news.ycombinator.com/item?id=46136067
anonymars 8 hours ago|
[flagged]
dizlexic 8 hours ago|
AHAHAHAHAHA, I'm sorry but we all knew this would happen.

I'm just laughing because I called it when they were in the "random idea x posts" about use server.

They'll fix it, but this was what we were warning about.

edit: downvote if you want, but I'm sorry React thinking they could shoehorn "use server" in and not create huge vulnerabilities was a pipe dream at best. I vote gross negligence because EVERYONE knew this was going to happen.

cluckindan 8 hours ago|
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 8 hours ago||
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 7 hours ago||
No. You cannot find all vulnerable code by grepping for ”use server”, for instance.
dizlexic 6 hours ago||
So that’s your “it’s not related to use server” argument?

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