zlacker

Critical RCE Vulnerabilities in React and Next.js

submitted by gonepi+(OP) on 2025-12-03 16:03:27 | 134 points 69 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
4. mmsc+p6[view] [source] 2025-12-03 16:30:37
>>gonepi+(OP)
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.

7. bri3d+c9[view] [source] 2025-12-03 16:43:02
>>gonepi+(OP)
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.

◧◩
13. cachiu+6c[view] [source] [discussion] 2025-12-03 16:54:34
>>skille+j6
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

15. pixl97+Pc[view] [source] 2025-12-03 16:58:08
>>gonepi+(OP)
https://www.cve.org/CVERecord?id=CVE-2025-66478 isn't even public yet, did they release this early?
17. cvsswe+1d[view] [source] 2025-12-03 16:58:51
>>gonepi+(OP)
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...

19. karimf+yd[view] [source] 2025-12-03 17:00:38
>>gonepi+(OP)
Dang, Cloudflare is moving fast. Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/
20. Walter+Rd[view] [source] 2025-12-03 17:01:38
>>gonepi+(OP)
Related Next.js blog: https://nextjs.org/blog/CVE-2025-66478
◧◩◪
25. mmsc+gf[view] [source] [discussion] 2025-12-03 17:08:02
>>jfindp+T9
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...

◧◩◪
28. karimf+Wf[view] [source] [discussion] 2025-12-03 17:10:57
>>xnorsw+ae
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

◧◩
29. mattca+hg[view] [source] [discussion] 2025-12-03 17:12:32
>>pixl97+Pc
The correct CVE is https://www.cve.org/CVERecord?id=CVE-2025-55182
◧◩
39. cybera+oj[view] [source] [discussion] 2025-12-03 17:25:59
>>bri3d+c9
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.

45. mmsc+Jk[view] [source] 2025-12-03 17:31:29
>>gonepi+(OP)
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

◧◩◪◨⬒⬓⬔⧯
53. nostra+Qs[view] [source] [discussion] 2025-12-03 18:10:05
>>Nitpic+Fl
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.)

◧◩◪◨⬒⬓⬔⧯▣
54. mmsc+Yt[view] [source] [discussion] 2025-12-03 18:16:14
>>nostra+Qs
https://archive.md/2025.12.03-165833/https://www.wiz.io/blog...

Mismatched smart quotes are visible in this archive.

60. ChrisA+Nj1[view] [source] 2025-12-03 22:28:38
>>gonepi+(OP)
More discussion:

RCE Vulnerability in React and Next.js

>>46136026

◧◩◪
61. rezona+3D1[view] [source] [discussion] 2025-12-04 00:38:58
>>mmsc+Al
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
[go to top]