Critical RCE Vulnerabilities in React and Next.js | Hacker News Reader

Critical RCE Vulnerabilities in React and Next.js

wiz.io

134 pointsgonepivoting77 comments

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 any React Server Function endpoints it may still be vulnerable if your app supports React Server Components.

- The vulnerability is present in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of: react-server-dom-webpack, react-server-dom-parcel, react-server-dom-turbopack

- Some React frameworks and bundlers depended on, had peer dependencies for, or included the vulnerable React packages. The following React frameworks & bundlers are affected: next, react-router, waku, @parcel/rsc, @vitejs/plugin-rsc, and rwsdk.

>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. Maybe I'm just dumb, but where did Wiz claim to have found this vulnerability?

the tl;dr definitely came out of an llm

presentation and formatting aside the constant attempts to manufacture legitimacy and signal urgency are a classic tell. everything is "near-100%" reliable, urgent, critical, reproducible, catastrophic. siren emoji

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.

>Because author says it, it doesn't mean that it is true.

And because random HNer says it is ai doesn't mean it is ai.

>But still, is it so important?

Not to me, no. If the information is useful/entertaining/etc., I don't really care. But having to read "it's ai!" comments on literally every article/blog posted for the next 10 years is going to be super annoying. Especially if the reasoning provided is "they used the word critical". At least you pointed to something kind of interesting with the quotation marks (although, certainly not definitive of anything), rather than saying some extremely common word = ai.

Absolutely, anyway you'll have critical judgment to make your own opinion.

What bothers me about the Wiz post is why they want to hide this HTTP request is actually not helpful in terms of security.

On the plus side, they help getting the word out there, so at least something.

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.

The document doesn't have both in it. It's possible it was edited, but someone else in the thread posted the archive.org original version, and it also doesn't have smart quotes:

https://web.archive.org/web/20251203162416/https://www.wiz.i...

(Note also that you can end up with mismatched quotes if you paste in a segment of text from some other source that uses them, which is pretty common in journalism for a fast-changing story.)

https://archive.md/2025.12.03-165833/https://www.wiz.io/blog...

Mismatched smart quotes are visible in this archive.

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

>Same way if you read an article full of typos you lose trust in it

Not for long! This seems like this will soon be the only way to put something on the internet without people rabidly saying its ai (at least for a few weeks, until people start prompting for typos to be included).

Hackernews' submission guidelines clearly state: "Please submit the original source. If a post reports on something found on another site, submit the latter." [0]

The Wiz post has significantly changed since it was first published (and how it looked when first posted to HN), FYI -- see [1]. When it was published, it was a summary of the React announcement, and was somehow longer than the original and yet provided less useful information than the original.

In any case, the "tell" is the syntactic structure (as Chomsky would say) and certain phrases used in the post.

[0]: https://news.ycombinator.com/newsguidelines.html

[1]: https://web.archive.org/web/20251203162416/https://www.wiz.i...

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?

Reuters isn’t a bank. Wiz is a security company so they have a greater responsibility to distinguish between their own original work and discoveries made by other researchers.

They do that by saying "we discovered this" when they discover it.

Hey mmsc, first of all - the blogs are not AI Generated!

Second of all, the blog did add more information

"In our experimentation, exploitation of this vulnerability had high fidelity, with a near 100% success rate and can be leveraged to a full remote code execution. The attack vector is unauthenticated and remote, requiring only a specially crafted HTTP request to the target server. It affects the default configuration of popular frameworks. "

In the end - if it helped spreading the news about this risk so teams can fix them faster, then this is our end-goal with these blog posts : )

There is some value:

> The vulnerability exists in the default configuration of affected applications

Can be inferred from the react blog but isn't really explicit

> According to Wiz data, 39% of cloud environments have instances vulnerable to CVE-2025-55182 and/or CVE-2025-66478.

Numbers!

>> According to Wiz data, 39% of cloud environments have instances vulnerable to CVE-2025-55182 and/or CVE-2025-66478.

> Numbers!

I do not see how such numbers are valuable to people reading this post, as the first indication of the existence of this vulnerability.

Hey, researcher from Wiz here - we definitely didn't discover these vulns and all the credit goes to Lachlan Davidson. We have been investigating these vulns throughout the day and decided not to disclose the full extent of our conclusions or release a working exploit until more people get a chance to patch this (and as I mentioned in another comment, exploitation works out-of-the-box so you definitely should patch ASAP).

I can't even read the Wiz post, it just plays an unrelated full screen video at me after flickering a couple of times.

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

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']

For the first case, it doesn't work because Object.assign() does not copy the prototype or non-enumerable properties, see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

That being said, it _will_ happen if you use your own merge() function like the TC-39 proposal demonstrates, but its because you are using the [] syntax to implement it which can affect __proto__

Side note, JSON.parse() also doesn't let you set the actual prototype:

  > JSON.parse('{"__proto__": {"isAdmin": true}}')
  { ['__proto__']: { isAdmin: true } }
  > JSON.parse('{"__proto__": {"isAdmin": true}}').isAdmin
  undefined

A normal JS object can do it, but of course that isn't attacker controlled unless you are using `eval()`, in which case the battle is lost anyway.

  > {"__proto__": {"isAdmin": true}}.isAdmin
  true

But even if JSON itself doesn't set the actual prototype, combining it with a user-written merge() function that copies __proto__ will indeed pollute.

  > Object.entries(JSON.parse('{"__proto__": {"isAdmin": true}}')).reduce((o, [k, v]) => o[k] = v, {}).isAdmin
  true

That was a typo, yeah. It should be

  console.log(config.isAdmin); // true!

On Node.js there are some hardening flags like --disable-proto=throw and --frozen-intrinsics to mitigate/crash on prototype pollution, and to prevent dynamic evals with --disallow-code-generation-from-strings - however, Vercel doesn't seem to support custom node runtime options.

Just to simplify this - our exploitation tests so far have shown that a standard Next.js application created via create-next-app and built for production is vulnerable to CVE-2025-66478 without any specific code modifications by the developer - so this is essentially exploitable out-of-the-box.

Here's a patch diff:

https://github.com/vercel/next.js/compare/v15.0.4...v15.0.5

It looks like the fix is checking hasOwnProperty, so it's almost certainly an issue with prototype chain pollution.

I think this is the fix for the React Server: https://github.com/facebook/react/pull/35277/files

It looks like it only affects dynamic reloading? If I understand correctly, the client can just politely ask the server to load arbitrary code, and the server agrees.

This should never be enabled in production in the first place. I'm not surprised that they are fundamentally vulnerable, and this is likely not going to be the last RCE in this part of the code.

Unrelated but... wow, this is... certainly some code.

      return "*" === metadata[2]
        ? moduleExports
        : "" === metadata[2]
          ? moduleExports.__esModule
            ? moduleExports.default
            : moduleExports
          : moduleExports[metadata[2]];

It's generated code ("compiled" Javascript); I found it easier to read than the "main" diff in React which was (intentionally, I think?) obfuscated with additional changesets.

Unsafe deserialization is a very 2010 Ruby on Rails sort of vulnerability. It is strangely interesting that such a vulnerability was introduced so late in the lifetime of these frameworks. It must be a very sneaky vulnerability given how cautious we have become around deserialization since then.

I'm willing to bet that this is linked to the magic __proto__ object namespace in JavaScript

You win!

The React Server Components wire format (Flight) is relatively novel and very new (it has existed in React stable for just a year). This is not a simple JSON parsing bug.

The rails bugs weren't about Json parsing, they were deserializing into Ruby objects of classes that had side effects, and those side effects led to RCE possibilities. Since those happened, you'll find any deserialization library, especially in dynamic languages, will have a safe (or conversely unsafe) deserialize function to make it more explicit that there's risks involved.

Wow, I am at a loss for words how serious this is. Looking forward to a more technical write up.

This might cause quite a lot of chaos and leaked code / credentials over the next couple of weeks.

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

It seems like this might be one of the biggest vulnerabilities in recent times...

The default react / nextjs configurations being vulnerable to RCE is pretty insane. I think platform level protections from Vercel / Cloudflare are very much showing their utility now!

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...

Not entirely true. The bug is also in the dev server, but primarily the exploitable vulnerability is in apps built for production.

It's not entirely JavaScript but it is partially due to some of the language's history and culture: prototype pollution wouldn't be possible in every other language and not everyone has culture around things like decoding payloads in an exploitable manner (e.g. in the Python world some people used to decode pickled objects but it was always frowned upon; the Java world has had debates over the years about this). The big one which is unique to JavaScript is the culture around client-side execution and mixing code running between the two environments, which means you have a lot of machinery setup to execute code on the server and/or clients, making it both easy to have confusion around the execution context in ways which have been exploited and encouraging people to do things like ship complex objects between the two which programmers using other backend languages wouldn't consider because they never had the possibility of running directly in the browser.

Dang, Cloudflare is moving fast. Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/

This is what coordinated disclosure looks like.

Given that most Next.js and RSC apps run on Vercel, I’m wondering if they’re doing the same thing. There’s no information about this in their latest blog post [0].

Update: They do similar thing. Mentioned here [1]

[0] https://nextjs.org/blog/CVE-2025-66478

[1] https://vercel.com/changelog/cve-2025-55182

Would be interesting to hear from Cloudflare the extent of exploitation before today. I'm assuming they can see if/when this started being exploited.

Please submit the original source. If a post reports on something found on another site, submit the latter.

https://news.ycombinator.com/newsguidelines.html

Original non-vendor-hype source: https://react.dev/blog/2025/12/03/critical-security-vulnerab...

Who knew react server components was a bad idea....

They'll fix it, and it will probably be fine. But every single old school PHP developer and or developer with commonsense knew this was coming.

God, how I miss the day when software came on a disc and wasn't stuffed behind a $10-per-month subscription full of sploits and vulns.

Related Next.js blog: https://nextjs.org/blog/CVE-2025-66478

More discussion:

RCE Vulnerability in React and Next.js

https://news.ycombinator.com/item?id=46136026

https://www.cve.org/CVERecord?id=CVE-2025-66478 isn't even public yet, did they release this early?

The correct CVE is https://www.cve.org/CVERecord?id=CVE-2025-55182

Where is the exploit ? So we can test if we fixed it properly ? Bad actors anyway will find it, so at least we should see.

What is RCE? Remote call execution?

From the blog post:

"Assigned CVE-2025-55182 (React) and CVE-2025-66478 (Next.js), this flaw allows for unauthenticated remote code execution (RCE) on the server due to insecure deserialization."

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 get even this information without much efforts is mind-boggling. With better setup it might be able to get more.

With AI now being common place, coordinated timely disclosure is even more important considering the stakes. It is theoretically possible to get an exploit working within minutes. Considering that we see one of these major vulnerabilities annually (and it seems to me around the same time of the year) a bad actor can easily capitalise on the opportunities when presented.

It's easier for a bad actor to get an exploit, than for an operator to test his own site if the upgrade succeded

An operator might not be able to upgrade at all!

Along the fixes, the advisories now need to contain detailed workarouds, firewall rules and other adhoc solutions to ensure they get quickly deployed.

A guide for mitigation is way more useful so we can back port only the fix and test if the fix works.

I tend to agree. Cloudflare and Vercel were able to mitigate in the form of WAF rules, but it's not immediately clear what a user or vendor can do to implement mitigations themselves other than updating their dependencies (quickly!).

IMO the CVE announcement could have been better handled. This was a level 10. If other mitigations can are viable and you know about them, you have a responsibility to disclose them in order to best protect the safety of the billions of users of React applications.

I wonder how many applications are still vulnerable.

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.

Checked. The answer is no (Claude Opus 4.5 with OpenCode). It wasn't even able to write a scanner to check for the vulnerability that worked. I gave it the diffs and various writeups, and the free access to the source and compiled index.js. It kept trying to cheat by editing the source to add a vulnerability and saying that it got an RCE

Reply on news.ycombinator.com