Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

RCE Vulnerability in React and Next.js

github.com

Post reply on HN
Print view View original

121–130 of 276 posts

Re: RCE Vulnerability in React and Next.js

#121

Post by venturecruelty »

mvdtnz wrote: post #67
javaking wrote: post #32

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

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.

"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.

Re: RCE Vulnerability in React and Next.js

#122

Post by jacquesm »

ivanjermakov wrote: post #104
_el1s7 wrote: post #50

Next.js/RSC has become the new PHP :) I guess now we'll see more bots scanning websites for "/_next" path rather than "/wp-content".

Inevitable when the line between the client and the server is blurred this much. RCE in a UI library is not a phrase you hear often.

Maybe one day we'll look back at JavaScript and conclude it was a gigantic mistake ship unaudited executable code to a few billion people every day.

Re: RCE Vulnerability in React and Next.js

#124

Post by jacquesm »

venturecruelty wrote: post #121
mvdtnz wrote: post #67

Earlier quoted context omitted.

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.

"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…

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.

Re: RCE Vulnerability in React and Next.js

#125

Post by jacquesm »

venturecruelty wrote: post #123
punkbit wrote: post #65

Do you really need React Server Conponents or even Server Side Rendering?

Yes. Web applications were impossible before these libraries.

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.

Re: RCE Vulnerability in React and Next.js

#126

Post by symaxian »

halflife wrote: post #61
paulhebert wrote: post #56

Earlier quoted context omitted.

I wish React wasn’t the “default” framework. I agree that the developer experience provided by the compiler model used in Svelte and React is much nicer to work with

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated. And what they DO add? Only things that improve dev exp

I'll second that Angular provides a great experience these days, but they have definitely had substantial API changes within the last few years: standalone components, swapping WebPack for esbuild, the new control-flow syntax, the new unit-test runner, etc...

Re: RCE Vulnerability in React and Next.js

#127

Post by apatheticonion »

halflife wrote: post #54

Why does the react development team keeps investing their time on confusing features that only reinvent the wheel and cause more problems than solve? What does server components do so much better than SSR? What minute performance gain is achieved more than client side rendering? Why won’t they invest more on solving the developer experience that took a nosedive when hooks were introduced? They finally added a compile…

I agree. Incoming hot take.

IMO, a big part of it is the lack of competition (in approach) exacerbated by the inability to provide alternatives due to technical/syntactical limitations of JavaScript itself.

Vue, Svelte, Angular, Ripple - anything other than React-y JSX based frameworks require custom compilers, custom file-types and custom LSPs/extensions to work with.

React/JSX frameworks have preferential treatment with pre-processors essentially baking in a crude compile time macro for JSX transformations.

Rust solved this by having a macro system that facilitated language expansion without external pre-processors - e.g. Yew and Leptos implement Vue-like and React-like patterns, including support for JSX and HTML templating natively inside standard .rs files, with standard testing tools and standard LSP support;

https://github.com/leptos-rs/leptos/blob/main/examples/count...

https://github.com/yewstack/yew/blob/master/examples/counter...

So either the ECMAScript folks figure out a way to have standardized runtime & compilable userland language extensions (e.g. macros) or WASM paves the way for languages better suited to the task to take over.

Neither of these cases are likely, however, so the web world is likely destined to remain unergonomic, overly complex and slow - at least for the next 5 - 10 years.

Re: RCE Vulnerability in React and Next.js

#128

Post by bartread »

azangru wrote: post #84
halflife wrote: post #61

Earlier quoted context omitted.

IMO angular provides such a great experience developing. They had minimal API changes in the last 10 years, and every project looks almost the same since it’s so opinionated. And what they DO add? Only things that improve dev exp

> They had minimal API changes in the last 10 years The 1 to 2 transition was one hell of a burn though; people are probably still smarting...

You aren’t wrong. I basically stopped using any OSS code backed by Google as a result.

I’d pushed Angular over React[0] for a massive project, and it worked well, but the migration to Angular 2 when it came created a huge amount of non-value-adding work.

Never again.

I don’t even really want to build anything against Gemini, despite how good it is, because I don’t trust Google not to do another rug pull.

[0] I’ve never enjoyed JSX/TSX syntax, nor appreciated the mix of markup with code, but I’ve subsequently learned to live with it.

Re: RCE Vulnerability in React and Next.js

#129

Post by Jnr »

karimf wrote: 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/

I patched and rebuilt what I could and added custom Crowdsec WAF rules for this, in case I missed something.

Re: RCE Vulnerability in React and Next.js

#130

Post by ejpir »

WatchDog wrote: post #116
ejpir wrote: post #79

I'm fumbled around a bit and got it working, but not entirely sure if this is how it really works: have a look at https://github.com/ejpir/CVE-2025-55182-poc

I ran your exploit-rce-v4.js with and without the patched react-server-dom-webpack, and both of them executed the RCE. So I don't think this mechanism is exactly correct, can you demo it with an actual nextjs project, instead of your mock server?

I'v updated the code, try it now with server-realistic.js:

1. npm start 2. npm run exploit

Post reply on HN