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

131–140 of 276 posts

Re: RCE Vulnerability in React and Next.js

#131

Post by pas »

morshu9001 wrote: post #108
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…

"React Server Functions allow a client to call a function on a server" Intentionally? That's a scary feature

used to wire up form submission in a type-safe way, so that part makes sense at least

whatever monstrosity hides underneath these nice high-level TypeScript frameworks to make all of it happen in JS, usually that's the worrying part

Re: RCE Vulnerability in React and Next.js

#133

Post by delifue »

tshaddox wrote: post #102
coffeecoders wrote: post #35

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…

To me it just looks like unacceptable carelessness, not an indictment of the alleged "lack of explicitness" versus something like gRPC. Explicit schemas aren't going to help you if you're so careless that, right at the last moment, you allow untrusted user input to reference anything whatsoever in the server's name space.

All mistakes can be blamed to "carelessness". This doesn't change the fact that some designs are more error-prone and more unsafe.

Re: RCE Vulnerability in React and Next.js

#135

Post by samdoesnothing »

switz wrote: post #38
dzonga wrote: 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.

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

Just because something is made possible and you can do it doesn't mean you should!

The criticism is that by allowing you to do something you shouldn't, there isn't any benefit to be had, even if that system allows you to do something you couldn't before.

Re: RCE Vulnerability in React and Next.js

#136

Post by morshu9001 »

apatheticonion wrote: post #127
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…

Does transpilation not cover this? That's how they did JSX.

Re: RCE Vulnerability in React and Next.js

#137

Post by morshu9001 »

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 tried it once, and it was like, you have to edit 5 files to add 1 button.

Re: RCE Vulnerability in React and Next.js

#139

Post by apatheticonion »

morshu9001 wrote: post #136
apatheticonion wrote: post #127

Earlier quoted context omitted.

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…

Does transpilation not cover this? That's how they did JSX.

Transpilation of anything other than jsx requires a complex toolchain with layers of things like LSPs, compilers, IDE plugins, bundler plugins, etc.

Frameworks that go that route typically activate this toolchain by defining a dedicated file extension (.vue, .svelte).

This custom toolchain (LSP, IDE plugins) presents a lot of overhead to project maintainers and makes it difficult to actually create a viable alternative to the JSX based ecosystem.

For instance both Vue and Svelte took years to support TypeScript, and their integrations were brittle and often incompatible with test tooling.

Angular used decorators in a very similar way to what I am describing here. It's a source code annotation in "valid" ecmascript that is compiled away by their custom compiler. Though decorators are now abandoned and Angular still requires a lot of custom tooling to work (e.g, try to build an Angular project with a custom rspack configuration).

JSX/TSX has preferential treatment in this regard as it's a macro that's built into tsc - no other framework has this advantage.

Re: RCE Vulnerability in React and Next.js

#140

Post by bdangubic »

morshu9001 wrote: post #137
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

I tried it once, and it was like, you have to edit 5 files to add 1 button.

same 5 files in every project at every company on earth
Post reply on HN