React2Shell: My First Up-Close Security Vulnerability

I had some very exciting news this week, at least for me, when I received an email from Vercel letting me know that there was a security flaw in certain versions of the framework. Probably not such exciting news for them!

The issue turned out to be a security vulnerability in some React components, tracked as CVE-2025-55182, also known as react2shell. (And then a few further issues in a separate email).

This vulnerability affects projects using certain versions of Next.js and React. Thankfully, a fix was released pretty quickly, but there was already a proof of concept available meaning attackers could potentially figure out how to exploit it if projects weren’t updated.

WHAT IS THE VULNERABILITY?

In simple terms, researchers discovered that if an attacker carefully crafts data in just the right way, they can trick the system into running any JavaScript code they want.

This happens because the framework didn’t properly check what type of data it was receiving. Instead of only allowing safe, expected types, it could be persuaded to reference internal types that were never meant to be exposed.

By chaining these types together, an attacker could eventually create a hidden (anonymous) function and then execute it, passing in malicious JavaScript. This chain can be disguised as a normal asynchronous process (using promises), which makes it harder to spot.

This kind of issue is commonly referred to as Remote Code Execution (RCE), one of the more serious categories of security vulnerabilities.

WHAT DID I DO?

The email linked to a page with clear instructions on what to do next, so the first thing I did was check my live sites that use Next.js and React.

I found one project running a vulnerable version. Then, a little later, I received another email pointing out additional issues so I had to update a more recent project too.

I followed the instructions on Vercel’s security bulletin: https://vercel.com/kb/bulletin/react2shell

Using the command line, I ran: npx fix-react2shell-next

After that, I added the changes, committed them, pushed everything up, and redeployed the projects.

While my hobby sites are unlikely to be the target of international cyber attacks, it still felt important to apply the fix. And for large organisations using Next.js at scale, this was obviously a much bigger and more urgent problem.

I also came across a really interesting Reddit thread where developers discuss how they’re handling this and similar vulnerabilities including detection, prevention, and staying ready to update quickly. You can read it here

A NEW ACRONYM FOR ME

One small but important thing I learned is that CVE stands for Common Vulnerabilities and Exposures.

CVE is a program that tracks and catalogues publicly disclosed cybersecurity vulnerabilities, making it easier for developers and organisations to talk about and respond to specific issues.

You can read more about it here: https://www.cve.org/

HOW TO PREVENT THESE VULNERABILITIES

This experience definitely reinforced a few basics for me:

• Use strong type checking
• Keep track of the versions of software I’m using
• Update dependencies regularly instead of letting them drift too far behind

None of this guarantees safety, but it massively reduces risk.

THIS ALSO GOT ME THINKING...

I found it interesting that I was notified about this vulnerability by Vercel, where my projects are hosted. It raised an interesting question for me: when should vulnerabilities be disclosed publicly?

On one hand, publishing details could encourage exploitation. On the other hand, people need to know about vulnerabilities so they can fix them.

This reminded me of an episode of Darknet Diaries where a man discovered serious vulnerabilities in his new router, including the fact that it didn’t require a password. He responsibly reported the issue to the company, but they mostly ignored his concerns. Eventually, he made the information public so people could protect themselves.

Personally, I’d want to know if my devices or software had security flaws, especially if fixing them was as simple as changing a setting or applying an update.

You can find the episode here: https://darknetdiaries.com/transcript/5/

FINAL THOUGHTS

This whole experience has made me realise I shouldn’t ignore those GitHub Dependabot emails I get. I have it enabled on one of my projects that isn’t live, so I hadn’t paid much attention to the alerts before. They are probably actually quite interesting!

Now, instead of seeing them as noise, I can see them as an opportunity to learn more about vulnerabilities and how they affect real projects.