React2Shell and the Case for Deception in Your Vulnerability Management Program

Another day, another vulnerability. Deception offers a pragmatic path to detecting and blocking zero day exploits while augmenting vulnerability management programs to accelerate prioritisation and reduce team burnout.

On Dec 3, 2025, the React2Shell vulnerability was officially disclosed by the React team. Mere hours later, customers using Zscaler Deception technology had detailed, accurate evidence of exploits of this vulnerability in their environments. This fast, high-fidelity intel gave security teams in those organizations the ammo they needed to bring a full-court press to finding and eradicating this vulnerability.

Sometimes, it’s not enough to know your house has dangerous flammable materials that should be addressed – sometimes you need the proof that shows your house is already on fire. Deception can provide that action-inspiring proof.

An onslaught of vulnerabilities

Every environment has vulnerabilities. A subset of those vulnerabilities are exploitable. In the last month alone, NVD shows their analysts investigated 3223 CVE vulnerabilities. That’s about 100 vulnerabilities a day. 

These statistics translate to security teams being called into action almost every working day of the last month.  

This deluge of new CVEs adds to the continuous and ongoing stress that SOC and vulnerability management teams already experience. Being on such a “Here we go again…” treadmill can feel like we can’t stay ahead. It’s the highway to burnout. 

The promise of Unified Vulnerability Management

When new vulnerabilities like React2Shell emerge, a Unified Vulnerability Management program should be able to to answer the following questions, quickly: 

1. Do we have this vulnerability?
2. Does it affect assets we consider important?
3. What’s the blast radius if an exploit materialized?
4. Is there evidence that we are being targeted?
5. Should we stop other activities to chase down this issue?

In an ideal world, teams should know these answers in minutes, with a high degree of accuracy. 

But in the real world, we’re faced with the reality that:

• Vulnerability information is stored across multiple tools and often in spreadsheets.
• Asset and software inventory information is stored in disparate databases. 

This siloed data creates a knock-on effect in scoping and triage of the vulnerability and subsequent prioritization. 

No wonder the people responsible for mitigating these kinds of risks report feeling high degrees of stress. 

The communication challenge

Oftentimes, security teams have enough tooling to realize they have the vulnerability in question, but they lack the tooling needed to demonstrate or provide evidence of the risk to the business. This gap makes it challenging to marshall the resources needed to respond with sufficient speed and force to the risk at hand.  

Evidence converts theoretical risk to actual risk

Evidence is a crucial tool for communicating risk to the business. If you have evidence that a given issue in your environment is being scoped by bad actors right now, then all the other pieces needed to flesh out the story (what’s the vulnerability, the assets, the blast radius, etc) can take center stage. Until then, the risk is only theoretical – a company might dismiss it or not respond with the urgency the security team feels is needed. 

A lot of security teams and leaders have likely experienced this challenge. Consider the difference in impact of these two summaries of the situation:

• Without Evidence: “A React2Shell vulnerability has been disclosed. It affects 30% of our applications. Multiple partners and vendors have flagged this vulnerability as a burning issue.  We need to fix it right now.”
• With Evidence: “We have evidence that our environment is actively being probed for a vulnerability named React2shell.  It affects 30% of our applications. Multiple partners and vendors have flagged this vulnerability as a burning issue.  We need to fix it right now.” 

Such evidence is pivotal to spurring action. So where does this evidence come from? That’s where deception comes in. 

Perimeter-facing deception: A source of Private Vulnerability Exploitation Intelligence

Deception technology deploys realistic decoys (apps, APIs, credentials, breadcrumbs) that look and behave like production assets but have no legitimate business use. Any meaningful interaction with them (e.g.,  attempting to log in, suspicious requests, large traffic volumes) is a high-fidelity signal of adversary intent rather than generic noise.

When those decoys are placed at the perimeter, including public-facing web apps advertising common React frameworks, they do two things:

• Convert scanner noise into targeted reconnaissance: you see who is actively looking for your stack and patterns, not just sweeping Shodan-grade scans.
• Produce private, first-party threat intelligence: indicators tied to your environment (IPs, tools, payloads, paths, headers) that aren’t in public feeds yet.

This information is not open-source intel or paid feeds – it’s your own adversary engagement data, generated by your decoys, tuned to your attack surface, and available in minutes.

React2Shell: What Zscaler customers saw

Within hours of the React2Shell public disclosure, Zscaler customers using Deception detected activity against decoy applications deployed at the perimeter consistent with exploit patterns reported in the vulnerability. 

What we observed:

• 98 distinct source IPs probed and attempted exploitation across decoy endpoints.
• The majority of these IPs had not been published anywhere at the time of detection. Deception uncovered net new adversary infrastructure relative to public threat intel feeds.
• Deception generated clear, high-quality intelligence on the attack, showing what targets were being sought, the payloads being used, and confirming the use of automated tools and evolving attack strategies.

This data is private threat intelligence in action: first-party indicators, tailored to your stack, appearing before or in parallel with broader ecosystem reporting.

How Deception accelerates vulnerability management decisions

• Do we have this vulnerability? Correlate decoy interaction fingerprints to real asset inventory (versions, frameworks). If a decoy that mimics AppType A is being probed, your AppType A inventory gets priority.
• Does it affect assets we consider important? Map decoy-relevant tech to business-critical services. If decoys for Customer Portal tech are hit, scope that tier first.
• What’s the blast radius if an exploit materialized? Use adversary paths captured in decoys (endpoints, parameters, headers) to simulate exploit chains across similar apps. Prioritize lateral choke points.
• Is there evidence that we are being targeted? Yes/no becomes a metric, not a guess: targeted reconnaissance against your stack is a high-fidelity signal, not a heuristic.
• Should we stop other activities to chase down this issue? Deception alerts are high fidelity, especially in scenarios like React2Shell. If they fire, orchestration is justified—block, throttle, isolate, or accelerate patching for affected tiers.

Operationalizing perimeter deception in a Vulnerability Management program

Deception technology provides a quick and easy augmentation to your VM program. Here’s a gameplan that can rapidly increase your protection:

1. Place realistic decoys at known tech perimeter hotspots
   1. Mirror your common frameworks, versions, and routing conventions.
   2. Advertise plausible headers and cookies and build artifacts that attract framework-specific recon.
2. Instrument for early, actionable signals
   1. Log source IPs, tooling fingerprints, exploit paths, payload deltas.
   2. Tag decoy interactions by framework/asset class to align with inventory.
3. Automate enrichment and routing
   1. Auto-enrich IPs and payloads, but treat decoy hits as first-class, high-confidence events.
   2. Route “React-tier decoy hits” to VM owners for immediate scoping.
4. Tie alerts to patch workflows
   1. If decoy X (React) is probed, open patch tasks for all matching production assets.
   2. Gate deployment with runtime mitigations (WAF rules, feature flags) while patch cycles run.
5. Orchestrate protective controls
   1. Block or throttle the specific IPs engaging decoys.
   2. Redirect persistent adversaries deeper into high-interaction decoys to gather more intel safely.
6. Report what matters to the business
   1. “We’re seeing active reconnaissance against our React stack today.”
   2. “We’ve prioritized patching for Tier-1 customer apps; we’ve deployed interim WAF rules.”
   3. “We’ve captured exploit paths, and we have mitigation in place, with net new attacker IPs blocked.”
       

Reduce burnout for Vulnerability Management and SOC teams

Our security teams already work under incredible pressure. We have the tooling needed to spare them from some of the emergency conditions they often face. Deception helps by providing:

• Fast speed to signal: Minutes, not days, to confirm targeting and triage the right assets.
• Decision clarity: High-fidelity alerts reduce debate and unlock action.
• Better sequencing: Patch what’s probed first; defer what’s quiet without guilt.
• Fewer pivots: Decoy telemetry provides context so analysts spend less time stitching together tools.

Closing thoughts

Vulnerabilities are inevitable. Breaches are optional—if you can see exploit attempts early and act decisively, you can avoid being compromised. Perimeter-facing deception turns your attack surface into an early-warning sensor, generating private threat intelligence that feeds vulnerability management programs effectively. With signals like “98 net new attacker IPs probing your decoys,” you don’t plead for urgency—you prove the need and move fast.

If you’re already patching React2Shell, put decoys on the perimeter now. Let the adversary tell you which parts of your environment to fix first. Then meet them there with patches, mitigations, and blocks—on your terms.

Request a demo to learn more about Zscaler Deception.

Threat Research by: Deepak Keshav, Prajjwal Singh, and Sayan Mitra