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

161–170 of 276 posts

Re: RCE Vulnerability in React and Next.js

#161

Post by orkj »

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

very interesting to read.

However, if I am reading this correctly, your PoC falls in the category described here: https://react2shell.com/

> Anything that requires the developer to have explicitly exposed dangerous functionality to the client is not a valid PoC. Common examples we've seen in supposed "PoCs" are vm#runInThisContext, child_process#exec, and fs#writeFile.

> This would only be exploitable if you had consciously chosen to let clients invoke these, which would be dangerous no matter what. The genuine vulnerability does not have this constraint. In Next.js, the list of server functions is managed for you, and does not contain these.

Context: This is from Lachlan Davidson, the reporter of the vulnerability

Re: RCE Vulnerability in React and Next.js

#163

Post by rand17 »

danabramov wrote: post #63
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…

Server Components is not really related to SSR. I like to think of Server Components as componentized BFF ("backend for frontend") layer. Each piece of UI has some associated "API" with it (whether REST endpoints, GraphQL, RPC, or what have you). Server Components let you express the dependency between the "backend piece" and the "frontend piece" as an import, instead of as a `fetch` (client calling server) or a (ser…

You either die a hero or live long enough to see yourself become the villain. The amount of time I've spent debugging other PRs (and mine) around hooks is just unruly, then React turned its attention to the server, something that I (most of us? we?) never ever asked for; but I guess that's what Meta, a company of cancer needs. I sure don't need it. Never have I imagined during the last 15 years that I'll be happy to say I'm using the mountain of enterprise spaghetti called Angular, but now I am. For years I hoped I'll be able to get back to React projects one day; that hope is long gone.

Re: RCE Vulnerability in React and Next.js

#164

Post by jondwillis »

slopfighter wrote: post #156
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

Your lump of AI-generated slop has detracted from the response to an important vulnerability. Congratulations. Your PoC is invalid and you should delete it.

HMU, proud owner of slopcop.ai and have been itching to put it to good use.

Re: RCE Vulnerability in React and Next.js

#165

Post by ashishb »

odie5533 wrote: post #152
ashishb wrote: post #145

JavaScript is meant to be run in a browser. Not on a backend server [1]. Those who are choosing JS for the backend are irresponsible stewards of their customers' data. 1- https://ashishb.net/tech/javascript/

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 changes, combined with outrageous security issues

Re: RCE Vulnerability in React and Next.js

#167

Post by Copenjin »

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…

> The server was deserializing untrusted input from the client directly into

If I had a dollar for every time a serious vulnerability that started like this was discovered in the last 30 years...

Re: RCE Vulnerability in React and Next.js

#169

Post by antonstihl »

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.

The Next.js server runs React modules. While one may argue that Next.js shouldn't bundle vulnerable dependencies, React does have modules for server-side runtimes these days and should be accountable.
Post reply on HN