Everyone's Talking About This React Exploit
JTJosh tried coding@joshtriedcoding · 174K subscribers
- Views
- 21.2K
- 21,212
- Outlier
- ×0.5
- Median 43.3K
- Length
- 12:22
- Published
- Dec 4, 2025
- Thursday
- Comments
- 74
- 719 likes
Script
How it's written
- Words
- 1,955
- Words a minute
- 158
- Reading time
- 9 min
- Segments
- 9
The hook
0:00–0:25Not going to lie, man. It's not looking too hot for the JavaScript ecosystem at the moment. First npm gets hacked. And now, just a week later, the biggest React exploit in probably the entire year. In this video, I want to find out together with you what might have been the problem, how the React team fixed it within hours, and what the problem was in the first place. So, there's a critical security vulnerability in React
Structure
Not going to lie, man. It's not looking too hot for the JavaScript ecosystem at the moment. First npm gets hacked. And now, just a week later, the biggest React exploit in probably the entire year. In this video, I want to find out together with you what might have been the problem, how the React team fixed it within hours, and what the problem was in the first place. So, there's a critical security vulnerability in React server components published on December 3rd by the React team. So let's get into this and see what was the problem and how did they fix it. So there is an unauthenticated remote code execution vulnerability in React server components. That sounds really scary man. Basically anyone can execute code that they want inside of your server components. That's scary and they recommend upgrading immediately. On November 29th, Lachland Davidson reported a security vulnerability in React that allows unauthenticated remote code execution by exploiting a flaw in how React decodes payloads sent to the React server function endpoints. And now we're going to take a look at the commit that fixes this here in a bit. I already opened this up. But before we do that, let's understand really what the problem is. Even if your app does not implement any React server function endpoints, it may still be vulnerable if your app supports React server components. So even if you don't use React server functions, which I personally don't, I
Watch from 0:00think there are nicer ways to fetch data with React Query, for example, and a type safe RPC endpoint, well, you're still vulnerable to this exploit. So this is scary, man. This vulnerability was disclosed as CVE 202555182 and is rated a CVSs of 10.0. CVSS is a way to score vulnerabilities on a scale of 0 to 10. 10 being the most severe and this is a straight 10 out of 10. So this is really really bad because as I found in this article critical vulnerabilities in React and NexJS everything you need to know. Yes, not only React is affected. Of course, Nex.js builds on these features. So, NexJS is also affected. The interesting thing here, basically, this is an exploit in the React server components flight protocol. Even the default configurations are vulnerable. Like, if you just create a standard NexJS app with create next app and don't change anything about it, you are vulnerable in some versions like every 15 and every 16 version. So all of the newer ones, they can be exploited with no code changes by the developer. So that's that's kind of nutty, man. Even if you don't change anything, you're still vulnerable. And the exploitation requires only a crafted HTTP request and has shown near 100% reliability in testing. The flaw stems from insecure des serialization in the
Watch from 1:31RC payload handling logic allowing attacker control data to influence serverside execution. So pretty much the only way around this is to patch your version. So what React and NexJS both did is first off firewall patches on the Verscell side. For example, if you happen to deploy on Versell, well, the firewall is kind of a hot fix without upgrading the package, but you should still probably upgrade the package as soon as possible. So, what the teams did is release new versions for basically every vulnerable version before that, right? So, 19.2 was affected. Well, they published 19.2.1, a minor patch. So even if you just say bun upgrade or npm update, whatever package manager you use, you're automatically going to be put on a safe version even without any other changes. That's a good way to go about it. We can see that quite a few people already downloaded these patches. Like 19.2.1 about 3,000 people here. For 19.0, it's 7,000 people. This is probably nowhere close to the amount of people that installed the vulnerable version, 19.0.0. zero. Which is why I want to be really careful when we get to the technical part because still a lot a lot of people are vulnerable to this and probably especially vibe coded apps man do you really think vibe coders people who just prompt cursor will really care about this I don't know man I hope so but still so many people are vulnerable to
Watch from 3:02this let's take a look at how this looks on nextj site because obviously react is affected in nextjs it's pretty much the same thing. This vulnerability originates in the upstream React implementation that Nex.js, especially the server components built on top of this advisory tracks the downstream impact on NexJS applications using the app router. It allows untrusted inputs to influence serverside execution behavior under specific conditions in attacker could craft requests that trigger unintended server execution paths. This can result in remote code execution in unpatched environments and basically every NexJS5 every NexJS 16 version is affected. Again here they published minor patches. So as soon as you upgrade your dependencies you are good and you're on a patch version. So all you need to do is say like npm update and that should fix it with these minor patches. You can see 15 has patches and 16 as well just in you know semantic versioning. these very tiny ones that npm knows to automatically update. Now, there are certain conditions though when you're not affected. If your app react code does not use a server whatsoever, you're good. Your app is not affected by this vulnerability. If your app does not use a framework bundler or bundler plug-in that supports React server components, your app is not affected by this vulnerability. So if you just use React as a spa, as a single page application purely on the client, you are fine. But
Watch from 4:33if you're using Next, React Router, Wahoo, basically any other way to interact with the more modern server-based React, well, just upgrade your packages, man. So how did this how did this work? Vulnerability overview. React server functions allow a client to call a function on a server. That's the idea, right? It's pipes safe. It's very convenient. It's honestly a really good way to execute code on the server, but it's also the problem here. React provides integration points and tools that frameworks and bunders use to help React code run on both the client and the server. React translates requests on the client into HTTP requests, which are forwarded to a server. So, it looks like you're calling a function on the client, but really crosses the network boundary. React turns this function call into an HTTP request and it's sent to the server. On the server, React translates the HTTP request into a function call and returns the needed data to the client. So, a classic RPC pattern. An unauthenticated attacker could craft a malicious HTTP request to any server function endpoint that when deserialized by React achieves remote code execution on the server. The attacker can run code in your environment in your server.
Watch from 6:05Further details of the vulnerability will be provided after the rollout of the fix is complete which makes a lot of sense because so many people are still vulnerable to this right so I want to be very careful with the technical part because so many people still haven't updated but I also want to provide a basic overview kind of how this vulnerability might have worked. Now let's take a look at a P here published on GitHub. But this P is very very likely not the actual issue, right? This is probably not it. This is artificially more dangerous than it needs to be. So take this vulnerability PLC with a very very big grain of salt, but it does help us kind of understand how this vulnerability might have worked. So let's take a look at this with a very big grain of salt. Basically we have a require module function in this example which might or might not exist in the actual react. But the vulnerable part is right here at the very end when we are parsing a module right here. This statement is problematic because we are accessing an object in this case module exports at the index of a user controlled input but we're not checking if whatever is
Watch from 7:23metadata 2 or what that evaluates to is a property of the object which is problematic. So the issue in this case would be that the module exports at the index of metadata 2 checks along the prototype chain the entire inheritance chain of the object and not just its own properties. If we have an object let's call it like in this example module exports cons module exports and let's just define it as an empty object. This metadata 2 property we are accessing on the object module exports can be influenced by the user. So this could evaluate for example to module exports dot constructor right or I guess in a different notation like here we could access the module exports at the property of constructor for example or any other property that exists well probably not emojis any other property that exists along the inheritance chain right for example constructor so this actually evaluates to a function and like this the user could get access to code they are not supposed to get access to. Right? The problem here is the constructor is not a property of the actual object. It's along the inheritance chain. So the better way to do it would be to check if the module exports has own property and we can check for constructor and this check module exports.ropy constructor evaluates to false because
Watch from 8:54it's not an actual property of the object. It's a property of the object instantiation above the module exports. And this here is the patch that fixed the problem. The patch flight reply server with fixes from ReactFlight client. So we already know this was a deserialization issue on the server somewhere in the ReactFlight protocol. And this patch also fixes a security vulnerability which is what we just talked about the big React problem that you know you can just fix by upgrading. And let's take a look at the commit now. For better or for worse, this commit is really long. This is actually not so bad because we don't want to provide the reproduction of the issue until literally everyone has upgraded. But I need to admit I already took a careful look at this whole commit and I think the issue fix for the vulnerability might be this one. The import has own property from shared has own property. So basically before we returned the module exports at the index of metadata name which looks very similar to what I just showed you where you could access things on the object inheritance chain above the module exports that usually users should not be allowed to access right like the constructor for example.
Watch from 10:25Now we are checking does the module exports object have the metadata at the index of name. Is it an actual property of the object? And that seems a lot more safe. Now, was this the main patch for the security vulnerability? I don't know. And it's totally fine to not know. Now, if you upgrade to any of these versions in XJS or any newer version in React, you're good. You're fine. But you should probably do that. I should probably do that, too, man. I think we're all affected by this cuz I like experimenting in the most modern versions. And turns out sometimes very very critical security vulnerabilities happen.
Watch from 11:42Full transcript
- 0:00
Not going to lie, man. It's not looking too hot for the JavaScript ecosystem at the moment. First npm gets hacked. And now, just a week later, the biggest React exploit in probably the entire year. In this video, I want to find out together with you what might have been the problem, how the React team fixed it within hours, and what the problem was
- 0:20
in the first place. So, there's a critical security vulnerability in React server components published on December 3rd by the React team. So let's get into this and see what was the problem and how did they fix it. So there is an unauthenticated remote code execution vulnerability in React server components. That sounds really scary
- 0:42
man. Basically anyone can execute code that they want inside of your server components. That's scary and they recommend upgrading immediately. On November 29th, Lachland Davidson reported a security vulnerability in React that allows unauthenticated remote code execution by exploiting a flaw in
- 1:03
how React decodes payloads sent to the React server function endpoints. And now we're going to take a look at the commit that fixes this here in a bit. I already opened this up. But before we do that, let's understand really what the problem is. Even if your app does not implement any React server function endpoints, it may still be vulnerable if your app
- 1:25
supports React server components. So even if you don't use React server functions, which I personally don't, I think there are nicer ways to fetch data with React Query, for example, and a type safe RPC endpoint, well, you're still vulnerable to this exploit. So this is scary, man. This vulnerability was disclosed as CVE 202555182
- 1:47
and is rated a CVSs of 10.0. CVSS is a way to score vulnerabilities on a scale of 0 to 10. 10 being the most severe and this is a straight 10 out of 10. So this is really really bad because as I found in this article critical vulnerabilities in React and NexJS everything you need
- 2:07
to know. Yes, not only React is affected. Of course, Nex.js builds on these features. So, NexJS is also affected. The interesting thing here, basically, this is an exploit in the React server components flight protocol. Even the default configurations are vulnerable. Like, if you just create a standard NexJS app with create next app
- 2:30
and don't change anything about it, you are vulnerable in some versions like every 15 and every 16 version. So all of the newer ones, they can be exploited with no code changes by the developer. So that's that's kind of nutty, man. Even if you don't change anything, you're still vulnerable. And the
- 2:50
exploitation requires only a crafted HTTP request and has shown near 100% reliability in testing. The flaw stems from insecure des serialization in the RC payload handling logic allowing attacker control data to influence serverside execution. So pretty much the only way around this
- 3:13
is to patch your version. So what React and NexJS both did is first off firewall patches on the Verscell side. For example, if you happen to deploy on Versell, well, the firewall is kind of a hot fix without upgrading the package, but you should still probably upgrade the package as soon as possible. So, what the teams did is release new versions for basically every vulnerable
- 3:35
version before that, right? So, 19.2 was affected. Well, they published 19.2.1, a minor patch. So even if you just say bun upgrade or npm update, whatever package manager you use, you're automatically going to be put on a safe version even without any other changes. That's a good way to go about it. We can see that
- 3:56
quite a few people already downloaded these patches. Like 19.2.1 about 3,000 people here. For 19.0, it's 7,000 people. This is probably nowhere close to the amount of people that installed the vulnerable version, 19.0.0. zero. Which is why I want to be really careful when we get to the technical part because still a lot a lot of people are
- 4:19
vulnerable to this and probably especially vibe coded apps man do you really think vibe coders people who just prompt cursor will really care about this I don't know man I hope so but still so many people are vulnerable to this let's take a look at how this looks on nextj site because obviously react is affected in nextjs it's pretty much the
- 4:41
same thing. This vulnerability originates in the upstream React implementation that Nex.js, especially the server components built on top of this advisory tracks the downstream impact on NexJS applications using the app router. It allows untrusted inputs to influence serverside execution behavior under specific conditions in attacker could craft requests that
- 5:02
trigger unintended server execution paths. This can result in remote code execution in unpatched environments and basically every NexJS5 every NexJS 16 version is affected. Again here they published minor patches. So as soon as you upgrade your dependencies you are good and you're on a patch version. So all you need to do is say like npm
- 5:24
update and that should fix it with these minor patches. You can see 15 has patches and 16 as well just in you know semantic versioning. these very tiny ones that npm knows to automatically update. Now, there are certain conditions though when you're not affected. If your app react code does not use a server whatsoever, you're
- 5:46
good. Your app is not affected by this vulnerability. If your app does not use a framework bundler or bundler plug-in that supports React server components, your app is not affected by this vulnerability. So if you just use React as a spa, as a single page application purely on the client, you are fine. But if you're using Next, React Router,
- 6:07
Wahoo, basically any other way to interact with the more modern server-based React, well, just upgrade your packages, man. So how did this how did this work? Vulnerability overview. React server functions allow a client to call a function on a server. That's the idea, right? It's pipes safe. It's very convenient. It's honestly a really good
- 6:29
way to execute code on the server, but it's also the problem here. React provides integration points and tools that frameworks and bunders use to help React code run on both the client and the server. React translates requests on the client into HTTP requests, which are forwarded to a server. So, it looks like
- 6:50
you're calling a function on the client, but really crosses the network boundary. React turns this function call into an HTTP request and it's sent to the server. On the server, React translates the HTTP request into a function call and returns the needed data to the client. So, a classic RPC pattern. An unauthenticated attacker could craft a
- 7:10
malicious HTTP request to any server function endpoint that when deserialized by React achieves remote code execution on the server. The attacker can run code in your environment in your server. Further details of the vulnerability will be provided after the rollout of the fix is complete which makes a lot of sense because so many people are still
- 7:31
vulnerable to this right so I want to be very careful with the technical part because so many people still haven't updated but I also want to provide a basic overview kind of how this vulnerability might have worked.
- 7:52
Now let's take a look at a P here published on GitHub. But this P is very very likely not the actual issue, right? This is probably not it. This is artificially more dangerous than it needs to be. So take this vulnerability
- 8:13
PLC with a very very big grain of salt, but it does help us kind of understand how this vulnerability might have worked. So let's take a look at this with a very big grain of salt. Basically we have a require module function in this example which might or might not exist in the actual react. But the vulnerable part is right here at the
- 8:35
very end when we are parsing a module right here. This statement is problematic because we are accessing an object in this case module exports at the index of a user controlled input but we're not checking if whatever is metadata 2 or what that evaluates to is
- 8:57
a property of the object which is problematic. So the issue in this case would be that the module exports at the index of metadata 2 checks along the prototype chain the entire inheritance chain of the object and not just its own properties. If we have an object let's call it like in this example module
- 9:17
exports cons module exports and let's just define it as an empty object. This metadata 2 property we are accessing on the object module exports can be influenced by the user. So this could evaluate for example to module exports dot constructor right or I guess in a different notation like here we could
- 9:39
access the module exports at the property of constructor for example or any other property that exists well probably not emojis any other property that exists along the inheritance chain right for example constructor so this actually evaluates to a function and like this the user could get access to
- 9:59
code they are not supposed to get access to. Right? The problem here is the constructor is not a property of the actual object. It's along the inheritance chain. So the better way to do it would be to check if the module exports has own property and we can check for constructor and this check
- 10:21
module exports.ropy constructor evaluates to false because it's not an actual property of the object. It's a property of the object instantiation above the module exports. And this here is the patch that fixed the problem. The patch flight reply server with fixes from ReactFlight client. So we already know this was a
- 10:41
deserialization issue on the server somewhere in the ReactFlight protocol. And this patch also fixes a security vulnerability which is what we just talked about the big React problem that you know you can just fix by upgrading. And let's take a look at the commit now. For better or for worse, this commit is really long. This is actually not so bad
- 11:04
because we don't want to provide the reproduction of the issue until literally everyone has upgraded. But I need to admit I already took a careful look at this whole commit and I think the issue fix for the vulnerability might be this one. The import has own property from shared has own property. So basically before we returned the
- 11:26
module exports at the index of metadata name which looks very similar to what I just showed you where you could access things on the object inheritance chain above the module exports that usually users should not be allowed to access right like the constructor for example. Now we are checking does the module exports object have the metadata at the
- 11:47
index of name. Is it an actual property of the object? And that seems a lot more safe. Now, was this the main patch for the security vulnerability? I don't know. And it's totally fine to not know. Now, if you upgrade to any of these versions in XJS or any newer version in React, you're good. You're fine. But you
- 12:08
should probably do that. I should probably do that, too, man. I think we're all affected by this cuz I like experimenting in the most modern versions. And turns out sometimes very very critical security vulnerabilities happen.
Description
wake up babe, a brand new react vulnerability just dropped 😭💀
i am REALLY curious how this worked exactly. there are no official details yet (obviously), but i'm really looking forward to learn about this. it's likely related to prototype pollution and the original finder maintains a website about the issue here: react2shell.com
-- other resources
I found this investigation on the topic really nice:
https://github.com/msanft/CVE-2025-55182
-- my links
twitter: https://x.com/joshtriedcoding
github: https://github.com/joschan21
appreciate you for watching 🙌
More from Josh tried coding
×1312:00:00Build a Complete Digital Marketplace with Next.js 14, React, tRPC, Tailwind | Full Course 2023
Josh tried coding571K views
×1212:00:00Build a Complete E-Commerce Shop with Next.js 14, Tailwind, React | Full Course 2024
Josh tried coding509K views
×4.44:41My Favorite UI Library Keeps Getting Better
Josh tried coding191K views
×3.76:58Fetching Data Doesn't Get Better Than This
Josh tried coding160K views
