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

241–250 of 276 posts

Re: RCE Vulnerability in React and Next.js

#241

Post by morshu9001 »

throwup238 wrote: post #198
azangru wrote: post #194

Earlier quoted context omitted.

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

> An approach that has made a comeback in the front-end space recently. It wasn’t really a “comeback,” RPC never lost popularity. We just called them “REST” APIs that were a barely disguised adhoc JSON RPC format with a few CRUD verbs tacked on for routing requests.

If people even bothered with the CRUD verbs instead of making everything POST

Re: RCE Vulnerability in React and Next.js

#243

Post by morshu9001 »

apatheticonion wrote: post #139
morshu9001 wrote: post #136

Earlier quoted context omitted.

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

This only applies to TS, not JS, right? Cause afaik JSX isn't getting any special treatment from babel, but TSX has tsc support like you said.

Re: RCE Vulnerability in React and Next.js

#244

Post by azangru »

pas wrote: post #205
bartread wrote: post #128

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…

> Google throws products under the bus, but not so much OSS projects.

It abandoned the Material Design web components project, which, I think, attracted some Polymer people.

Speaking of Polymer, it has evolved into Lit; but I understand there is no more support for that project from Google. Lit has joined the OpenJS foundation to stay afloat. The Googlers that used to work on Lit, and on Material Design web components have mostly left.

Also, remember the Workbox project? A simple setup for service workers? It's barely alive.

Re: RCE Vulnerability in React and Next.js

#245

Post by vanwal_j »

Rauchg wrote: post #27
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/

We collaborated with many industry partners to proactively deploy mitigations due to the severity of the issue. We still strongly recommend everyone to upgrade their Next, React, and other React meta-frameworks (peer)dependencies immediately.

Does this include any provider that does not fall under USA CLOUD Act? This vulnerability disclosure timeline is a nightmare for us Europeans, it was fully disclosed yesterday late afternoon for us and I can trace back attack logs that happend during the night. I expect some downfalls from this.

I genuinely believe Next.JS is a great framework, but as an European developer working on software that should not touch anything related to CLOUD Act you're just telling me that Next.JS and React, despite being OSS, is not made for me anymore.

Re: RCE Vulnerability in React and Next.js

#246

Post by j45 »

jeroenhd wrote: post #221
j45 wrote: post #37

Earlier quoted context omitted.

The subjects of theses types of posts should report the CVSS severity as 10.0 so the PR speak can't simply deflect to what needs to be done.

Unfortunately, CVSS scores are gamified hard. Companies pay more money in bug bounty programs, so there's an incentive for bug bounty hunters to talk up the impact of their discovery. Especially the CVSS v3 calculation can produce some unexpected super high or super low scores. While scores are a good way to bring this stuff to people's attention, I wouldn't use them to enforce business processes. There's a good chan…

It’s possible to create a scoring system based on actual root cause analysis and impact scores.

Surprised there isn’t more talk about a solution like this or something and more downplaying CVSS.

Downplaying CVSS alone can smell a little like PR talk even however unintentional.

Re: RCE Vulnerability in React and Next.js

#247

Post by steve_adams_86 »

z3ratul163071 wrote: post #158

there can be no React RCE. if it is on the frontend, it is a browser RCE. if it is on the backend, then, as in this case it is a Next.js RCE.

You're wrong, but this is one of the unsettling things about the vulnerability and what React has become. Intuitively, you'd think a view library can't have RCE vulnerabilities like this. But that's not what React is anymore.

Re: RCE Vulnerability in React and Next.js

#248

Post by steve_adams_86 »

ashishb wrote: post #165
odie5533 wrote: post #152

Earlier quoted context omitted.

TypeScript is really nice though.

> TypeScript is really nice though. Even if that's true, it is irrelevant. - You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ... - You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources. - You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible…

If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits.

Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use.

Bun also allows for this but it feels a bit more tacked-on and less like an early architectural decision based around security concerns.

Re: RCE Vulnerability in React and Next.js

#249

Post by paulhebert »

odie5533 wrote: post #148
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

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

This is an odd philosophy.

There are lots of things in life that may be “good enough.”

I prefer the things that are better than that

Re: RCE Vulnerability in React and Next.js

#250

Post by ashishb »

steve_adams_86 wrote: post #248
ashishb wrote: post #165

Earlier quoted context omitted.

> TypeScript is really nice though. Even if that's true, it is irrelevant. - You need to decide package manager and everyone has their favorite one: npm, yarn, bun, pnpm ... - You need to depend on npmjs.com for dependencies, which has an unusually high number of malicious packages compared to other dependency sources. - You need to use some framework like Next.js, which itself is a cesspool of backward-incompatible…

If you use deno you can consume dependencies much more securely from arbitrary URLs, such as your own. You can also set permissions for the runtime, though that might not save you depending on the severity of exploits. Arguably the safest approach is to embed all dependencies in your source, and vet all of them for each release. But I'm glad deno lets me choose which registry I use. Bun also allows for this but it fe…

> If you use deno you can consume dependencies much more securely

How would Deno have prevented the RCE issue with React+Next.js?

Post reply on HN