React Got Hacked Again (this is bad)
JTJosh tried coding@joshtriedcoding · 174K subscribers
- Views
- 11.2K
- 11,178
- Outlier
- ×0.3
- Median 43.3K
- Length
- 10:02
- Published
- Dec 12, 2025
- Friday
- Comments
- 81
- 448 likes
Script
How it's written
- Words
- 1,645
- Words a minute
- 164
- Reading time
- 7 min
- Segments
- 7
The hook
0:00–0:25So, um, React got hacked again twice. Yeah, this is not a drill. After the big 10.0 critical security vulnerability exploit just last week, two more major exploits have been found in React. Man, I'm I'm getting tired and it's pretty bad. So, researchers have found two new vulnerabilities in React server
Structure
So, um, React got hacked again twice. Yeah, this is not a drill. After the big 10.0 critical security vulnerability exploit just last week, two more major exploits have been found in React. Man, I'm I'm getting tired and it's pretty bad. So, researchers have found two new vulnerabilities in React server components while attempting to exploit the patches last week. Basically, it's pretty normal. If a exploit gets leaked, especially a 10.0 security exploit like last week, people are going to probably figure out new ones in order to reproduce that. These are new issues separate from the critical CVE last week. The patch for React to Shell, the big exploit from last week, remains effective for the remote code execution exploit. What's going on here? Right. They figured out two new exploits and these are not a 10 out of 10, but they're pretty bad as well. Denial of service and source code exposure in React Server components. Security researchers have found and disclosed two additional vulnerabilities in React server components while attempting to exploit the patches in last week's critical vulnerability. These two new vulnerabilities do not allow for remote code execution. Good, right? Because remote code execution is considered the worst thing that can happen security-wise cuz anyone can run untrusted code on your server. It's not
Watch from 0:00that bad. The patch for React to Shell remains effective at mitigating the remote code execution exploit. Basically, what this means is the patch is valid, but it does not patch the two new vulnerabilities that they just found out. One of them is denial of service with a high severity classified as CVE 20255184 and this other one with a scale you know this measures the CVSS measures how bad is a vulnerability on a scale of one it doesn't really matter to 10 this is extremely high severity this gets a 7.5 so it's pretty high up there it's pretty bad and source code exposure with a medium severity of 5.3 even So, as we're going to see, this is pretty easy to pull off and it just leaks the source code of your server actions. It's pretty bad. I will show you in code here in a second. We recommend upgrading immediately due to the severity of the newly disclosed vulnerabilities. Great man. So, this is again just fixed by saying re uh npm install react at latest, Nex.js at latest, whatever it might be. It's an easy fix, but these are crazy vulnerabilities, man. I don't know if you already updated for the critical security vulnerability last week, you will need to update again. You have to be kidding me, man. Anyways, immediate action required. The vulnerabilities are present in the same packages and versions as CVE 20255182.
Watch from 1:31Quick recap. If you forgot what that was, let's go in here. This was the 10 out of 10 extremely critical security vulnerability that I made a video about a couple days ago, right? So just patching back then didn't fix the current issue. You need to do it again and so do I, right? We all need to do it. The vulnerable React versions are 19, 19.01, 02, and so on. All of these, I'm not going to go through all of them, but an important disclaimer here from the React team. It's common for critical CVEes to uncover follow-up vulnerabilities. When a critical vulnerability is disclosed, researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed. Right? So in order to try, hey, can we bypass this on a specific firewall in the code itself, people figure out new vulnerabilities and this already happened back in the days with log for shell, right? The same thing happened. People figured out additional vulnerabilities. Let's get into what are the vulnerabilities. First one, high severity denial of service with a base score of 7.5. Security researchers have discovered that a malicious HTTP request can be crafted and sent to any server function endpoint that when des serialized by React can cause an infinite loop that hangs the server process and consume CPU. Even if your app does not implement any React server function endpoints, it may still be vulnerable if your app even just
Watch from 3:00supports React server components, which most apps, especially if you're Next.js, do, right? Because NexJS does support React Server components. So, especially if you're Next, please update, man. Do us all a favor. Don't don't let this happen to you. This creates a vulnerability vector where an attacker may be able to deny users from accessing your product and potentially have a performance impact on the server environment. Cool. And then they published a patch today to mitigate the infinite loop. The other one which we're going to reproduce together right now is source code exposure with a medium severity with a 5.3 scale. A security researcher has discovered that a malicious HTTP request sent to a vulnerable server function may unsafeely return the source code of any server function. Exploitation requires the existence of a server function which explicitly or implicitly exposes a stringified argument. This is the reason this condition at the end here is big reason why this is classified as 5.3 because this doesn't just work in any case and leaks any server function but it's especially dangerous only if you explicitly or implicitly expose a stringified argument. This is the big problem. They give an example here use server. So this is classified as a server function and we have a server function with a name and this here is problematic because we're stringifying a
Watch from 4:32secret key. This is implicit right because then in the next line we are creating the connection right here to our database right in a attempt to create this user and then we are returning this is a explicit string because we're you know just inserting a template string. So both of these the implicit and the explicit are problematic in this exploit. An attacker may be able to leak the following basically the source code async function console log server function and so on with the secret key inside. This is the problematic part. So if you hardcode a variable here an attacker will be able to see it. This doesn't work with process.env because that's evaluated. Only if you stringify like hardcode the variable here. this becomes problematic. So let's visualize together how this exploit works in detail. Basically, if we have any page and define a server action on there, we import it here. This is a regular NexJS server action that we import on the page that we can somehow invoke from this page. Let's take a look at that in the server. We have a button run example server action. And whenever we do, let's open up the network tab. Let's click that. It runs the server action. And we can see the network request right here. exploit PLC. Let's open that up. And at build time for every server action that we have in our app, there is a thing that's generated in our server manifest. Let's kind of sketch this out. We have our source code. At build time, a server manifest
Watch from 6:03is generated that associates each server action with a action ID. So when we execute a server action from the client, then we attach the next action header to the request. You can see that here. In this case, the ID that's generated for this server action that identifies the action on the server is this. It's 4087 and so on. That's how we identify which function to run on the back end. And this is now problematic because if a attacker knows this next action, they can simply say, let's send a request to this action. I've prepared a script here. Here we go. Action ID. Let's paste that in right here. And as soon as they know the actual ID and the target URL, which is really easy to figure out because it's also involved in the header here, right here, the referer, for example, /exploit PC. If you know the action ID and the referral, then things become pretty problematic because if you send a specific payload, which I don't want to leak here, you know, it's not super hard to figure out, but basically it's a certain payload that we can send to the server. And if we go ahead and execute this file, oops. Ah, here we go. We get basically the source code of the server action. You know, the server action is nowhere imported in this file.
Watch from 7:34We only make a fetch request to it. But if we send the specific payload and know the action ID, which is really easy to figure out, we can know the actual source code for this function. And if something is implicitly or explicitly stringified there, then we can know about it. Again, if you use a process.env, what the attacker would see here would also be process.env. They wouldn't know the actual variable. But I am probably not the only person that doesn't always use process.env PNV and sometimes hard codes variables on the back end. Is it a good practice? No. But we all kind of do it and that would be very problematic in this specific instance if you stringify your code. Just go ahead say npm install react at latest. NextJS at latest. You're safe again. But I am getting pretty tired of so many React exploits before Christmas. Man, why does it happen now? Anyways, I appreciate you, man. Thanks so much for watching. I hope you have a safe Christmas. save pre Christmas time. Um, just install the latest patch and then I will see you in the next video.
Watch from 8:54Full transcript
- 0:00
So, um, React got hacked again twice. Yeah, this is not a drill. After the big 10.0 critical security vulnerability exploit just last week, two more major exploits have been found in React. Man, I'm I'm getting tired and it's pretty
- 0:20
bad. So, researchers have found two new vulnerabilities in React server components while attempting to exploit the patches last week. Basically, it's pretty normal. If a exploit gets leaked, especially a 10.0 security exploit like last week, people are going to probably figure out new ones in order to reproduce that. These are new issues separate from the critical CVE last
- 0:42
week. The patch for React to Shell, the big exploit from last week, remains effective for the remote code execution exploit. What's going on here? Right. They figured out two new exploits and these are not a 10 out of 10, but they're pretty bad as well. Denial of service and source code exposure in
- 1:04
React Server components. Security researchers have found and disclosed two additional vulnerabilities in React server components while attempting to exploit the patches in last week's critical vulnerability. These two new vulnerabilities do not allow for remote code execution. Good, right? Because remote code execution is considered the
- 1:26
worst thing that can happen security-wise cuz anyone can run untrusted code on your server. It's not that bad. The patch for React to Shell remains effective at mitigating the remote code execution exploit. Basically, what this means is the patch is valid, but it does not patch the two new vulnerabilities that they just found out. One of them is denial of service
- 1:47
with a high severity classified as CVE 20255184 and this other one with a scale you know this measures the CVSS measures how bad is a vulnerability on a scale of one it doesn't really matter to 10 this is extremely high severity this gets a 7.5
- 2:07
so it's pretty high up there it's pretty bad and source code exposure with a medium severity of 5.3 even So, as we're going to see, this is pretty easy to pull off and it just leaks the source code of your server actions. It's pretty bad. I will show you in code here in a second. We recommend upgrading immediately due to the severity of the newly disclosed vulnerabilities. Great
- 2:29
man. So, this is again just fixed by saying re uh npm install react at latest, Nex.js at latest, whatever it might be. It's an easy fix, but these are crazy vulnerabilities, man. I don't know if you already updated for the critical security vulnerability last week, you will need to update again. You have to be kidding me, man. Anyways,
- 2:52
immediate action required. The vulnerabilities are present in the same packages and versions as CVE 20255182. Quick recap. If you forgot what that was, let's go in here. This was the 10 out of 10 extremely critical security vulnerability that I made a video about a couple days ago, right? So just patching back then didn't fix the
- 3:14
current issue. You need to do it again and so do I, right? We all need to do it. The vulnerable React versions are 19, 19.01, 02, and so on. All of these, I'm not going to go through all of them, but an important disclaimer here from the React team. It's common for critical CVEes to uncover follow-up vulnerabilities. When a critical
- 3:34
vulnerability is disclosed, researchers scrutinize adjacent code paths looking for variant exploit techniques to test whether the initial mitigation can be bypassed. Right? So in order to try, hey, can we bypass this on a specific firewall in the code itself, people figure out new vulnerabilities and this already happened back in the days with
- 3:56
log for shell, right? The same thing happened. People figured out additional vulnerabilities. Let's get into what are the vulnerabilities. First one, high severity denial of service with a base score of 7.5. Security researchers have discovered that a malicious HTTP request can be crafted and sent to any server function endpoint that when des
- 4:18
serialized by React can cause an infinite loop that hangs the server process and consume CPU. Even if your app does not implement any React server function endpoints, it may still be vulnerable if your app even just supports React server components, which most apps, especially if you're Next.js, do, right? Because NexJS does support
- 4:40
React Server components. So, especially if you're Next, please update, man. Do us all a favor. Don't don't let this happen to you. This creates a vulnerability vector where an attacker may be able to deny users from accessing your product and potentially have a performance impact on the server environment. Cool. And then they published a patch today to mitigate the
- 5:02
infinite loop. The other one which we're going to reproduce together right now is source code exposure with a medium severity with a 5.3 scale. A security researcher has discovered that a malicious HTTP request sent to a vulnerable server function may unsafeely return the source code of any server
- 5:23
function. Exploitation requires the existence of a server function which explicitly or implicitly exposes a stringified argument. This is the reason this condition at the end here is big reason why this is classified as 5.3 because this doesn't just work in any case and leaks any server function but
- 5:44
it's especially dangerous only if you explicitly or implicitly expose a stringified argument. This is the big problem. They give an example here use server. So this is classified as a server function and we have a server function with a name and this here is problematic because we're stringifying a secret key. This is implicit right
- 6:06
because then in the next line we are creating the connection right here to our database right in a attempt to create this user and then we are returning this is a explicit string because we're you know just inserting a template string. So both of these the implicit and the explicit are problematic in this exploit. An attacker
- 6:27
may be able to leak the following basically the source code async function console log server function and so on with the secret key inside. This is the problematic part. So if you hardcode a variable here an attacker will be able to see it. This doesn't work with process.env because that's evaluated.
- 6:47
Only if you stringify like hardcode the variable here. this becomes problematic. So let's visualize together how this exploit works in detail. Basically, if we have any page and define a server action on there, we import it here. This is a regular NexJS server action that we import on the page that we can somehow invoke from this page. Let's take a look at that in the server. We have a button
- 7:09
run example server action. And whenever we do, let's open up the network tab. Let's click that. It runs the server action. And we can see the network request right here. exploit PLC. Let's open that up. And at build time for every server action that we have in our app, there is a thing that's generated in our server manifest. Let's kind of
- 7:29
sketch this out. We have our source code. At build time, a server manifest is generated that associates each server action with a action ID. So when we execute a server action from the client, then we attach the next action header to the request. You can see that here. In
- 7:50
this case, the ID that's generated for this server action that identifies the action on the server is this. It's 4087 and so on. That's how we identify which function to run on the back end. And this is now problematic because if a attacker knows this next action, they can simply say, let's send a request to
- 8:11
this action. I've prepared a script here. Here we go. Action ID. Let's paste that in right here. And as soon as they know the actual ID and the target URL, which is really easy to figure out because it's also involved in the header here, right here, the referer, for example, /exploit PC. If you know the action ID and the referral, then things
- 8:31
become pretty problematic because if you send a specific payload, which I don't want to leak here, you know, it's not super hard to figure out, but basically it's a certain payload that we can send to the server. And if we go ahead and execute this file, oops. Ah, here we go. We get basically the source code of the server action. You know, the server
- 8:52
action is nowhere imported in this file. We only make a fetch request to it. But if we send the specific payload and know the action ID, which is really easy to figure out, we can know the actual source code for this function. And if something is implicitly or explicitly stringified there, then we can know about it. Again, if you use a process.env, what the attacker would see
- 9:14
here would also be process.env. They wouldn't know the actual variable. But I am probably not the only person that doesn't always use process.env PNV and sometimes hard codes variables on the back end. Is it a good practice? No. But we all kind of do it and that would be very problematic in this specific instance if you stringify your code.
- 9:35
Just go ahead say npm install react at latest. NextJS at latest. You're safe again. But I am getting pretty tired of so many React exploits before Christmas. Man, why does it happen now? Anyways, I appreciate you, man. Thanks so much for watching. I hope you have a safe Christmas. save pre Christmas time. Um, just install the latest patch and then I
- 9:57
will see you in the next video.
Description
you gotta be kidding me man, lets chill before christmas 😭😭😭
-- my links
twitter: https://x.com/joshtriedcoding
github: https://github.com/joschan21
Sponsorfirecrawl affiliate link: https://firecrawl.link/josh-triedcoding
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
