Notifications
Clear all
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.
NHIMG editorial — based on content published by RAD Security: Back to Blog Behavioral Threat Detection How RAD Helps Teams Answer the Only Question That Matters: Are We Exposed?
Questions worth separating out
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.
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.
Q: What do security teams get wrong about static scanning for modern application risk?
A: They assume static findings are enough to establish exposure.
Practitioner guidance
- Map runtime exposure for framework-specific attack paths Inventory every workload using React Server Components and verify how deserialised payloads behave in live environments.
- 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.
- 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.
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
👉 Read RAD Security's analysis of React2Shell and Shai Hulud exposure →
React2Shell and Shai Hulud: what exposure visibility teams need now?
Explore further
08/07/2026 7:30 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Runtime exposure checks for React2Shell and Shai Hulud risks
