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.
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 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...
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
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 : )
> 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!
> 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.
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).
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.
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.
return "*" === metadata[2]
? moduleExports
: "" === metadata[2]
? moduleExports.__esModule
? moduleExports.default
: moduleExports
: moduleExports[metadata[2]];This might cause quite a lot of chaos and leaked code / credentials over the next couple of weeks.
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!
Vulnerabilities caused by shoddy JS are a lot more impactful to a server since multiple users will be served by the same runtime instance.
The bug here is in the hot reloading code. It should not be enabled anywhere but on developers' machines.
Update: They do similar thing. Mentioned here [1]
https://news.ycombinator.com/newsguidelines.html
Original non-vendor-hype source: https://react.dev/blog/2025/12/03/critical-security-vulnerab...
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.
RCE Vulnerability in React and Next.js
"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."
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.
> 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!"
Btw, LLMs are already used in vulnerability discovery and exploit development.
Along the fixes, the advisories now need to contain detailed workarouds, firewall rules and other adhoc solutions to ensure they get quickly deployed.
> let config = {};
> Object.assign(config, JSON.parse('{"__proto__": {"isAdmin": true}}'));
console.log({}.isAdmin); // true!
> console.log({}['constructor'] ? {}['constructor']('THIS MUST NOT BE EXPOSED') : 'pub')
[String: 'THIS MUST NOT BE EXPOSED'] > let config = {};
> Object.assign(config, JSON.parse('{"__proto__": {"isAdmin": true}}'));
console.log({}.isAdmin); // undefined
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
> {"__proto__": {"isAdmin": true}}.isAdmin
true
> Object.entries(JSON.parse('{"__proto__": {"isAdmin": true}}')).reduce((o, [k, v]) => o[k] = v, {}).isAdmin
true console.log(config.isAdmin); // true!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.
Which you should've done before making such statements imo.
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.
+ it is maybe 10% AI max, which seems to be for the structure / readability, and there is legit information under.
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.
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
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.
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).
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.)
Mismatched smart quotes are visible in this archive.