12 ms·

Critical RCE Vulnerabilities in React and Next.js

134 points by gonepivoting 10mo ago

gonepivoting 10mo ago
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.
tinco 10mo ago
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.
- LunaSea 10mo ago
  I'm willing to bet that this is linked to the magic __proto__ object namespace in JavaScript
  - jazzypants 10mo ago
    You win!
- Tomuus 10mo ago
  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.
  - tinco 10mo ago
    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.
skilled 10mo ago
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.
- cachius 10mo ago
  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 https://vercel.com/changelog/cve-2025-55182
mmsc 10mo ago
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-vulnerability-in-react-server-components 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.
- jfindper 10mo ago
  >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?
  - tensegrist 10mo ago
    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
    - deleted 10mo ago
      [deleted]
    - jfindper 10mo ago
bri3d 10mo ago
Here's a patch diff: https://github.com/vercel/next.js/compare/v15.0.4...v15.0.5 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.
- cyberax 10mo ago
  I think this is the fix for the React Server: https://github.com/facebook/react/pull/35277/files 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.
- EdwardDiego 10mo ago
  Unrelated but... wow, this is... certainly some code. return "*" === metadata[2] ? moduleExports : "" === metadata[2] ? moduleExports.__esModule ? moduleExports.default : moduleExports : moduleExports[metadata[2]];
  - bri3d 10mo ago
    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.
jimmyl02 10mo ago
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!
pixl97 10mo ago
https://www.cve.org/CVERecord?id=CVE-2025-66478 https://www.cve.org/CVERecord?id=CVE-2025-66478 isn't even public yet, did they release this early?
- deleted 10mo ago
  [deleted]
- mattcarrollcode 10mo ago
  The correct CVE is https://www.cve.org/CVERecord?id=CVE-2025-55182 https://www.cve.org/CVERecord?id=CVE-2025-55182
_pdp_ 10mo ago
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.
- rvnx 10mo ago
  It's easier for a bad actor to get an exploit, than for an operator to test his own site if the upgrade succeded
  - _pdp_ 10mo ago
    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.
    - rvnx 10mo ago
      A guide for mitigation is way more useful so we can back port only the fix and test if the fix works.
    - seanw265 10mo ago
      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.
cvsswebshit 10mo ago
Please submit the original source. If a post reports on something found on another site, submit the latter. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Original non-vendor-hype source: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab...
_f9cu 10mo ago
What is RCE? Remote call execution?
- 1vuio0pswjnm7 10mo ago
  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."
karimf 10mo ago
Dang, Cloudflare is moving fast. Cloudflare WAF proactively protects against React vulnerability https://blog.cloudflare.com/waf-rules-react-vulnerability/ https://blog.cloudflare.com/waf-rules-react-vulnerability/
- xnorswap 10mo ago
  This is what coordinated disclosure looks like.
  - karimf 10mo ago
    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 https://nextjs.org/blog/CVE-2025-66478 [1] https://vercel.com/changelog/cve-2025-55182 https://vercel.com/changelog/cve-2025-55182
- bradly 10mo ago
  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.
WalterSobchak 10mo ago
Related Next.js blog: https://nextjs.org/blog/CVE-2025-66478 https://nextjs.org/blog/CVE-2025-66478
rvnx 10mo ago
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.
tempaccount420 10mo ago
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.
- cyberax 10mo ago
  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.
  - tempaccount420 10mo ago
    It's never JavaScript itself, but somehow it's almost always JavaScript code...
  - cluckindan 10mo ago
    Not entirely true. The bug is also in the dev server, but primarily the exploitable vulnerability is in apps built for production.
  - acdha 10mo ago
    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.
dizlexic 10mo ago
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.
- venturecruelty 10mo ago
  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.
mmsc 10mo ago
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 https://github.com/tc39/proposal-symbol-proto
- mmsc 10mo ago
  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']
  - rezonant 10mo ago
    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/Reference/Global_Objects/Object/assign#properties_on_the_prototype_chain_and_non-enumerable_properties_cannot_be_copied 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
ChrisArchitect 10mo ago
More discussion: RCE Vulnerability in React and Next.js https://news.ycombinator.com/item?id=46136026 https://news.ycombinator.com/item?id=46136026

134 points by gonepivoting 10mo ago

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.

tinco 10mo ago

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.

LunaSea 10mo ago
I'm willing to bet that this is linked to the magic __proto__ object namespace in JavaScript
- jazzypants 10mo ago
  You win!
Tomuus 10mo ago
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.
- tinco 10mo ago
  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.

skilled 10mo ago

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.

cachius 10mo ago
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 https://vercel.com/changelog/cve-2025-55182

mmsc 10mo ago

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-vulnerability-in-react-server-components 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.

jfindper 10mo ago
>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?
- tensegrist 10mo ago
  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
  - deleted 10mo ago
    [deleted]
  - jfindper 10mo ago

bri3d 10mo ago

Here's a patch diff: https://github.com/vercel/next.js/compare/v15.0.4...v15.0.5 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.

cyberax 10mo ago
I think this is the fix for the React Server: https://github.com/facebook/react/pull/35277/files 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.
EdwardDiego 10mo ago
Unrelated but... wow, this is... certainly some code. return "*" === metadata[2] ? moduleExports : "" === metadata[2] ? moduleExports.__esModule ? moduleExports.default : moduleExports : moduleExports[metadata[2]];
- bri3d 10mo ago
  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.

jimmyl02 10mo ago

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!

pixl97 10mo ago

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

deleted 10mo ago
[deleted]
mattcarrollcode 10mo ago
The correct CVE is https://www.cve.org/CVERecord?id=CVE-2025-55182 https://www.cve.org/CVERecord?id=CVE-2025-55182

_pdp_ 10mo ago

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.

rvnx 10mo ago
It's easier for a bad actor to get an exploit, than for an operator to test his own site if the upgrade succeded
- _pdp_ 10mo ago
  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.
  - rvnx 10mo ago
    A guide for mitigation is way more useful so we can back port only the fix and test if the fix works.
  - seanw265 10mo ago
    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.

cvsswebshit 10mo ago

Please submit the original source. If a post reports on something found on another site, submit the latter. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html Original non-vendor-hype source: https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components https://react.dev/blog/2025/12/03/critical-security-vulnerab...

_f9cu 10mo ago

What is RCE? Remote call execution?

1vuio0pswjnm7 10mo ago
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."

karimf 10mo ago

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

xnorswap 10mo ago
This is what coordinated disclosure looks like.
- karimf 10mo ago
  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 https://nextjs.org/blog/CVE-2025-66478 [1] https://vercel.com/changelog/cve-2025-55182 https://vercel.com/changelog/cve-2025-55182
bradly 10mo ago
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.

WalterSobchak 10mo ago

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

rvnx 10mo ago

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.

tempaccount420 10mo ago

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.

cyberax 10mo ago
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.
- tempaccount420 10mo ago
  It's never JavaScript itself, but somehow it's almost always JavaScript code...
- cluckindan 10mo ago
  Not entirely true. The bug is also in the dev server, but primarily the exploitable vulnerability is in apps built for production.
- acdha 10mo ago
  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.

dizlexic 10mo ago

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.

venturecruelty 10mo ago
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.

mmsc 10mo ago

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 https://github.com/tc39/proposal-symbol-proto

mmsc 10mo ago
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']
- rezonant 10mo ago
  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/Reference/Global_Objects/Object/assign#properties_on_the_prototype_chain_and_non-enumerable_properties_cannot_be_copied 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

ChrisArchitect 10mo ago

More discussion: RCE Vulnerability in React and Next.js https://news.ycombinator.com/item?id=46136026 https://news.ycombinator.com/item?id=46136026