Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Critical RCE Vulnerabilities in React and Next.js

wiz.io

Post reply on HN
Print view View original

51–60 of 92 posts

Re: Critical RCE Vulnerabilities in React and Next.js

#51

Post by _pdp_ »

internetter wrote: post #40
_pdp_ wrote: post #17

I don't have time to look into it right now (def later)! However, I was curious to see if github copilot can reverse engineer it based on the latest commits and seems that what it is saying aligns with both advisories. It pointed out that it has to do with circular reference handling which sounds to me something that can be easily overlooked. While this analysis might be completely off, the simple fact that I could g…

While I agree with your conclusion > While this analysis might be completely off, the simple fact that I could get even this information without much efforts is mind-boggling. With better setup it might be able to get more. This can essentially be rephrased as "I don't know if what the LLM said is true or not but the fact it may or may not be correct is amazing!"

I don't know what the LLM said is true for sure but based on my experience in the field sounds plausible. The only way to know is to verify it.

Btw, LLMs are already used in vulnerability discovery and exploit development.

Re: Critical RCE Vulnerabilities in React and Next.js

#52

Post by mmsc »

It seems like this vulnerability is yet another prototype pollution vulnerability.

There was a TC39 proposal a few years ago [0] that proposed to block the getting/setting of object prototypes using the bracket notation, which would have prevented this vulnerability.

At the moment, every single get/set with a square bracket, which uses untrusted data, needs to do some manual check to see whether variables contain "bad" keys like `__proto__`, `prototype,` `constructor`, and so on. This is incredibly annoying, and doesn't really fix the issue. It's possible also to freeze an object's prototype, but that causes other issues. It's also possible to use Object.create(null), and Object.hasOwn (also known as Object.prototype.hasOwnProperty), but again, this does not scale because it has to be done _every single time_.

Maybe it's time to revisit this from a language perspective, instead of continuous bandaid fixes for this language-specific vulnerability (a similar language-specific vulnerability exists in Python called class pollution, but it's .. extremely uncommon).

[0]: https://github.com/tc39/proposal-symbol-proto

Re: Critical RCE Vulnerabilities in React and Next.js

#53

Post by jfindper »

deathanatos wrote: post #45
jfindper wrote: post #36

Earlier quoted context omitted.

[flagged]

> It just comes off as condescending. Or, … they're just citing the source for the information, so that, in case you aren't aware as to where to find them, now you are. I think that's a doubly reasonable thing to do, given that your account is new, too.

>in case you aren't aware as to where to find them

The guidelines are linked at the bottom of every page, and directly underneath the comment box on new accounts. I also, perhaps surprisingly, know how to google "hn guidelines". Or ask chatgpt. Or reply "where's that piece of information from?".

>I think that's a doubly reasonable thing to do, given that your account is new, too.

People link the guidelines and, like, wikipedia to accounts that are 10 years old with 30,000 karma. It's a weird quirk of HN.

If you're talking to someone in real life, or professional emails, or whatever and you provide citations for commonly known things/definitions/etc.... you're being condescending.

Re: Critical RCE Vulnerabilities in React and Next.js

#54

Post by mmsc »

mmsc wrote: post #52

It seems like this vulnerability is yet another prototype pollution vulnerability. There was a TC39 proposal a few years ago [0] that proposed to block the getting/setting of object prototypes using the bracket notation, which would have prevented this vulnerability. At the moment, every single get/set with a square bracket, which uses untrusted data, needs to do some manual check to see whether variables contain "ba…

Note however, that proposal does not cover some other types of prototype pollution, such as:

  > let config = {};
  > Object.assign(config, JSON.parse('{"__proto__": {"isAdmin": true}}'));
  console.log({}.isAdmin); // true!
or:

  > console.log({}['constructor'] ? {}['constructor']('THIS MUST NOT BE EXPOSED') :  'pub')
  [String: 'THIS MUST NOT BE EXPOSED']

Re: Critical RCE Vulnerabilities in React and Next.js

#55

Post by NitpickLawyer »

nostrademons wrote: post #47
rvnx wrote: post #41

Earlier quoted context omitted.

Is it so important ? It's a mix of AI and human-written. It's normal nowadays and perfectly acceptable. + it is maybe 10% AI max, which seems to be for the structure / readability, and there is legit information under.

So smart quotes is now an LLM tell? You know that a lot of people write in word processors that automatically replace standard quotes with smart quotes (like, say, MS Word), and that these word processors can then export HTML straight into your block or preserve the smart quotes across a copy & paste? Several blog WYSIWYG editors will also directly insert them as well.

I think what they're saying is that having both in a document is the tell.

Re: Critical RCE Vulnerabilities in React and Next.js

#56

Post by karimf »

jfindper wrote: post #9
mmsc wrote: post #5

These wiz.io blog posts should be banned from HN; AFAICT, they're AI generated. Here's the original post with the details: https://react.dev/blog/2025/12/03/critical-security-vulnerab... - the vulnerability was not found by a Wiz employee at all, and the Wiz article (unlike the react.dev article) does not provide any meaningful technical information. The important part to know: - Even if your app does not implement a…

> AFAICT, they're AI generated. What is the "tell"? I'm not saying they are or aren't, but... people say this about literally everything now and it's typically some flimsy reasoning like "they used a bullet point". I don't see anything in particular that makes me think ai over a standard template some junior fills out. > the vulnerability was not found by a Wiz employee at all I've re-read the Wiz article a few times…

When I saw "WIZ Research - Critical Vulnerabilities in React and Next.js" on the big image banner, I immediately thought that Wiz found the vulnerability.

Re: Critical RCE Vulnerabilities in React and Next.js

#57

Post by aprilthird2021 »

rvnx wrote: post #41
jfindper wrote: post #30

Earlier quoted context omitted.

The authors have said it isn't. I can't believe saying a security vulnerability is "reproducible", "critical", etc. is a "classic tell of ai". I've used "reproducible" and "critical" in my deliverables since well before ai was a thing.

Is it so important ? It's a mix of AI and human-written. It's normal nowadays and perfectly acceptable. + it is maybe 10% AI max, which seems to be for the structure / readability, and there is legit information under.

Yeah it's important, it degrades trust in the reader if you use AI without disclosing or ensuring them the document was proofread.

Same way if you read an article full of typos you lose trust in it. Those tells of AI voice undermine the author and make the reader suspicious

Re: Critical RCE Vulnerabilities in React and Next.js

#58

Post by internetter »

_pdp_ wrote: post #51
internetter wrote: post #40

Earlier quoted context omitted.

While I agree with your conclusion > While this analysis might be completely off, the simple fact that I could get even this information without much efforts is mind-boggling. With better setup it might be able to get more. This can essentially be rephrased as "I don't know if what the LLM said is true or not but the fact it may or may not be correct is amazing!"

I don't know what the LLM said is true for sure but based on my experience in the field sounds plausible. The only way to know is to verify it. Btw, LLMs are already used in vulnerability discovery and exploit development.

> The only way to know is to verify it.

Which you should've done before making such statements imo.

Re: Critical RCE Vulnerabilities in React and Next.js

#59

Post by jfindper »

karimf wrote: post #56
jfindper wrote: post #9

Earlier quoted context omitted.

> AFAICT, they're AI generated. What is the "tell"? I'm not saying they are or aren't, but... people say this about literally everything now and it's typically some flimsy reasoning like "they used a bullet point". I don't see anything in particular that makes me think ai over a standard template some junior fills out. > the vulnerability was not found by a Wiz employee at all I've re-read the Wiz article a few times…

When I saw "WIZ Research - Critical Vulnerabilities in React and Next.js" on the big image banner, I immediately thought that Wiz found the vulnerability.

When Reuters has an article that says "Reuters Business - Interest rates going up", do you think Reuters made the interest rates go up themselves or that they are reporting on the interest rates?

Re: Critical RCE Vulnerabilities in React and Next.js

#60

Post by tempaccount420 »

cyberax wrote: post #49
tempaccount420 wrote: post #39

Basically, JavaScript should not be running on servers. Vulnerabilities caused by shoddy JS are a lot more impactful to a server since multiple users will be served by the same runtime instance.

It's not JavaScript by itself. It's unsafe coding practices that blend production and development code. The bug here is in the hot reloading code. It should not be enabled anywhere but on developers' machines.

It's never JavaScript itself, but somehow it's almost always JavaScript code...
Post reply on HN