Live data from Hacker News

RCE Vulnerability in React and Next.js

github.com

231–240 of 276 posts

Re: RCE Vulnerability in React and Next.js

#231

Earlier quoted context omitted.

> React always hailed itself as the “just JS framework”, I've literally never heard someone say "React is just a JS framework". They've said React uses JSX over templates. And that React has introduced functional components. But never heard someone say what you're claiming. > but you can’t actually write regular JS in components since hooks have so many rules that bind the developer in a very specific way of writing…

I’ve heard, especially during the first few years when react was introduced, that you don’t need templating, compiler, or anything special to write react, “it’s just JS”. Of course you CAN write anything you want inside a component, but then it breaks, or has awful performance. To write components the proper way you can’t use any control flows with state management, you need to keep remembering which are the correct…

> that you don’t need templating, compiler, or anything special to write react, “it’s just JS”

This is still true. I don't currently use any of those things. And the existance of a compiler does imply you can't write Javascript. Totally different concepts. Also, pretty sure they had compiler plans for like years now.

> but then it breaks, or has awful performance.

You're gonna have to be more specific. I could repeat that sentence for every programming language/library on the planet and without specifics it would make sense.

> You can’t use if-else in JSX,

I don't need to use if-else in JSX to control flow. I can write if(condition) return html;

> which are hard to read, or using JS anomalies like having a condition expression return the last truthish evaluation.

See the sentence I just wrote before this. I can use if/else to control flow and return early without templating. How is that not ideal?

> And regarding signals, preact is using it and it doesn’t seem to break anything there.

It's not about literlaly "breaking" something. They could implement htem if they wanted to. It's about breaking the mental model.

In React, data flows down. That's a constraint, but not always a bad one. I know exactly where to look for data (up). With signals, that's throw out the window. And now, it's not just about what the component accepts via props/context (which again, is down) it now needs to turn itself on it's head.

I used Angular for years before React and I do not miss having things talking to each other throw multiple lateral levels.

> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state.

> Function of a state has a nice ring to it, but eventually this was solved a long time before react, every templating engine is a function of a state. The hard part is composing the state easily which react has never been able to achieve.

This is incredibly misleading (and wrong). Templates don't compose. And React is quite literlaly the king of composition.

It's starting to feel like you've never actually used React, but instead are basing your opinions on what you see other people say (who have also not used React).

Re: RCE Vulnerability in React and Next.js

#232

Earlier quoted context omitted.

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.

Yikes I didn't know that! I haven't actually used it yet hah.

For a bit of context, I come from writing blitters on 8 MHz Mac Plusses, so I have a blind spot around slowness. Basically, that nothing should ever be slow today with GHz computers. So most slowness isn't a conceptual flaw, but an inefficient implementation.

These alternative frameworks are generally small enough that it might be kind of fun to stress test them and contribute some performance improvements. Especially with AI, I really have no excuse anymore.

Edit: after pondering this for 2 seconds, I suspect that it's actually a problem with backend requests. It may have some synchronous behavior (which I want) or layout dependency issues that force it to wait until all responses have arrived before rendering. That's a harder problem, but not insurmountable. Also things like this irk me, because browsers largely solved progressive layout in the 1990s and we seem to have lost that knowledge.

Re: RCE Vulnerability in React and Next.js

#234

Earlier quoted context omitted.

You mean call whatever server action the client asks? I don't think having this vulnerability was intentional.

This is only really fine as long as you have extremely clearly, well defined actions. You need to verify that the request is sane, well-formed, and makes sense for the current context, at the very least.

You would probably need to do the same if you were writing back-end in Go or something. I don't see how that is conceptually different.

Re: RCE Vulnerability in React and Next.js

#235

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…

Indeed this is pretty bad.

The vast majority of developers do not update their frameworks to the latest version so this is something that will linger on for years. Particularly if you're on Next something-like-12 and there's breaking changes in order to go to 16 + patch.

OTOH this is great news for bad actors and pentesters.

Re: RCE Vulnerability in React and Next.js

#236
post #85

Earlier quoted context omitted.

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…

> I also had the same experience with the magic convention over configuration in Ruby. I'm not sure what this is a reference to? Is it actually about Rails?

Ya I used Rails on an aging project for about 6 months and there was so much magic behavior that we couldn't effectively trace through the code, so debugging even the simplest issue took days. Also the happy path mostly ran fine, but we couldn't answer even the simplest questions about the code or make estimations when something went wrong, because we couldn't isolate the source of truth in its convention-dominated codebase.

I come from a C++ background and mostly use PHP/Laravel today, and even though it does things less "efficiently" than the syntactic sugar in Ruby or low-level optimizations in .NET, I find that its lack of magic makes for much higher productivity in the long run. IMHO it feels like Ruby solves the easiest problems with sugar and then glosses over the hardest problems like they don't exist. So I just can't tell what problems it actually solves.

Generally, I think that cleverness was popular in the 2010s but has fallen out of fashion. A better pattern IMHO works more like Cordova or scripting in video games, where native plugins or a high-performance engine written in a language like Swift or Rust is driven by a scripting language like Javascript or Lua. Or better yet, driven declaratively by HTML or no-code media files that encode complex behavior like animations.

Of course all of this is going away with AI, and I anticipate atrociously poorly-written codebases that can't be managed by humans anymore. Like we might need pair programming just to take a crack at fixing something if the AI can't. I'm always wrong about this stuff though, so hopefully I'm wrong about this.

Re: RCE Vulnerability in React and Next.js

#237

Earlier quoted context omitted.

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

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.

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.

Re: RCE Vulnerability in React and Next.js

#238

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…

Indeed this is pretty bad. The vast majority of developers do not update their frameworks to the latest version so this is something that will linger on for years. Particularly if you're on Next something-like-12 and there's breaking changes in order to go to 16 + patch. OTOH this is great news for bad actors and pentesters.

This doesn't affect Next 12. Every single minor version of Next that's affected has a patch in the corresponding minor release cycle: https://nextjs.org/blog/CVE-2025-66478#fixed-versions

Re: RCE Vulnerability in React and Next.js

#239
post #205

Earlier quoted context omitted.

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

No one forced you to migrate immediately. (Also, non-value-adding work? You don't think the rewrite to TS did not bring any value? And thanks to that rewrite that app can be upgraded even today to Angular v21. And likely it'll be the case for many years.) React also went through a lot of churn. (Still does.) There's no magic optimal duration for keeping API stability. Not in general and not for specific projects. Eco…

> You don't think the rewrite to TS did not bring any value?

I mean, I don't really like TypeScript, and I never have. It's ugly, boilerplatey, and inelegant. I am not a fan.

So... no.

But, again, some battles you have to accept you've lost. TS is everywhere and there's not much getting away from it.

Re: RCE Vulnerability in React and Next.js

#240

Earlier quoted context omitted.

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

> Intentionally? It's RPC. Remote procedure calls. An approach that has made a comeback in the front-end space recently. There was tRPC; then react made a splash with the release of its server components; then other frameworks started emulating the approach. I think Svelte now has something similar with its "remote functions". And Solid has been working on something similar; so that SolidStart now has a "use server"…

RPC is normally more explicit than this, or when it's not, it's server2server stuff like in Erlang.
Post reply on HN