Topic starter
08/07/2026 7:06 pm
TL;DR: React2Shell and Shai Hulud show how different attack paths can still leave the same operational question unanswered, because many security programmes cannot quickly determine whether they are exposed, according to RAD Security. Manual scanning and static analysis leave the blast radius unclear until containment is already harder.
Editorial analysis by NHI Mgmt Group, based on content published by RAD Security: “How RAD Helps Teams Answer the Only Question That Matters: Are We Exposed? Operational lessons from React2Shell and Shai Hulud, and how RAD closes the visibility gap.”.
Key questions
Q: What should security teams do first when they cannot tell whether they are exposed?
A: Start with a live exposure query that joins workload behaviour, package activity, and identity signals.
Q: Why do runtime-sensitive attacks defeat static scanning and manual investigations?
A: Because the risk depends on what the system is doing now, not only on what the code or configuration looked like earlier.
Q: What are the signs that exposure visibility is failing in practice?
A: The clearest signs are long gaps between detection and a confident scope answer, repeated dependence on subject-matter experts, and inconsistent blast-radius assessments across teams.
Practitioner guidance
- Map exposure questions to live runtime evidence Define which workloads, package chains, and identities must be queryable during an incident so the team can answer exposure without waiting for manual triage.
- Correlate package activity with credential use Track preinstall behaviour, publishing actions, and identity events together so recursive npm-style propagation can be detected as one chain rather than separate alerts.
- Validate vulnerable framework usage in production Identify where React Server Components or similar runtime-sensitive frameworks are deployed, then confirm whether production behaviour matches the assumptions made during code review.
Bottom line: React2Shell and Shai Hulud show that different exploit paths can still produce the same operational failure: teams cannot determine exposure quickly enough to contain it.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
08/07/2026 7:30 pm
Exposure is now a runtime governance problem, not a scanning problem. React2Shell and Shai Hulud do not just demonstrate different attack mechanics. They show that the decisive question is whether defenders can determine affected scope while the system is still changing. Programmes that rely on best-effort scans and tribal knowledge cannot answer that question at containment speed. The practitioner conclusion is to treat exposure as a live state, not a periodic assessment.
A few things that frame the scale:
- Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: How should teams organise accountability for exposure decisions during an incident?
A: Assign ownership before the incident for who can declare scope, who can interpret runtime telemetry, and who can approve containment. Exposure management fails when those decisions are distributed informally across code, cloud, and identity teams with no single accountable path.
👉 Read our full editorial: Runtime exposure checks for React2Shell and Shai Hulud risks