React2Shell shows why identity is the real cloud perimeter

At a glance

What this is: React2Shell is a cloud exploit analysis showing how unauthenticated RCE can quickly become identity abuse, lateral movement, and persistence once attackers reach a workload.

Why it matters: It matters because IAM scope, identity visibility, and privilege boundaries determine whether a patched flaw stays local or becomes a broader cloud breach.

👉 Read Unosecur's analysis of React2Shell and cloud identity abuse

Context

React2Shell is a critical unauthenticated remote code execution flaw in React Server Components’ Flight protocol. A single crafted HTTP request can execute arbitrary code on vulnerable servers, which makes the initial compromise path simple and fast.

The governance problem starts after exploitation. In cloud environments, the next question is not whether a flaw existed, but which identities the compromised workload could touch, whether those identities were over-privileged, and whether new access paths were created before patching closed the vulnerability.

For identity teams, this is an NHI and cloud IAM problem at the same time: service roles, instance identities, API tokens, and workload permissions determine the blast radius once a runtime flaw becomes an access event.

Key questions

Q: What fails when a cloud workload with an attached role is compromised by RCE?

A: The failure is usually not the patch itself but the identity boundary around the workload. If the attached role can call management APIs, modify trust, or access multiple services, the attacker can pivot from code execution into broader cloud control before responders finish remediation.

Q: Why do over-privileged service accounts make post-exploit containment harder?

A: Over-privileged service accounts let attackers operate through legitimate cloud permissions, which means their actions can blend into normal API traffic. That extends dwell time, expands the blast radius, and makes it harder to distinguish attacker behaviour from routine automation in the logs.

Q: What are the signs that a compromised cloud identity is being used for persistence?

A: Watch for new roles, altered trust policies, unusual token issuance, access at odd hours, and identity-management actions that do not match the workload’s normal function. Those signals often show that the attacker has moved from initial access into durable access paths.

Q: How should teams respond after a cloud RCE if they suspect identity abuse?

A: Contain the workload, review attached permissions, revoke or rotate exposed credentials, and inspect cloud activity for role changes or lateral movement before declaring the incident closed. The patch removes the bug, but the identity review determines whether the compromise can recur.

Technical breakdown

How unauthenticated RCE becomes an identity problem

Unauthenticated remote code execution gives an attacker a runtime foothold without valid credentials. In cloud environments, that foothold often runs inside a workload that already has attached identity context, such as instance roles, service accounts, or application tokens. At that point the attacker does not need to break authentication again. They inherit whatever permissions the compromised process can reach and begin using those permissions to query cloud APIs, enumerate resources, and move toward higher-value targets. The technical risk is not just code execution. It is the combination of execution plus reachable identity surface.

Practical implication: treat every RCE in a cloud workload as a potential identity exposure event, not just an application patching issue.

Why cloud identity scope determines blast radius

Cloud identity scope defines what the compromised workload can do after exploit. Broad IAM roles, reusable tokens, and excessive API permissions convert a local application flaw into a platform-wide problem because cloud services are accessed through identities, not through the original vulnerability. Attackers commonly test whether they can create or modify roles, call management APIs, deploy new workloads, or move laterally across accounts. If the identity can do those things, containment becomes much harder, because the attacker can live off legitimate permissions rather than noisy malware behaviour.

Practical implication: review attached roles, token scope, and service permissions for every exposed workload before assuming the incident is contained.

How post-exploitation persistence works in cloud environments

Persistence in cloud incidents often comes from identity changes rather than binaries. After initial access, an attacker may create a new service account, mint a token, widen permissions, or modify trust relationships so access survives patching. That is why patching the vulnerable library is necessary but not sufficient. The exploit path may be closed while the attacker’s newly created identity paths remain open. Effective detection therefore has to look for identity-management actions, unusual API timing, and access patterns that do not match the workload’s historical behaviour.

Practical implication: hunt for identity changes and abnormal API activity in the exposure window, not only for the vulnerable code path.

Threat narrative

Attacker objective: The attacker aims to expand from code execution into durable cloud access, broader resource control, and persistence through abused identities.

1. Entry occurs through a single crafted HTTP request that triggers unauthenticated remote code execution in React Server Components’ Flight protocol.
2. Credential or privilege abuse follows when the attacker uses the compromised workload’s attached service roles, instance identities, or API tokens to access cloud resources.
3. Escalation and lateral movement can follow through overly broad permissions, allowing API-driven expansion across services and accounts.
4. Impact is established when the attacker persists through new identities, modified roles, or resource-abuse workloads that outlast the original patch window.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
• Gravity SMTP CVE-2026-4020 API Keys Exposure: CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

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

NHI Mgmt Group analysis

Identity is the real perimeter because cloud compromise is decided by attached permissions, not the original flaw. React2Shell shows that a patch closes the code path, but it does not automatically remove the attacker’s access to cloud APIs, roles, and tokens during the exposure window. The decisive control is whether identity scope limits what a compromised workload can do once execution is achieved. Practitioners should treat the blast radius as an identity problem first and an application problem second.

Least privilege becomes a breach-containment control, not a governance slogan, when RCE lands inside cloud workloads. The article’s central lesson is that broad service roles convert a single exploit into a wider operational incident because the attacker can act through legitimate permissions. That is the direct cloud analogue of privilege sprawl in human IAM, but the speed of exploitation is faster and the signal is noisier. The implication is that permission scope must be narrow enough to make post-exploit action materially difficult.

Patch velocity and identity visibility solve different parts of the same incident. Patching removes the vulnerable entry point, while identity telemetry reveals whether the attacker already used the window to create persistence, modify trust, or move laterally. Organisations that rely only on vulnerability response are blind to the post-exploitation phase where the real damage is done. The practitioner priority is to make identity events observable at the same operational speed as vulnerability remediation.

Runtime cloud identity abuse is now a standard post-exploit pattern, not an edge case. The article ties exploitation to service roles, API tokens, and workload permissions, which means defenders need to assume identity pivoting is part of the attacker playbook whenever code execution is gained in cloud infrastructure. That assumption should shape how incident teams triage exposure, scope containment, and forensic review.

Identity blast radius deserves to be a named security metric. React2Shell makes it clear that the question after compromise is not simply whether a server was patched, but how far the compromised identity could reach before containment. That metric connects IAM design, cloud architecture, and incident response into one governance view. Practitioners should evaluate cloud workloads by reachable permissions, not by asset count alone.

From our research library:

• Valid account abuse was responsible for 35% of cloud-related incidents, according to CrowdStrike's 2025 Global Threat Report.

What this signals

Identity blast radius is the control plane that matters after cloud exploitation. Patch management reduces exposure, but cloud compromise is ultimately governed by which identities the attacker can abuse after execution is gained. That means incident response has to move from vulnerability triage to permission mapping and trust review immediately.

Service roles and workload tokens need the same governance attention that teams usually reserve for human accounts. In practice, post-exploit risk is driven by whether those identities can create new access paths, not just whether the original vulnerability has been fixed. The governance model should therefore treat runtime cloud identities as first-class assets in triage and investigation.

For practitioners

• Map workload identity blast radius Inventory the service roles, instance identities, API tokens, and reachable cloud resources attached to every internet-facing workload so you can scope post-exploit risk quickly.
• Review permissions before remediation closes the window Check whether any compromised workload could create new identities, modify trust relationships, or call IAM management APIs during the exposure period.
• Hunt for identity-management actions in the exposure window Look for unusual token usage, role changes, privilege escalation events, and API timing that does not match the workload’s historic behaviour.
• Enforce least privilege on attached cloud identities Reduce the permissions granted to compute roles, serverless functions, and service accounts so a future exploit cannot turn execution into broad cloud access.

Key takeaways

• React2Shell illustrates that a single unauthenticated RCE can become an identity-led cloud incident when workloads carry broad permissions.
• The key evidence is the post-exploit chain, where service roles, API tokens, and trust relationships can turn a patchable flaw into durable access.
• The control that changes the outcome is least privilege plus identity visibility, because those controls narrow blast radius and expose persistence attempts.

Key terms

• Cloud Identity Blast Radius: The amount of damage a compromised cloud identity can cause before it is contained. It expands when credentials are long-lived, privileges are broad, or access spans multiple clouds and vaults, and it shrinks when elevation is temporary and tightly scoped.
• Post-Exploitation Identity Abuse: The use of legitimate cloud identities after initial compromise to move, persist, or escalate. In cloud environments, the attacker often relies on normal API access rather than malware, which makes identity scope and telemetry the decisive controls.
• Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
• Identity Visibility: Identity visibility is the ability to see which identities exist, what they can access, and how those access paths relate across systems. In NHI programmes, it means correlating service accounts, tokens, certificates, and agents into one operational view so governance decisions are based on evidence, not assumptions.

What's in the full article

Unosecur's full blog covers the operational detail this post intentionally leaves for the source:

• The identity-specific detection logic used to spot abnormal API usage after exploitation
• The no-code IAMOps remediation flow for revoking or quarantining suspicious identities
• The forensic questions teams should ask about workload access during the exposure window
• The cloud identity visibility model across AWS, Azure, and GCP environments

👉 The full Unosecur blog covers identity visibility, post-exploit detection, and IAMOps remediation details.

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.