What We Actually Saw in the Wild After the React RCE CVE Dropped

When the recent React RCE CVE went public, most posts focused on what the vulnerability is and how the exploit works. That information is fine, but it is not what mattered the most once real traffic started hitting our systems.

This write-up focuses on what we observed in live traffic during the first few days, including the patterns that stood out and what ultimately helped us tune detections without causing regressions.

One observation became clear early on: the most meaningful activity wasn’t the exploit itself, but the reconnaissance that preceded it.

Why this CVE was tricky at the start

When the disclosure dropped, there was very little clarity on the exact payload structure. You could recognize that React flight requests were involved, but you did not start with a clean set of known bad payloads. That meant any immediate rule would either be too loose or too aggressive.

If you maintain runtime detections, this is a familiar tension: a rule that is too broad risks breaking your application, while a rule that is too specific may fail to provide meaningful protection. 

Paradoxically, the lack of complete information is what makes early traffic so valuable. It exposes the behavioral boundaries needed to strike that balance without overcorrecting.

What we saw: most activity was reconnaissance, not exploitation

Once we started sampling traffic, one pattern became obvious very quickly.

Attackers often do not begin with the exploit. They begin with probes.

Some examples from our logs:

• Flight request–shaped traffic containing values inconsistent with real request flows
• Headers that looked structurally correct but made no sense semantically
• User agents that literally included the CVE number or the name of the scanner
• Payloads designed purely to determine whether the target was running React, rather than to deliver a functional exploit

These were not real requests and not complete exploits. They were checks. In a few cases, the requests were so blatant that they were almost funny, but the behavior itself is common.

Why this matters: if a source is already checking whether you are vulnerable to a brand new RCE, that is a useful signal even if they never send the full exploit. In several cases, the same sources tried unrelated attacks later once they seemed to realize the React vector would not land.

A scoring model made this easier than a simple allow or deny rule

Many WAF-style systems treat this class of issue as a binary decision: does the payload match a known exploit signature or not? While that approach works for some cases, it misses two important aspects of real-world attacks:

1. The reconnaissance phase and
2. Payloads that do not yet match any published pattern.

We switched to a small scoring model rather than a single-match rule. It looked like this.

Low score: Likely reconnaissance. Shaped like a React request but containing obviously bogus values. Something to record, not something to block immediately.

Middle score: Probably a legitimate flight request from a real application. Especially if the response is not an error.

High score: Exploit attempt. These had very specific indicators such as certain keys, object fields, or header combinations.

This approach allowed us to do three things at the same time.

1. Block high-confidence attacks
2. Record low and medium confidence activity for analysis
3. Avoid breaking the application during the first 48 hours

A binary system forces you to choose between being too aggressive or too permissive. A small scoring range gives you room to observe without causing outages.

Recon as an early warning signal

One concrete example involved a set of requests from a Russian IP range. The user agent included the CVE identifier and the word scan. The body looked like a React flight request but with completely invalid values. It was not an exploit. It was a probe.

Even that is enough to treat the source as suspicious. Many teams wait for the exploit attempt before tagging a source. In practice, the earlier signal is often more reliable.

Why it helped to save payloads during the first 48 hours

When a new CVE is released, attackers generate a large volume of noisy traffic as they experiment. If you are not saving payloads during this period, you lose the opportunity to understand:

• Obfuscated variants Structural anomalies that do not match public examples
• Payloads that use different encodings
• Edge cases that will eventually produce false positives or false negatives

Once we saved and deduped payloads, most of them collapsed into a small set of variants. The outliers were the ones worth studying. Feeding these into offline analysis helped us tighten the scoring without guessing.

This is one place where AI was actually useful. Not writing rules for us, but grouping and comparing payloads at scale.

Practical takeaways for AppSec teams

Here are a few things that ended up being helpful.

• Capture reconnaissance. It tells you who is scanning you before the exploit arrives.
• Record all suspicious payloads during the first couple of days. You will learn more from these than from published signatures.
• Use a scoring model instead of a single rule. Even three levels low, medium, high is better than a binary match.
• Deduplicate payloads. Most traffic is repetitive. The unique samples are the ones that matter.
• Feed the observations back into your detection logic. The first rule you write will almost never be the final one.
• Treat recon as a reputation signal. If a source is already probing you, treat later activity differently.

None of this requires a particular tool. It does require handling runtime detection as a learning problem rather than a simple pattern-matching problem.

Closing thoughts

CVE announcements usually create urgency for AppSec teams. They can also create useful opportunities to improve detections. If you treat the early window as a data gathering period, you end up with better-tuned rules, fewer false positives, and a clearer picture of attacker behavior.

The exploit matters. The reconnaissance tells the real story. If you pay attention to it, you become more accurate long before the rest of the industry releases updated signatures.