From Disclosure to Detection: How we responded to react2shell

"How long between disclosure and when react2shell was available as a check in Burp DAST?"

Attendee question, Better Together webinar Q&A

When a new vulnerability class drops, the question most teams ask first is "can our scanner detect this?" The better question is what happens between disclosure and the moment your scanning infrastructure actually has coverage. That gap says more about your DAST tool than any feature comparison sheet.

We're going to answer the question above, but the timeline is only half the story. The other half is what happened after the check existed.

How we assessed react2shell

Disclosure

React2shell is publicly disclosed.

Research picks it up (same day)

Our Research team identified the disclosure and began assessment within hours.

Assessment

Three questions determined priority:

Exploitability: Could this be reliably triggered in production applications, or was it theoretical?
Prevalence: How many applications in the wild were likely running affected React configurations?
Detection feasibility: Could we write a scan check that identifies vulnerable instances without false positives?

Prioritization

The Research team concluded react2shell was both exploitable and likely to appear across a meaningful number of production environments. It went to the top of the queue.

Development and testing

A custom scan check was developed, tested against real vulnerable configurations, and validated across a range of deployment patterns.

Available to customers

The check was available within X hours/days of the original disclosure.

For a practitioner working in Burp Suite Professional, that scan check was immediately useful. But the people asking the question at our webinar aren't responsible for one application. They're responsible for hundreds.

From one application to two hundred

Customer snapshot

Mid-sized financial services firm. AppSec team of six. 200+ web applications.

When react2shell dropped, their senior pentester ran the scan check against the three applications they considered highest risk. Two came back clean. One was vulnerable.

That confirmed the issue was real in their environment. But checking 200 applications one by one in Pro wasn't realistic. Their team loaded the same scan check into Burp Suite DAST and ran it across the full portfolio. Within timeframe, they had a clear picture: results. The findings came through in the same format their pentesters already work with, so triage started immediately rather than after a translation step.

The key detail: Same scan check. Same detection logic. The pentester's manual investigation and the automated estate-wide scan used identical detection, because Pro and DAST share the same scanning engine.

Three questions for your DAST evaluation

When you're evaluating DAST tools, detection rates on established vulnerability classes are table stakes. What separates tools is what happens when something new appears.

How quickly do new vulnerability classes get added after public disclosure?
Does the detection go through the same engine your pentesters trust?
Can you deploy new checks at scale without waiting for a formal release cycle?

How we think about response time

We'd rather show you how we actually respond to a new vulnerability class than claim a response time we can't consistently deliver. Some disclosures result in a scan check within hours. Others take longer, because the vulnerability is harder to detect reliably, or because the affected configurations are more varied than they first appear. Speed matters, but accuracy matters more.

If you'd like to see more of how this workflow plays out, including a case study showing the same bi-directional flow with a different vulnerability, that post is here.