React2Shell shows why protocol interpreters in request paths become RCE risks

At a glance

What this is: Pixee argues that React2Shell repeats an old AppSec pattern where request-path interpreters create remote code execution risk through unsafe deserialisation.

Why it matters: This matters because IAM, PAM, and platform teams need to understand how privileged server-side execution paths expand blast radius when authentication and authorisation controls are bypassed at the protocol layer.

👉 Read Pixee's analysis of React2Shell and the request-path interpreter risk

Context

The core problem is not just a single vulnerability, but a design pattern that lets user-controlled input influence server-side execution through an interpreter or serialisation layer. In AppSec terms, that is where abstract architectural risk becomes operational exposure, especially when request handling can reach privileged code without strong boundary checks.

For IAM practitioners, the identity angle appears when framework behaviour creates unauthenticated or over-privileged execution paths inside application runtimes. That makes application-layer trust assumptions as important as access policy, because a weak protocol boundary can nullify otherwise well-designed identity controls.

Key questions

Q: What breaks when request-path interpreters are not tightly bounded?

A: The boundary between data and code collapses. If a framework lets user-controlled input reach expression evaluation, deserialisation, or function invocation, attackers may turn parsing into server-side execution. That can bypass intended authentication assumptions, expose secrets, and convert a single application flaw into full runtime compromise.

Q: Why does PQC planning matter to IAM and PAM teams?

A: Because authentication, privileged access, and workload trust all depend on cryptographic primitives that may need post-quantum replacement. IAM and PAM teams own many of the systems that will break first if trust assumptions are not mapped early. PQC is therefore an identity architecture issue, not only a cryptography issue.

Q: How can security teams know whether a framework pattern is becoming dangerous?

A: Look for repeated coupling of request handling with interpreters, decoders, or module-loading behaviour. If the same design pattern appears across multiple vulnerable components, it is no longer an isolated bug class. It is an architectural risk that should be tracked alongside patch metrics and threat intel.

Q: Should organisations treat active exploitation differently from abstract design risk?

A: Yes. Active exploitation demands immediate containment and patching, but abstract design risk should still trigger architecture review, because the same pattern can reappear in new frameworks. Mature programmes do both: they close the live hole and reduce the chance of the next one.

Technical breakdown

Why request-path interpreters are so dangerous

When a framework embeds an interpreter in the request path, it allows structured input to be converted into executable behaviour. In Struts, OGNL made that dangerous because expression evaluation sat close to request processing. In React2Shell, the Flight protocol and Server Functions create a similar risk shape: decoding logic expands objects, loads modules, and invokes functions. The issue is not JSON itself, but any mechanism that turns data parsing into code execution without a hard boundary.

Practical implication: treat interpreter-in-the-request-path designs as high-risk architectural choices, not routine implementation detail.

Unsafe deserialisation and prototype pollution as an exploit chain

Unsafe deserialisation becomes severe when the parser accepts crafted structures that alter object state or influence execution flow. Prototype pollution is especially dangerous in JavaScript ecosystems because it can reshape behaviour globally, not just locally. React2Shell sits in this class because attacker-controlled payloads can reach decoding logic that assumes trusted shape and then affect server-side function invocation. That combination turns parsing defects into unauthenticated code execution opportunities.

Practical implication: validate object shape strictly before deserialisation and remove any path where parsing can influence execution primitives.

Why abstract risk becomes concrete only after exploitation

AppSec teams often react well to concrete signals such as CVEs, KEV listings, and active exploitation. Abstract risk is harder because it describes a pattern that is not yet weaponised, but is structurally capable of becoming a breach. That is why OGNL in Struts, JNDI abuse, and template-engine injection all matter before the first exploit lands. React2Shell reinforces that mature programmes need pattern-based risk review, not only vulnerability response.

Practical implication: add pattern-based architectural review to vulnerability management so dangerous execution models are flagged before exploitation.

Threat narrative

Attacker objective: The attacker wants unauthenticated server-side code execution that can be used to steal data, deploy further payloads, or pivot deeper into the environment.

1. Entry occurs when an unauthenticated attacker sends a crafted payload into the React Server Components decoding path.
2. Escalation happens when unsafe deserialisation and prototype pollution influence object construction and function invocation on the server.
3. Impact is remote code execution on affected application instances, which can lead to broader compromise of application data and secrets.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• JetBrains GitHub plugin token exposure — CVE-2024-37051 in JetBrains IntelliJ GitHub plugin exposed GitHub access tokens.

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

NHI Mgmt Group analysis

Interpreter-heavy request paths create a concrete governance blind spot. The article shows that teams often separate application design risk from identity and access risk, even when a parser can reach privileged server execution. That is a mistake because any unauthenticated execution path can bypass the assumptions behind authentication, authorisation, and session control. Practitioners should treat these frameworks as trust-boundary decisions, not just code-quality concerns.

Abstract risk is the precursor state that most vulnerability programmes still underweight. Pixee's comparison with Struts is useful because it shows how dangerous design patterns persist across generations of frameworks before the next CVE appears. AppSec, IAM, and platform teams need a shared language for identifying interpreters, decoders, and protocol bridges that can collapse data into code. Practitioners should prioritize pattern review, not only patch response.

Concrete exploitation only exposes the earlier failure to set architectural limits. Once a framework allows user-controlled input to reach execution primitives, the breach is already partially decided. That is why CVE-driven remediation is necessary but incomplete. Practitioners should document where deserialisation, function invocation, and module loading sit in their risk registers and assign owners before attackers do.

Server-side execution bugs often expand into identity and secrets exposure within minutes. When an unauthenticated RCE lands, the first follow-on targets are usually credentials, tokens, and service identities sitting in runtime memory or adjacent configuration stores. This is where application security intersects directly with NHI governance and PAM. Practitioners should assume that code execution on a web tier can quickly become identity compromise.

Framework-specific bugs and platform-level trust models need the same review cadence. Organisations tend to review IAM policy drift more often than they review assumptions baked into application runtimes, even though both can govern the same blast radius. The named concept here is abstract risk drift: the accumulation of architectural decisions that look acceptable individually but become dangerous as a set. Practitioners should fold these patterns into architecture governance reviews.

What this signals

Application teams should expect more scrutiny on interpreter-heavy frameworks and serialization layers because attackers repeatedly turn these design choices into code execution paths. The operational signal is not just whether a CVE exists, but whether a platform relies on trust assumptions that can collapse before authentication or authorisation are even applied.

The named concept here is abstract risk drift: the slow accumulation of architectural decisions that become dangerous only when combined. Security programmes that track only known vulnerabilities will keep missing this category. Teams should align AppSec governance, runtime hardening, and secrets protection so one execution flaw does not become a full identity event.

For practitioners building resilience around web platforms, the key is to connect application runtime risk to downstream identity impact. Resources such as the Analysis of Claude Code Security and the OWASP Agentic Applications Top 10 help frame how execution boundaries fail across modern software stacks.

For practitioners

• Review request-path interpreter exposure Inventory frameworks and middleware where user input can reach expression engines, deserialisers, or function invocation logic. Flag any code path where parsing and execution are coupled before authentication or strong schema validation.
• Add architectural pattern checks to AppSec review Create a review step for interpreter-heavy designs such as OGNL-style evaluation, unsafe deserialisation, and server-function decoding. Use it to catch abstract risk before a CVE or KEV listing appears.
• Map RCE blast radius to identity assets Assume any server-side execution bug can expose API keys, service account tokens, and session material. Tie incident playbooks to nearby secrets stores and privileged identities so containment starts with the most likely follow-on targets.
• Prioritise patching for active exploitation Where a vulnerability is in KEV or under active exploitation, move it ahead of routine patch queues and verify affected framework versions across all app stacks, including transitive framework dependencies.

Key takeaways

• React2Shell is a reminder that architectural trust boundaries can fail long before a CVE becomes public.
• Unsafe deserialisation and protocol-driven execution are not abstract code smells, because they can collapse directly into remote code execution and identity exposure.
• Security programmes should review interpreter-heavy frameworks as governance risks, not just patch targets, so exploitation does not surprise the identity stack.

Key terms

• Unsafe Deserialisation: Unsafe deserialisation happens when an application turns untrusted serialized data back into objects without strict validation. In Python, this can become code execution if the format supports callable reconstruction or hidden execution paths. Authentication code should avoid it entirely when processing cookies, sessions, or request data.
• Prototype Pollution: Prototype pollution is a JavaScript bug where attacker-controlled keys modify Object.prototype or another shared prototype. That makes the injected property visible to many objects that were never directly touched by the attacker. In security terms, it creates hidden state that later code may treat as trusted configuration.
• Request-Path Interpreter: A request-path interpreter is any expression engine, protocol decoder, or similar component that sits in the flow of handling user requests and can turn data into executable behaviour. These components are risky because they compress the distance between input handling and code execution.

What's in the full article

Pixee's full article covers the code-level and historical detail this post intentionally leaves for the source:

• A closer comparison between React2Shell and Struts OGNL failures that shows how the same risk pattern recurs across framework generations.
• Specific references to CVE-2025-55182, the affected React and Next.js configurations, and why the bug is being treated as concrete exploit risk.
• The article's discussion of abstract versus concrete risk, including how teams may miss architectural danger until exploitation begins.
• Pixee's framing of why storytelling and metaphor matter when AppSec teams try to communicate latent framework risk to management.

👉 Pixee's full post covers the Struts comparison, concrete exploit status, and the abstract-risk argument in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security practitioners connect application compromise to identity and access risk across modern environments.