Runtime exposure checks for React2Shell and Shai Hulud risks

At a glance

What this is: This is an operational analysis of why runtime exposure questions fail when teams rely on static scans and manual investigation.

Why it matters: It matters because IAM, NHI, and security teams need fast proof of exposure across code, identity, and runtime behaviour before compromise spreads.

👉 Read RAD Security's analysis of React2Shell and Shai Hulud exposure

Context

The core problem is exposure visibility, not just detection. When an organisation cannot quickly tell whether a vulnerable pattern exists in code, infrastructure, or runtime, response becomes a slow investigation instead of a containment decision. That gap affects identity governance too, because compromised credentials and workload access can turn a software flaw into a broader identity incident.

React2Shell and Shai Hulud are useful because they represent two different failure modes with the same operational outcome: teams struggle to answer whether they are affected. One path hinges on vulnerable runtime behaviour in React Server Components, while the other uses poisoned npm packages and credential theft to spread through standard tooling. The typical starting position is common, not exceptional.

Key questions

Q: How should security teams confirm whether they are exposed to runtime and supply chain attacks?

A: They should combine code inventory, identity ownership, and live runtime telemetry into one exposure workflow. Static scans can find known patterns, but they rarely prove whether a crafted payload, poisoned package, or stolen credential is active in production. Fast confirmation depends on correlating what is deployed with what is actually executing.

Q: Why do runtime attacks and poisoned packages create the same visibility problem?

A: Because both exploit the gap between what teams think is trusted and what the system actually executes. One attack path abuses runtime deserialisation, while the other abuses package installation and credential reuse. In both cases, slow manual investigation means the blast radius expands before the organisation can answer a basic exposure question.

Q: What do security teams get wrong about static scanning for modern application risk?

A: They assume static findings are enough to establish exposure. In practice, source code and configuration checks do not reliably show whether a runtime will accept a malicious payload or whether a package credential has already been abused. Teams need behavioural evidence, not just file-based evidence.

Q: Who is accountable when a compromised package credential is used to spread malicious artefacts?

A: Accountability sits with the organisation that owns the publishing authority and the surrounding identity controls, not just the developer who used the tool. Publishing access is a privileged identity path, so governance must cover ownership, monitoring, and revocation with the same seriousness as other elevated access.

Technical breakdown

React Server Components and unauthenticated runtime execution

React2Shell exploits a behaviour in React Server Components where deserialised server action payloads can trigger unauthenticated remote code execution. The important detail is that the dangerous action happens at runtime, after a crafted payload reaches the application, so static source review alone cannot prove safety. If framework defaults are permissive, the attack surface exists even without an explicit vulnerable API call. The failure is not just a bug in one file. It is a mismatch between assumed request handling and what the runtime will actually execute.

Practical implication: identify every workload using React Server Components and test runtime payload handling, not just code patterns.

Recursive npm package infection and credential abuse

Shai Hulud spreads through poisoned npm packages by using preinstall scripts to steal credentials and then reuse those credentials to publish additional compromised packages. That makes the attack recursive, because each successful compromise can create the next one without needing a new initial foothold. The mechanism also depends on standard developer tooling, which means package trust and publishing rights become part of the attack path. This is a supply chain problem shaped by identity misuse as much as by malware execution.

Practical implication: treat package publishing credentials as high-risk identities and monitor for abnormal publish activity.

Why static scanning misses the blast radius

Static scanning sees files, manifests, and known signatures, but it does not reliably answer whether live workloads, credentials, or runtime behaviours are already affected. These attacks exploit the gaps between systems, so a code-only or config-only view leaves the organisation with partial evidence and delayed confidence. A reasoning layer that correlates code, infrastructure, identity, and runtime telemetry is therefore more useful than isolated point checks. The question is not whether a control exists somewhere. The question is whether the environment can answer exposure fast enough to contain impact.

Practical implication: correlate code, identity, and runtime signals in one workflow so exposure can be confirmed during the incident window.

Threat narrative

Attacker objective: The attacker aims to turn trusted application or package pathways into broad runtime compromise and secondary credential-driven propagation.

1. Entry occurs when crafted React Server Components payloads or poisoned npm packages reach an environment that trusts them enough to process or install them.
2. Credential access or execution follows when the runtime accepts deserialised payloads or preinstall scripts steal publishing credentials from standard tooling.
3. Impact expands as attackers gain unauthorised execution, propagate compromised packages, and widen the blast radius across connected systems.

Breaches seen in the wild

• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Exposure visibility is now a governance control, not a convenience feature. When teams cannot answer whether they are affected within the incident window, they have already lost the ability to shape containment. That gap spans code, infrastructure, identity, and runtime telemetry, which means the governance problem is cross-domain rather than purely technical. The practical conclusion is that exposure confirmation must be treated as an operational control objective.

Runtime behaviour is the real trust boundary for modern application risk. Static analysis can still be useful, but it cannot replace visibility into how workloads actually parse payloads, execute scripts, or move credentials. React2Shell and Shai Hulud both show that the blast radius emerges where trusted defaults meet live execution. Practitioners should stop treating the build stage as the whole control surface.

Credentialed publishing paths create identity risk inside the software supply chain. In the Shai Hulud pattern, package credentials are not just access tokens. They are propagation tools that let attackers turn one compromised identity into many compromised artefacts. That makes software publishing a governed identity function, not a developer convenience. Practitioners need to treat publishing authority as an identity perimeter.

Identity, code, and runtime telemetry belong in the same decision loop. The article’s core insight is not that better detection exists somewhere. It is that exposure questions require a single reasoning layer that can connect who has access, what was changed, and what is happening at runtime. That is the standard practitioners should expect before they trust any answer about blast radius.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• That visibility gap makes exposure questions harder to answer in practice, which is why the NHI Lifecycle Management Guide matters when identities, access, and offboarding need tighter control.

What this signals

Exposure confirmation is becoming a programme-level capability, not a point-in-time check. When teams need to answer whether they are affected during an active incident, the relevant control is not just detection but decision speed. That is especially true where code, credentials, and runtime behaviour all contribute to the risk surface, because fragmented tooling cannot reliably tell the full story.

The emerging pattern is identity-adjacent software risk, where publishing credentials, package trust, and runtime execution all intersect. Security teams should expect more incidents in which the first useful question is not what failed, but whether the environment can prove scope before containment windows close.

Identity blast radius: the practical measure of how far compromised access, trusted tooling, or malformed runtime behaviour can spread before the organisation can respond. Teams that can connect identity ownership to runtime evidence will reduce the time spent guessing and increase the quality of containment decisions.

For practitioners

• Map runtime exposure for framework-specific attack paths Inventory every workload using React Server Components and verify how deserialised payloads behave in live environments. Pair the inventory with runtime testing so the team can answer exposure questions without relying on source code review alone.
• Treat package publishing credentials as privileged identities Separate npm or equivalent publishing rights from day-to-day developer access, and monitor for abnormal publish, preinstall, or token-use patterns. Publishing credentials should be reviewed as high-risk identities, not ordinary development access.
• Correlate code, identity, and runtime signals before incident pressure peaks Build a workflow that can join configuration state, credential ownership, and behavioural telemetry into one response path. The goal is to determine affected workloads quickly enough to contain impact while the incident is still active.

Key takeaways

• The key failure is not a lack of alerts, but a lack of fast exposure confirmation across code, identity, and runtime.
• React2Shell and Shai Hulud show that different technical paths can produce the same governance problem: the blast radius is unclear until it is already expanding.
• Teams need correlated runtime and identity evidence, because static scanning alone cannot reliably answer whether modern application environments are affected.

Key terms

• Runtime Exposure: Runtime exposure is the state where a system can be affected by malicious input or trusted-tool abuse in live operation, even if static review looks clean. It focuses on what the application or workload actually does when it executes, not just what the code appears to allow.
• Recursive Package Infection: Recursive package infection is a supply chain attack pattern where a compromised package uses stolen credentials or trusted automation to publish more compromised packages. The result is self-propagating spread through normal developer tooling and publishing paths, which makes containment dependent on identity and process controls as much as on malware detection.
• Exposure Visibility: Exposure visibility is the organisation’s ability to determine quickly whether a known threat, vulnerable pattern, or compromised identity exists in its environment. It depends on joined-up evidence from code, configuration, identity, and runtime behaviour, and it is what turns investigation into actionable containment.

What's in the full article

RAD Security's full post covers the operational detail this post intentionally leaves for the source:

• Specific runtime checks for React Server Components exposure in live workloads
• The telemetry correlation approach used to connect code, infrastructure, identity, and runtime behaviour
• Practical visibility examples for tracking anomalous package activity and credential-driven propagation
• How the platform frames incident-time exposure questions across multiple layers

👉 The full RAD Security post covers the runtime checks and correlation approach in more detail

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.