Recently we had an issue with a Nextjs frontend where it was compromised by an application mining coin.

Our servers are behind a VPN that protects the ssh port 22, and we found the intruders at frontend root. We know there’s a recent active exploit that targets frontends such as we use because we’re fixing it for our clients.

How Our Own Blog Became a Cryptomining Target

Let’s identify the exploit and explain how it works. I ask My AI.

Based on the most recent and relevant information, the exploit that likely compromised your Next.js frontend is CVE-2025-66478 (also referred to as the Next.js variant of “React2Shell,” with the React vulnerability tracked as CVE-2025-55182).

This is a critical, unauthenticated remote code execution (RCE) vulnerability affecting Next.js applications using React Server Components (RSC). It was publicly disclosed in late November 2025 and is actively being exploited as of now, December 2025.

As I mentioned, we know about the vulnerability and are working to provide protection for our clients platforms. But we were too late for this one, our own blog. Yes, might be reading this story on that very platform.

The attackers first placed an instance of the mining tool xmrig on December 6 18:12. We noticed it almost immediately and removed it.

However then an application was placed that proceeded to run docker. At that point we decided to spin up a new server and power down the affected node.

How the Exploit Works: A Step-by-Step Breakdown

I turn to My AI, ask: How is this kind of exploit possible with React2Shell, CVE-2025-66478?

There’s a vulnerability in React Server Components that's exploited by issuing an HTTP request to your Nextjs application.

Due to insecure deserialization in the React Server Components (RSC) Flight protocol, the server executes attacker-controlled JavaScript code.

1️⃣ Attacker sends a malformed Flight protocol payload via HTTP request to a vulnerable Next.js/React Server Component endpoint.

2️⃣ Insecure deserialisation in the server’s Flight protocol handler processes the payload without proper validation.

3️⃣ Malicious payload triggers unintended server-side execution, leading to Remote Code Execution (RCE).

4️⃣ Attacker gains control over the server process, allowing further actions like deploying cryptominers, stealing data, or pivoting deeper into the network.

Who’s Exploiting React2Shell?

Let’s dive into about the organisations or companies behind the exploits. Do they develop attack vectors themselves? Do they work for clients? Where are they located?

Those behind the exploitation of CVE-2025-55182 (React2Shell) are primarily state-nexus groups. Think China. Have weird names like Earth Lamia and Jackpot Panda.

They’re known for rapid adoption of newly disclosed vulnerabilities, using automated tools with evasion techniques to avoid detection. They may develop or adapt exploit code internally, sometimes based on public PoCs, where legitimate developers share information about potential exploits. They may also purchase or share exploits within their networks.

State-backed groups are typically looking to harvest credentials, sensitive data, or set up access for future operations. Like installing docker.

Ok.

Why Monero and Who’s Likely Involved?

The fact that this exploit placed mining software on our server denotes cybercrime rather than state actors. Which coin variant and which organisations are likely to be involved?

The deployment of XMRig mining software in your incident strongly indicates cryptojacking by cybercriminal groups. XMRig is designed to mine Monero, which is favoured by cybercriminals because it is privacy-focused, making transactions harder to trace. Monero’s value surged in early 2025, making it a prime target for illicit mining campaigns.

And from where?

The use of XMRig and the rapid deployment after the React2Shell disclosure point to opportunistic cybercriminals, likely from Eastern Europe or Russia, rather than state-sponsored actors.

The Pros and Cons of Tiny Nodes

Two things I found interesting: 1) We’ve been using tiny nodes on subdomains for distinct sections of our applications. For example one of our clients runs a large number of different domains, and we run groups of them on a tiny node, just 1 cpu 2gb ram. That means that the exploit, this exploit at least, has immediate impact, it eats 100% so our application goes down and triggers our monitoring system.

And 2) In the case of the exploited instance, the separation went much further, we were running a blog (this blog, if you’re reading this on our own platform) that’s completely independent from our website, with a backend behind VPN and only the tiny node exposed to http ports.

My question is if this strategy, which looks a little like the classic load balancer / node architecture but isn’t quite the same, is actually advantageous?

Both advantages and risks, says My AI.

Running distinct sections (e.g., blogs, microservices) on separate tiny nodes limits blast radius. A compromise in one node doesn’t immediately threaten your entire infrastructure or backend.

Small, disposable nodes make it easy to spin up replacements quickly, reducing downtime. And resource exhaustion (e.g., 100% CPU from XMRig) triggers alerts faster than on larger, shared servers, enabling rapid response.

However.

Tiny nodes are more vulnerable to resource starvation attacks, as you experienced. And more importantly, each exposed node is a potential entry point. Expanding your potential vulnerability.

Plus, it’s not redundant like a true load balancing setup. Nodes need to be spun up manually.

Automate node replacement and patching and you have a system.

How Cybercriminals and Defenders Are Leveraging AI

One last remark. We as a software company use coding agents to an increasing degree. But this will also be the case for cybercriminals. Are there any estimations as to which extent AI is used in cybercrime? Are AI companies aware of this, and what could they possibly do? Is there a threat of an arms race between cybercrime and the rest of us?

🤖 AI is now central to cybercrime, powering 80%+ of phishing, malware, and fraud. Cybercriminals use AI agents for autonomous attacks, while defenders race to deploy AI-driven protections.

AI companies are responding with safeguards and partnerships, but the arms race is intensifying, with global costs hitting $10.5T/year.

👦 Do you mean that the costs of combating cybercrime is as much as the GDP of a small country?

🤖 Exactly. Or actually, not a SMALL country. It’s comparable to the GDP of major economies.

10.5 trillion is roughly the combined GDP of Japan and Germany, or more than double the GDP of India.

It’s a staggering figure that reflects not just direct financial losses (theft, ransomware, fraud), but also the cost of defence, recovery, insurance, lost productivity, and reputational damage across the global economy.

👦 Thanks for the reassuring words, My AI. Let’s start patching.