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

141–150 of 276 posts

Re: RCE Vulnerability in React and Next.js

#141

Post by TZubiri »

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…

Because Facebook has a budget for R&D, which works out to several salaries, and React is one of the biggest technical assets they have, so it's someone full time job to develop features and new versions of React to increase the moat and stock value of Meta.

It works out because it keeps a workforce of React Developers on their feet, learning about the new features, rather than doing other stuff. It's like SaSS for developers, only instead of paying a monthly subscription in cash, you have to pay a monthly subscription in man-hours.

Re: RCE Vulnerability in React and Next.js

#142

Post by csomar »

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…

They are taking care of the customers. The customers are front-end dev with little experience in servers, back-end and networking. So they want to run some code that changes state without having to deal with all of that infra and complexity. Preferably while remaining in the "React state". That is the attraction of Nextjs and RSC.

Re: RCE Vulnerability in React and Next.js

#143

Post by bdangubic »

chatmasta wrote: post #114
ethanwillis wrote: post #60

Earlier quoted context omitted.

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.

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.

100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)

Re: RCE Vulnerability in React and Next.js

#144

Post by chatmasta »

bdangubic wrote: post #143
chatmasta wrote: post #114

Earlier quoted context omitted.

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.

100’s of thousands used to use php too :) most developers (roughly 97.56% are terrible/incompetent so going with the herd should tell you you are on the wrong train :)

Thousands of developers still use PHP… and even more users… Wordpress (43% of web), Facebook (billions of users), Wikipedia (billions of users)…. all PHP.

htmx is a a toy, mildly amusing to play with, built on an insecure foundation that bypasses basic browser security controls and hands a blob of JavaScript to a bunch of backend developers who can’t be bothered to learn it because they think they know better…

No serious project uses htmx and none ever will, because it becomes an unmaintainable mess by the third developer and second year of development.

Re: RCE Vulnerability in React and Next.js

#147

Post by mary-ext »

filearts wrote: post #19
embedding-shape wrote: post #6

From Facebook/Meta: https://www.facebook.com/security/advisories/cve-2025-55182 > A pre-authentication remote code execution vulnerability exists in React Server Components versions 19.0.0, 19.1.0, 19.1.1, and 19.2.0 including the following packages: react-server-dom-parcel, react-server-dom-turbopack, and react-server-dom-webpack. The vulnerable code unsafely deserializes payloads from HTTP requests to Server Functi…

Given that the fix appears to be to look for own properties, the attack was likely to reference prototype level module properties or the gift-that-keeps-giving the that is __proto__.

not `__proto__` but likely `constructor`, if you access `({}).constructor` you'd get the Object constructor, then if you access `.constructor` on that you'd get the Function constructor

the one problem I haven't understood is how it manages to perform a second call afterwards, as only being able to call Function constructor doesn't really amount to much (still a serious problem though)

Re: RCE Vulnerability in React and Next.js

#148

Post by odie5533 »

paulhebert wrote: post #56
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 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

React is good enough, so it's very hard to come up with a strong case to use anything else.

Re: RCE Vulnerability in React and Next.js

#149

Post by odie5533 »

zackmorris wrote: post #80
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 couldn't agree more. I'll probably switch from React to something like ArrowJS in my personal work: https://www.arrow-js.com/docs/ It makes it easy to have a central JSON-like state object representing what's on the page, then have components watch that for changes and re-render. That avoids the opaqueness of Redux and promise chains, which can be difficult to examine and debug (unless we add browser extensions for…

For a single page of HTML, ArrowJS's site loads really slow. I sat for almost a full second on just the header showing.

Re: RCE Vulnerability in React and Next.js

#150

Post by [deleted] »

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/

[deleted]
Post reply on HN