❌

Normal view

There are new articles available, click to refresh the page.
Yesterday β€” 5 December 2025Main stream

From React to Remote Code – Protecting Against the Critical React2Shell RCE Exposure

5 December 2025 at 18:35

A critical remote code execution (RCE) vulnerability, dubbed β€˜React2Shell’, affecting React Server Components (RSC) and Next.js, is allowing unauthenticated attackers to perform server-side code attacks via malicious HTTP requests.

Discovered by Lachlan Davidson, the flaw stems from insecure deserialization in the RSC β€˜Flight’ protocol and impacts packages including react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack. Exploitation is highly reliable, even in default deployments, and a single request can compromise the full Node.js process. The flaw is being tracked as CVE-2025-55182. Originally tagged as a CVE for Next.js, NIST subsequently rejectedΒ  CVE-2025-66478, as it is a duplicate of CVE-2025-55182.

This blog post includes the critical, immediate actions recommended to secure your environment, new and existing Platform Detection Rules designed to defend against this vulnerability, and information on how SentinelOne Offensive Security Engine, a core component ofΒ  the Singularityβ„’ Cloud Security solution, allows our customers to quickly identify potentially vulnerable workloads.

What is React2Shell? Background & Impact

On December 3, 2025, the React and Next.js teams disclosed two related vulnerabilities in the React Server Components (RSC) Flight protocol: CVE-2025-55182 (React) and CVE-2025-66478 (Next.js), with the latter CVE now marked by NIST as a duplicate.

Both enable unauthenticated RCE, impacting applications that use RSC directly or through popular frameworks such as Next.js. These vulnerabilities are rated critical (CVSS 10.0) because exploitation requires only a crafted HTTP request. No authentication, user action, or developer-added server code is needed for an attacker to gain control of the underlying Node.js process.

The vulnerability exists because RSC payloads are deserialized without proper validation, exposing server functions to attacker-controlled inputs. Since many modern frameworks enable RSC as part of their default build, some teams may be exposed without being aware that server-side RSC logic is active in their environment.

Security testing currently shows:

  • Exploitation can succeed with near 100% reliability
  • Default configurations are exploitable, including a standard Next.js app created with create-next-app and deployed with no code changes
  • Applications may expose RSC endpoints even without custom server functions
  • A single malicious request can escalate to full Node.js process compromise

Security researchers warn that cloud environments and server-side applications using default React or Next.js builds are particularly at risk. Exploitation could allow attackers to gain full control over servers, access sensitive data, and compromise application functionality. Reports have already emerged of China-nexus threat groups β€œracing to weaponize” the flaw.

Available Vendor Mitigations & Immediate Actions

Fixes are available in React 19.0, 19.1.0, 19.1.1, and 19.2.0, and Next.js 5.x, Next.js 16.x, Next.js 14.3.0-canary.77 and later canary releases. Administrators are urged to audit environments and update affected packages immediately.

Companies are advised to review deployments, restrict unnecessary server-side exposure, and monitor logs for anomalous RSC requests. Securing default configurations, validating deserialized input, and maintaining a regular patch management schedule can prevent attackers from exploiting framework-level vulnerabilities in production applications.

  1. Update React by installing the patched versions of React as listed above.
  2. Update Next.js and other RSC-enabled frameworks as listed above. Ensure the latest framework and bundler releases are installed so they ship the patched React server bundles.
  3. Review deployment behavior by checking whether your organization’s workloads expose RSC server function endpoints. These may exist regardless of whether developers added custom server functions.

How SentinelOne Protects Our Customers

Cloud Native Security – Offensive Security Engine

SentinelOne’s Offensive Security Engine (OSE), core component of its Singularity Cloud Security solution, proactively distinguishes between theoretical risks and actual threats by simulating an attacker’s methodology. Rather than relying solely on static scans that flag every potential misconfiguration or vulnerability, this engine automatically conducts safe, harmless simulations against your cloud infrastructure to validate exploitability.

This approach delivers differentiated outcomes by radically reducing alert fatigue and focusing security teams on immediate, confirmed dangers. By providing concrete evidence of exploitabilityβ€”such as screenshots or code snippets of the successful simulationβ€”it eliminates the need for manual validation and β€œred teaming” of every alert. Shift from chasing hypothetical vulnerabilities to remediating verified attack vectors, ensuring resources are always deployed against the risks that pose a genuine threat to their environment.

In response to this vulnerability, SentinelOne released a new OSE plugin which can verify exploitability of these vulnerabilities for publicly accessible workloads using a defanged (i.e., harmless) HTTP payload.

Viewing Misconfigurations in the SentinelOne Console

SentinelOne customers can quickly identify potentially vulnerable workloads using the Misconfigurations page in the SentinelOne Console.

Search for:

React & Next.js (React Server Components) Versions 19.0.0–19.2.0 Vulnerable to Pre-Authentication Remote Code Execution via Unsafe Deserialization (CVE-2025-55182)

This highlights Node.js workloads that are exposing RSC-related server function endpoints. Once identified, affected assets can be patched or temporarily isolated. SentinelOne CNS also detects suspicious Node.js behavior associated with exploitation attempts, providing protection while updates are deployed.

It identifies verified exploitable paths on your publicly exposed assets, confirming which systems are truly at risk. By validating exploitability rather than simply flagging theoretical vulnerabilities, Singularity Cloud Security minimizes noise and provides concrete evidence so security teams can focus on what matters.

Wayfinder Threat Hunting

The Wayfinder Threat Hunting team is proactively hunting for this emerging threat by leveraging comprehensive threat intelligence. This includes, but is not limited to, indicators and tradecraft associated with known active groups such as Earth Lamia and Jackpot Panda.

Our current operational coverage includes:

  • Atomic IOC Hunting: We have updated our atomic IOC library to include known infrastructure and indicators from these threat actors, as well as broader intelligence regarding this campaign.
  • Behavioral Hunting: We are actively building and executing hunts designed to detect behavioral TTP matches that identify suspicious activity beyond static indicators.

Notification & Response All identified true positive findings will generate alerts within the console for the affected sites. For clients with MDR, the MDR team will actively review these alerts and manage further escalation as required.

Platform Detection Rules

SentinelOne’s products provide a variety of detections for potential malicious follow-on reverse shell behaviors and other actions which may follow this exploit. As of December 5, 2025, SentinelOne released new Platform Detection Rules specifically to detect observed in-the-wild exploit activity. We recommend customers apply the latest detection rule, Potential Exploitation via Insecure Deserialization of React Server Components (RSC), urgently to ensure maximum protection.

Additionally, SentinelOne recommends customers verify the following existing rules have also been enabled:

  • Potential Reverse Shell via Shell Processes
  • Potential Reverse Shell via Node
  • Potential Reverse Shell via Python
  • Reverse Shell via Perl Utility
  • Potential Reverse Shell via AWK Utility
  • Potential Reverse Shell via GDB Utility
  • Potential Reverse Shell via Lua Utility
  • Potential Reverse Shell via Netcat
  • Potential Reverse Shell using Ruby Utility
  • Potential Reverse Shell via Socat Utility

Conclusion

CVE-2025-55182 and CVE-2025-66478 represent critical risks within the React Server Components Flight protocol. Because frameworks like Next.js enable RSC by default, many environments may be exposed even without intentional server-side configuration. Updating React, updating dependent frameworks, and verifying whether RSC endpoints exist in your organization’s workloads are essential steps.

Singularity Cloud Security helps organizations reduce risk by identifying vulnerable workloads, flagging misconfigurations, and detecting malicious Node.js behavior linked to RCE exploitation. This provides immediate visibility and defense while patches are applied.

Learn more about SentinelOne’s Cloud Security portfolio here or book a demo with our expert team today.

Third-Party Trademark Disclaimer:

All third-party product names, logos, and brands mentioned in this publication are the property of their respective owners and are for identification purposes only. Use of these names, logos, and brands does not imply affiliation, endorsement, sponsorship, or association with the third-party.

This Week in Security: React, JSON Formatting, and the Return of Shai Hulud

5 December 2025 at 10:00

After a week away recovering from too much turkey and sweet potato casserole, we’re back for more security news! And if you need something to shake you out of that turkey-induced coma, React Server has a single request Remote Code Execution flaw in versions 19.0.1, 19.1.2, and 19.2.1.

The issue is insecure deserialization in the Flight protocol, as implemented right in React Server, and notably also used in Next.js. Those two organizations have both issued Security Advisories for CVSS 10.0 CVEs.

There are reports of a public Proof of Concept (PoC), but the repository that has been linked explicitly calls out that it is not a true PoC, but merely research into how the vulnerability might work. As far as I can tell, there is not yet a public PoC, but reputable researchers have been able to reverse engineer the problem. This implies that mass exploitation attempts are not far off, if they haven’t already started.

Legal AI Breaks Attorney-Client Privilege

We often cover security flaws that are discovered by merely poking around the source of a web interface. [Alex Schapiro] went above and beyond the call of duty, manually looking through minified JS, to discover a major data leak in the Filevine legal AI. And the best part, the problem isn’t even in the AI agent this time.

The story starts with subdomain enumeration β€” the process of searching DNS records, Google results, and other sources for valid subdomains. That resulted in a valid subdomain and a not-quite-valid web endpoint. This is where [Alex] started digging though Javascript, and found an Amazon AWS endpoint, and a reference to BOX_SERVICE. Making requests against the listed endpoint resulted in both boxFolders and a boxToken in the response. What are those, and what is Box?

Box is a file sharing system, similar to a Google Drive or even Microsoft Sharepoint. And that boxToken was a valid admin-level token for a real law firm, containing plenty of confidential records. It was at this point that [Alex] stopped interacting with the Filevine endpoints, and contacted their security team. There was a reasonably quick turnaround, and when [Alex] re-tested the flaw a month later, it had been fixed.

JSON Formatting As A Service

The web is full of useful tools, and I’m sure we all use them from time to time. Or maybe I’m the only lazy one that types a math problem into Google instead of opening a dedicated calculator program. I’m also guilty of pasting base64 data into a conversion web site instead of just piping it through base64 and xxd in the terminal. Watchtowr researchers are apparently familiar with such laziness efficiency, in the form of JSONformatter and CodeBeautify. Those two tools have an interesting feature: an online save function.

You may see where this is going. Many of us use Github Gists, which supports secret gists protected by long, random URLs. JSONformatter and CodeBeautify don’t. Those URLs are short enough to enumerate β€” not to mention there is a Recent Links page on both sites. Between the two sites, there are over 80,000 saved JSON snippets. What could possibly go wrong? Not all of that JSON was intended to be public. It’s not hard to predict that JSON containing secrets were leaked through these sites.

And then on to the big question: Is anybody watching? Watchtowr researchers beautified a JSON containing a Canarytoken in the form of AWS credentials. The JSON was saved with the 24 hour timeout, and 48 hours later, the Canarytoken was triggered. That means that someone is watching and collecting those JSON snippets, and looking for secrets. The moral? Don’t upload your passwords to public sites.

Shai Hulud Rises Again

NPM continues to be a bit of a security train wreck, with the Shai Hulud worm making another appearance, with some upgraded smarts. This time around, the automated worm managed to infect 754 packages. It comes with a new trick: pushing the pilfered secrets directly to GitHub repositories, to overcome the rate limiting that effected this worm the first time around. There were over 33,000 unique credentials captured in this wave. When researchers at GitGuardian tested that list a couple days later, about 10% were still valid.

This wave was launched by a PostHog credential that allowed a malicious update to the PostHog NPM package. The nature of Node.js means that this worm was able to very quickly spread through packages where maintainers were using that package. Version 2.0 of Shai Hulud also includes another nasty surprise, in the form of a remote control mechanism stealthily installed on compromised machines. It implies that this is not the last time we’ll see Shai Hulud causing problems.

Bits and Bytes

[Vortex] at ByteRay took a look at an industrial cellular router, and found a couple major issues. This ALLNET router has an RCE, due to CGI handling of unauthenticated HTTP requests. It’s literally just /cgi-bin/popen.cgi?command=whoami to run code as root. That’s not the only issue here, as there’s also a hardcoded username and password. [Vortex] was able to derive that backdoor account information and use hashcat to crack the password. I was unable to confirm whether patched firmware is available.

Google is tired of their users getting scammed by spam phone calls and texts. Their latest salvo in trying to defeat such scams is in-call scam protection. This essentially detects a banking app that is opened as a result of a phone call. When this scenario is detected, a warning dialogue is presented, that suggests the user hangs up the call, and forces a 30 second waiting period. While this may sound terrible for sophisticated users, it is likely to help prevent fraud against our collective parents and grandparents.

What seemed to be just an illegal gambling ring of web sites, now seems to be the front for an Advanced Persistent Threat (APT). That term, btw, usually refers to a government-sponsored hacking effort. In this case, instead of a gambling fraud targeting Indonesians, it appears to be targeting Western infrastructure. One of the strongest arguments for this claim is the fact that this network has been operating for over 14 years, and includes a mind-boggling 328,000 domains. Quite the odd one.

Before yesterdayMain stream
❌
❌