Runtime exposure checks for React2Shell and Shai Hulud risks

At a glance

What this is: RAD Security argues that React2Shell and Shai Hulud expose the same operational weakness: many programmes cannot quickly determine whether they are affected in their own environment.

Why it matters: IAM, NHI, and security teams need runtime visibility because exposure questions now depend on how code, identity, and workloads behave together, not on static inventory alone.

Context

React2Shell and Shai Hulud are different threats, but they create the same governance problem for security teams: proving whether the environment is exposed fast enough to contain the blast radius. That question sits at the junction of application behaviour, identity signals, and runtime telemetry, which is why static analysis alone is not enough.

The article frames exposure as an operational decision problem, not a post-incident reporting exercise. If teams cannot correlate code paths, package activity, and runtime behaviour quickly, they lose the window in which containment still changes the outcome.

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. The first goal is not root cause. It is to identify which assets may still be participating in the attack path so containment decisions can be made before the blast radius grows.

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. Static tools may miss behaviour that only appears in execution, while manual investigations are too slow to preserve a containment window.

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. If one group says a workload is affected and another cannot confirm, the programme does not yet have operational exposure visibility.

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.

Technical breakdown

Why static detection fails for React2Shell-style exposure

React2Shell exploits a server-side behaviour rather than a simple signature or known malicious file. When deserialised payloads can trigger unauthenticated remote code execution, the relevant question becomes whether a workload accepts the vulnerable pattern at runtime, not whether a scanner found a named exploit string. Static tools struggle here because the risk depends on framework behaviour, request handling, and deployment context. A system may look clean in code review and still remain exposed in production if permissive defaults are present.

Practical implication: verify exposure against live workload behaviour, not code status alone.

How recursive package compromise changes the exposure problem

Shai Hulud spreads through poisoned npm packages and uses preinstall scripts to steal credentials, then reuses those credentials to publish more compromised packages. That creates a recursive infection path where the initial package compromise is only the start of the exposure chain. Traditional scanning sees a package or a secret in isolation, but the real risk lies in how identity, build tooling, and publishing privileges interact over time. The danger is compounded when teams cannot tie credential use back to runtime and pipeline behaviour.

Practical implication: correlate package activity with credential use and publishing rights across the build chain.

Why a single reasoning layer matters across code, infrastructure, and runtime

The article’s core architectural point is that exposure becomes answerable only when telemetry from code, infrastructure, identity, and workload behaviour is unified. Without that correlation layer, teams get partial signals that cannot answer the containment question in time. This is not about collecting more logs for their own sake. It is about turning fragmented observations into a single exposure verdict that reflects how the system is actually behaving under threat.

Practical implication: build one exposure view that joins identity, workload, and runtime signals before incidents arrive.

Threat narrative

Attacker objective: The attacker aims to turn a single compromise into wider exposure across software supply chains and runtime environments before defenders can contain it.

1. Entry occurs through a React Server Components behaviour where crafted deserialised server action payloads can trigger unauthenticated remote code execution without an explicit vulnerable API call.
2. Credential theft occurs in the Shai Hulud path when poisoned npm packages use preinstall scripts to steal developer or CI credentials.
3. Escalation follows when stolen credentials are reused to publish additional compromised packages, turning one infection into recursive propagation.
4. Impact is the inability to determine blast radius quickly enough to contain exposed workloads, packages, and identities before the attack spreads further.

Breaches seen in the wild

• ChainDrop npm worm 2026: A self-propagating npm worm starting with keyv hit 444 packages in hours, harvesting publishing tokens, CI secrets, cloud keys and AI tool credentials.
• Bitwarden CLI npm compromise 2026: A malicious Bitwarden CLI on npm, linked to the Checkmarx campaign, targeted GitHub, npm, cloud and CI secrets from developers for 90 minutes.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime exposure visibility is the missing control plane for modern incident containment. The article points to a gap between code, infrastructure, identity, and workload telemetry that existing workflows do not close. That gap is where blast radius becomes unknowable. For NHIMG, the important shift is that governance has to reflect runtime truth, because static inventories do not tell teams which workloads or identities are actually participating in an active attack path.

Identity context is part of exposure verdicts, not a separate investigation stream. Shai Hulud shows that credentials used in package publishing can become the propagation mechanism, while React2Shell shows that application behaviour can expose systems even without overt credential compromise. The named concept here is runtime exposure gap: the delay between compromise and trustworthy scope determination. That gap is where containment fails, so exposure analysis must collapse identity, code, and runtime into one decision surface.

Security operations need answerable questions, not more fragmented alerts. The article’s operational value is not a new signature or a new exploit taxonomy. It is the case for a single reasoning layer that can answer whether a workload, package, or identity is implicated right now. That shifts the field toward evidence-based containment decisions. Practitioners should measure whether their programme can produce a scope answer before the attacker can extend the blast radius.

Modern exposure management is converging with identity governance. The same environment that obscures runtime vulnerability also obscures how credentials and build privileges are being used. That means exposure visibility, NHI governance, and workload behaviour analysis are no longer separable disciplines in practice. The practitioner implication is to plan for combined control paths rather than independent tool silos.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Identity Security Posture Management (ISPM) Guide

What this signals

Runtime exposure gap: When defenders cannot join code, identity, and workload telemetry in one place, containment becomes a guessing exercise. That gap is what turns a known threat into an unknown blast radius, and it is the programme weakness this article exposes for identity and security teams.

Security operations that still separate application risk from identity risk will struggle with attacks that propagate through credentials and runtime behaviour at the same time. The practical signal is simple: if a team cannot answer whether it is exposed in minutes, it does not yet have an incident-ready exposure model.

For practitioners

• 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.
• Replace tribal knowledge with an exposure runbook Document who can answer scope questions, what telemetry sources they need, and how to judge whether containment still has a meaningful window.

Key takeaways

• 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.
• The article centres on a runtime visibility gap, with the strongest evidence coming from recursive package compromise, credential theft, and unauthenticated execution behaviour.
• The control lesson is to join code, infrastructure, identity, and workload telemetry so exposure can be answered while containment is still possible.

Key terms

• Runtime exposure management: A security approach that prioritises what is actually exploitable in live environments rather than treating every finding as equally urgent. It combines runtime context, asset criticality, and control enforcement so teams can focus on exposure that changes production risk.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
• Recursive Propagation: A spread pattern where compromised credentials or packages are reused to extend the attack into additional systems. It is especially dangerous in software supply chains because each successful step can create the next foothold.
• Runtime correlation: Runtime correlation is the practice of joining identity state changes with security activity while an investigation is still active. It lets teams evaluate whether access use matches expected behaviour, which is more useful than reviewing entitlement records after the fact.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.