Detecting React2Shell with Kiuwan: A Practical Guide for AppSec Engineers

A critical deserialization flaw in React Server Components demands immediate attention—here’s how to find it in your codebase.

The application security community is responding to React2Shell (CVE-2025-55182), a maximum-severity vulnerability affecting React Server Components that security researchers are comparing to Log4Shell. With a Common Vulnerability Scoring System (CVSS) score of 10.0, unauthenticated remote code execution capabilities, and active exploitation already observed in the wild, this vulnerability represents an urgent priority for any organization running React or Next.js applications.

The good news? If you’re using Kiuwan for your application security testing, you have multiple detection vectors at your disposal. Let’s walk through how to leverage static application security testing (SAST), software composition analysis (SCA), and custom rules to identify and remediate this threat.

Understanding React2Shell

Before diving into detection, it helps to understand what we’re dealing with. React2Shell exploits unsafe deserialization in the React Flight protocol, the mechanism React uses to communicate between client and server in React Server Components (RSC).

How the vulnerability works

An attacker crafts a malicious HTTP payload that injects metadata pointing to dangerous prototype-chain properties. When React’s server-side request decoding logic processes this payload, it deserializes attacker-controlled input unsafely, achieving arbitrary code execution on the server.

What makes this particularly dangerous:

• No authentication required
• No user interaction needed
• Exploitable even if your app doesn’t explicitly use Server Functions—merely supporting React Server Components is enough
• Affects approximately 39% of cloud environments according to Wiz’s analysis

The affected components include:

Additionally, frameworks that embed these packages are affected: React Router, Waku, RedwoodJS, Vite RSC plugin, and Parcel RSC.

Detection strategy 1: Software Composition Analysis (SCA)

Your first line of defense is Kiuwan Insights, which performs Software Composition Analysis to identify vulnerable third-party components in your applications.

How to check for vulnerable React packages

1. Navigate to your application’s Insights dashboard in Kiuwan
2. Review the Components tab for any React or Next.js dependencies
3. Filter by severity to surface Critical vulnerabilities—CVE-2025-55182 carries the maximum CVSS score
4. Check transitive dependencies—remember that Next.js vendors React internally, so traditional dependency tools may not automatically flag it

What to look for

Search your component inventory for:

• react-server-dom-webpack
• react-server-dom-parcel
• react-server-dom-turbopack
• next (versions 14.3.0-canary.77 through 16.x)

Kiuwan’s SCA engine will automatically correlate these components against known CVE databases, flagging CVE-2025-55182 and CVE-2025-66478 (the Next.js-specific identifier) when detected.

Pro tip

Set up a continuous monitoring policy that alerts your team whenever new Critical vulnerabilities are discovered in components already present in your codebase. This ensures you’re notified immediately when threats like React2Shell emerge, rather than waiting for your next scheduled scan.

Set up a continuous monitoring policy that alerts your team whenever new Critical vulnerabilities are discovered in components already present in your codebase. This ensures you’re notified immediately when threats like React2Shell emerge, rather than waiting for your next scheduled scan.

Detection strategy 2: Custom SAST rules for string detection

While SCA catches the vulnerable packages themselves, there’s an additional layer of protection available through Kiuwan’s custom rule capabilities. This approach proved invaluable during the polyfill.io compromise and applies equally well here.

Why string-based detection matters

Some attack patterns involve hard-coded references to malicious endpoints, compromised package names, or known exploit signatures. By creating custom rules that search for specific string constants in your codebase, you can:

• Detect references to deprecated or vulnerable package versions in configuration files
• Identify any hard-coded imports of affected RSC packages
• Catch potential exploit payloads in test files or documentation that shouldn’t be there

Creating a React2Shell detection rule

Using Kiuwan’s Rules Management feature, you can create a custom JavaScript/TypeScript rule that flags occurrences of the vulnerable package names.

Rule configuration:

• Language: JavaScript, TypeScript
• Rule Type: String detection
• Severity: Critical
• Strings to detect:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
  • @next/react-server-dom

Extending the rule for version detection

For more granular detection, extend your rule to catch specific version strings in package.json and package-lock.json files:

"react-server-dom-webpack": "19.0.0"
"react-server-dom-webpack": "19.1.0"
"react-server-dom-webpack": "19.1.1"
"react-server-dom-webpack": "19.2.0"

This approach provides a low-cost safety net that complements your SCA scanning, catching references that might slip through more complex analysis.

Detection strategy 3: SAST analysis for dangerous patterns

Beyond composition analysis, Kiuwan’s SAST engine can help identify code patterns that might indicate exploitation attempts or unsafe deserialization handling.

Patterns to monitor

Configure your Kiuwan model to flag:

1. Unsafe deserialization patterns in server-side JavaScript
2. Dynamic property access on server function metadata
3. Prototype pollution indicators that could be leveraged in an exploit chain

While these won’t directly detect React2Shell, they represent defense-in-depth measures that help identify code that might be vulnerable to similar deserialization attacks.

Remediation: What to do when Kiuwan finds vulnerable components

Once you’ve identified affected applications, remediation is straightforward:

Patched versions

Immediate actions

1. Update React and Next.js to the patched versions listed above
2. Redeploy affected applications after updating
3. Verify remediation by running a fresh Kiuwan scan
4. Enable Web Application Firewall (WAF) protections if available—Cloudflare and AWS have deployed protective rules
5. Monitor logs for exploitation attempts: (threat actors are actively probing for this vulnerability)

If you can’t patch immediately

• Implement WAF rules to block malicious RSC payloads
• Review network segmentation to limit blast radius
• Prioritize patching for internet-facing applications

Building long-term resilience

React2Shell follows a familiar pattern: a critical vulnerability in a ubiquitous component that requires rapid response across the industry. Here’s how to position your security program for the next incident:

Operationalize Kiuwan for supply chain threats

1. Schedule regular scans of all applications, including those in development
2. Create alerting policies for Critical and High severity findings
3. Maintain custom rules for known-bad strings, domains, and packages
4. Review your SBOM regularly to understand your true dependency footprint

Document your detection and response process

When React2Shell hit, organizations with established processes responded faster. 

Be sure to document:

• Who receives alerts from Kiuwan
• Escalation paths for Critical vulnerabilities
• Patching SLAs by severity level
• Communication templates for stakeholders

Bottom line

React2Shell represents exactly the kind of supply chain threat that modern AppSec programs must be prepared to handle: a maximum-severity vulnerability in foundational infrastructure, with active exploitation beginning within hours of disclosure.

Kiuwan users have multiple tools to detect and respond to this threat. SCA scanning identifies vulnerable components automatically, custom string-detection rules provide an additional safety net, and continuous monitoring ensures you’re notified immediately when new vulnerabilities affect your stack.

The question isn’t whether another Log4Shell-scale vulnerability will emerge—it’s when. By building robust detection capabilities now, you’ll be ready when it does.

Ready to verify your React2Shell exposure? Run a fresh scan in Kiuwan today, and consider implementing custom string-detection rules for additional coverage. For more information on rules management, visit the Kiuwan support documentation.

*This technical note was prepared for Kiuwan users and AppSec engineers responding to the React2Shell vulnerability disclosure. 

About the author

JD Burke is a seasoned technology professional with over 20 years of experience in product management and application security, currently serving as Director of Security Products at Sembi. His deep expertise in application security testing spans SAST, SCA, and DevOps integration, demonstrated through senior technical roles at leading cybersecurity companies including Snyk, CyberRes/Fortify, and Kiuwan. His technical foundation includes systems architecture experience. He combines strong product management skills with hands-on application security knowledge, having successfully led cross-functional teams through strategic planning, feature development, and market positioning while maintaining expertise in vulnerability assessment, compliance frameworks, and security tool integration.