Recently, many React/Next.js projects were affected by the React2Shell remote code execution, a critical score 10 vulnerability. This vulnerability has affected the developer community badly, compromising countless servers and deployments. Even if your app seems to be working fine, your system might still be compromised.
As someone who is new to Next.js and has been tracking this issue closely to avoid any such compromise, I want to share some quick but effective checks that every developer should run to get an initial sense of their system's health.
Understanding the Threat
The React2Shell, a critical vulnerability in React Server Components affecting React 19 and frameworks that use it like Next.js (v15.0.0-v16.0.6), allows attackers to execute arbitrary code remotely. The concerning part is that you might not notice anything wrong right away. Your app might continue to work normally while malicious processes run in the background, quietly mining cryptocurrency or creating backdoors.
December 11, 2025 Update: Two Additional Vulnerabilities Discovered
After React2Shell was announced, developers started looking more into React Server Components and found two more vulnerabilities that need fixing:
- CVE-2025-55184 (High Severity): Denial of Service vulnerability
- CVE-2025-55183 (Medium Severity): Source Code Exposure vulnerability
Both affect React 19 and frameworks that use it, like Next.js. The good news is that neither of these new issues allow for Remote Code Execution, but better you patch these soon to prevent service disruptions and potential information leakage.
Quick Health Checks
Here are several critical checks you should perform immediately if you suspect your system might be compromised:
1. Check for Abnormal Resource Usage
After exploitation, many attackers deploy crypto-mining or persistent background processes. If CPU usage stays unusually high for extended periods, investigate immediately.
Open your system monitor or run the following commands to check resource usage:
top
# or for a more detailed view
htopLook for processes consuming abnormally high CPU or memory, especially ones you don't recognize.
2. Scan for Suspicious Processes
This command helps surface unexpected non-root processes often associated with mining or injected scripts:
ps aux | grep -v root | grep -E "kwork|crypt|mine|xmr|node|python"Pay close attention to any processes with suspicious names or those running from unusual locations like /tmp or /dev/shm.
3. Review Cron Jobs
Attackers often add persistence via scheduled tasks. Check your cron jobs to ensure nothing malicious has been added:
crontab -l
sudo ls -al /etc/cron*Look for cron entries you did not configure. Be especially wary of jobs that download and execute scripts, or those that run at unusual intervals.
4. Review System Users
Check if any unfamiliar user accounts were created:
cat /etc/passwd | grep -v "nologin"Any user accounts you don't recognize should be investigated immediately, as attackers sometimes create new users to maintain access.
5. Inspect Common Malware Directories
Many payloads hide in temporary directories. Inspect these locations for suspicious files:
ls -al /tmp
ls -al /var/tmp
ls -al /dev/shmIf you see unknown executables, scripts, or oddly named folders, inspect them further. Be particularly cautious of hidden files (those starting with a dot).
6. Check for Recent Suspicious File Changes
This command lists modified system and runtime files from the last 48 hours:
sudo find / -mtime -2 2>/dev/null | grep -E "bashrc|profile|node|npm|.config"You can increase the -mtime value (e.g., -5 for 5 days or -7 for 7 days) to extend the investigation window based on when you suspect the compromise may have occurred.
Look for modifications to shell configuration files, Node.js installations, or NPM global packages that you didn't make.
7. Verify npm and Node.js Binaries
Many attacks modify global installations by replacing or tampering with npm and Node.js binaries. Check if your installations are pointing to the correct locations:
which node
which npm
ls -al $(which node)
ls -al $(which npm)Look for any unexpected paths or symlinks. Common locations that attackers target include:
/usr/local/bin/npm/usr/bin/node$HOME/.npm-global
If these binaries are pointing to unusual directories like /tmp or /var/tmp, that's a red flag.
Important Considerations
These checks are not a comprehensive security audit, but they help quickly surface anomalies that warrant further investigation. It's written to give you an initial sense of whether your system has been compromised.
If anything looks suspicious during these checks:
- Isolate the machine immediately from your network
- Rotate all credentials that were accessible from the compromised system
- Perform a deeper investigation or consult with a security professional
- Consider a clean reinstall if the compromise is confirmed
Prevention and Best Practices
Beyond checking for existing compromises, here are some preventive measures:
- Keep your React, Next.js, and all dependencies up to date
- Regularly audit your
package.jsonandpackage-lock.jsonfor suspicious packages - Use tools like
npm auditandsnykto scan for known vulnerabilities - Implement proper access controls and run services with minimal privileges
- Monitor your systems regularly, not just during security incidents
Conclusion
The React2Shell vulnerability is a reminder that security isn't a one-time thing - it's an ongoing responsibility. Even if you haven't been affected, it's worth running these checks regularly to keep your systems healthy.
Stay safe, keep your stacks patched, and don't hesitate to investigate anything that seems off.
Have you been affected by React2Shell or found something suspicious using these checks? I'd love to hear about your experience and any additional security measures you've implemented.
Stay vigilant and happy coding!