Your Website's Frontend just became a Backdoor, and on the Future of Cyber Attacks.

6.2%¹ of all websites in the world use React.js. According to multiple sources^{2 3 4}, that's around 55-87 million out of 1.1-1.4 billion websites, from which around 200 million are active (however those statistic providers define "active").

Since React is a rather modern framework, we can assume that websites using React on average are more likely to be active than inactive.

Yesterday a CVSS-10.0-rated vulnerability was patched under CVE-2025-55182⁵ (and the Next.js descendant⁶). That's the most severe value on the rating system. And it probably has lived inside the library since React officially introduced RSC in v19 on 5th December 2024⁷ (coincidentally only 2 days short of a year later). However, the feature was accessible since December 2020 and could be used in alpha, beta and canary products (how can you call yourself tech bro without using pre-release features in business-critical production systems?).

But this post is not about the vulnerability in particular. It's about a foreshadowing of the future in software products as I see it.

Thesis

With AI and increasing infrastructure all over the board, and automation gaining huge popularity, software vulnerability discoveries as well as their practical exploitation might become more severe and frequent than ever before.

My thesis is that AI's ability to provide and understand context within arbitrary text - including code - makes software vulnerabilities easier to discover and automatable, while the attack surface is likewise increasing (more produced and deployed code).

In addition, tech companies make up a monumental share of the stock market. Not to mention virtually every company that is not classified as tech companies has exploitable tech infrastructure. This creates massive incentive for large-scale cyberattacks and digital heists. And while there are good players trying to be on the other side trying to use AI to find vulnerabilities, and OSS patches are coming in hot, in the end it's an arms race. And I feel that right now the incentive growth rate is significantly higher for bad actors.

To put this into words for non-technical business owners, an attacker could use AI to:

1. Find a vulnerability in a code base of a popular and widely integrated library.
2. Automate discovery of the library usage (which is especially easy for websites, but could potentially be done in creative ways with AI for non-front-facing and internal services).
3. Automate vulnerability identification and confirmation (e.g. "filter out secure systems") by running a naive and preliminary attack on those targets. This step is optional and could be consolidated into step 4, subject to the attackers taste of implementing his attacks.
4. Run a more sophisticated, potentially AI-directed attack on the known vulnerable targets. Or, inject a human into the attack where he sees fit.

Now, to run this requires solid infrastructure and preparation work, and would most likely be conducted by organizations. And if you think that there are no organizations in the world doing this right now, you probably think that the scammer who tried convincing you to tell him your Bitcoin private key is doing it from his personal iPhone instead of from a dark, dystopian, call center spanning five floors in your friendly neighborhood's skyscraper.

How could this attack look on "CVE-2025-55182"?

First, let's make a few educated guesses and assumptions about what this vulnerability is and what capabilities it provides the attacker.

Specific technical details on the attack vector have not been published by the React maintainers or other public institutions to prevent the spread of the exploit and protect React.js users.

The vulnerability implies that an attacker can get arbitrary access to code on the server side. Most famously used by Next.js' "server actions" Reacts' RSC feature uses "magic" to glue the client to the server. This means (to my personal interpretation) that it might allow a client to execute a close-to-direct function on the server, although the core issue is arguably insecure deserialization of untrusted inputs. The app developer intended to expose only one specific, well-defined action for a valid use case, of course. Unfortunately - other than with conventional HTTP API requests - the server action exposes the whole server code by design, and then makes sure the correct piece of code is executed.

If an attacker was somehow able to bypass the request validation and execute any other than the intended function, he could potentially gain access to anything that's bundled within the server action. That means he could be able to access a database (or Stripe) client with service permissions - at which point none of the commonly developer-written security measures like a user-authenticated database client (or nowadays popular Row Level Security (RLS) rules) matter. You are vulnerable from the moment you made the design decision to use server actions.

This would explain why the vulnerability is classified at the highest 10.0 severity.

Beyond blog posts and PR yapping many companies have private and proprietary business-related data inside databases that are connected to their websites.

Now, if an evil institution was to start a large-scale attack on websites using React.js, it could

1. Find and understand CVE-2025-55182 (utilizing LLMs)
2. Get a list of all sites using React (let's pray the hacker uses a free n8n workflow from LinkedIn)
3. Create a naive script that tests the vulnerability
4. finally run the attack with an AI Exploit-agent (and optionally a human in the loop) to adjust and customize, or even iteratively improve every attack execution.

By the way, Anthropic reported a malicious entity using Claude to do this not too long ago⁸.

A concerning real-world circumstance is that many businesses

1. do not actively maintain their website
2. do not know what it's built on
3. how it's built
4. often even what it does
5. or how much it potentially exposes them

The owners handed the keys to a freelancer or agency who vanished post-launch, and might have no idea that they are exposed.

Postscript

On the bright side, since AI accelerates everything, and software as businesses move faster than ever before, vulnerabilities will likely be identified and closed much faster than ever before. This is a huge point, because it leaves an attacker practically no time to setup the attack unless the attacker discovered the exploit. CVE-2025-55182 was closed within 5 days of the report and hit the public only after it was patched. Since the era of SQL injections ended in the early days of PHP, the time to become more vigilant about securing our infrastructure may be back again.

The future is volatile.