React and Next.js RCE flaws expose server-side apps to trivial exploit

At a glance

What this is: Two related React and Next.js vulnerabilities can permit unauthenticated remote code execution through crafted server-side requests.

Why it matters: IAM and platform teams need to treat framework exposure as an access problem as well as a patching problem, because unauthenticated server-side execution can bypass normal trust assumptions and expand blast radius quickly.

👉 Read Anomali's analysis of React and Next.js RCE vulnerabilities

Context

React server-side rendering vulnerabilities matter because they turn ordinary HTTP traffic into a server execution path. When a framework flaw allows code execution before authentication, the problem is not only application security but also the trust boundary between external requests and internal execution.

For identity and access programmes, this is a reminder that privileged server contexts are effectively high-value identities. If attackers can execute code on the server, they may pivot into secrets, tokens, service accounts, and deployment pipelines that sit behind the application edge. That intersection makes framework hygiene relevant to NHI governance as well as secure development.

The starting position here is unfortunately typical for modern web stacks: teams adopt framework defaults first and only later discover that a shared dependency exposed every deployment using that runtime path.

Key questions

Q: What breaks when a framework flaw allows unauthenticated server-side execution?

A: The main failure is that the application tier stops being a control boundary. An attacker can execute code before authentication, which means normal access checks, session controls, and some logging assumptions no longer protect the host. If that server also holds secrets or service credentials, the flaw can quickly become an identity and data exposure issue.

Q: Why do React and Next.js flaws create broader risk than a single vulnerable app?

A: Because shared framework code can place many deployments into the same exposure pattern even when teams did not customise the dangerous feature. That makes version governance, build inventory, and dependency tracking essential. A single vulnerable runtime path can affect multiple apps, environments, and release branches at once.

Q: How do security teams know if a framework exploit has already been attempted?

A: Look for unusual request patterns around the vulnerable protocol, repeated unauthenticated requests, malformed payloads, and errors that appear only on specific server routes. Then correlate those events with patch state and exposed internet-facing systems. Detection should focus on traffic to the framework path, not only on endpoint alerts after compromise.

Q: What should teams do first after a public proof-of-concept appears?

A: Patch the exposed framework versions immediately, then verify that rebuilds and redeploys have removed the vulnerable path from production. After that, hunt for signs of probing and rotate any credentials reachable from the affected servers. The priority is to shorten exposure before scanning turns into successful exploitation.

Technical breakdown

How the Flight protocol turns request parsing into code execution

React Server Components use the Flight protocol to exchange server-rendered component data between client and server. The disclosed flaw sits in unsafe deserialization inside that path, which means specially crafted input can be interpreted in a way the developer never intended. Because deserialization happens before normal application logic completes, the issue is not limited to a single application route. Once the server accepts attacker-controlled data in that pipeline, it can be coerced into executing supplied JavaScript in the server context. That makes the vulnerability especially dangerous in default deployments where teams assumed the framework boundary was already safe.

Practical implication: treat framework deserialization paths as execution surfaces and patch the runtime before relying on application-layer mitigations.

Why bundled framework packages broaden the exposure surface

Next.js can bundle React server packages, so a flaw in the underlying framework can propagate into applications that never consciously chose the vulnerable code path. That is a supply-chain style exposure inside the application stack, where the application owner inherits risk from the runtime architecture itself. The rejected duplicate CVE exists because the same flaw appeared across the ecosystem through shared packaging and integration. In practice, this means inventorying only direct application code is not enough. Teams also need to know which framework versions, build artifacts, and server component features are actually present in production.

Practical implication: maintain a live inventory of framework versions and build outputs, not just application names.

Why public proof-of-concept code changes the threat profile

Once proof-of-concept exploits are public, exploitation usually shifts from targeted testing to opportunistic scanning. Attackers no longer need deep understanding of the underlying framework bug if they can automate the request pattern and look for default configurations. That changes the risk from theoretical code execution to broad internet exposure. For defenders, the practical issue becomes speed of remediation and visibility into which hosts still present the vulnerable request path. Log review around unusual Flight protocol requests can help confirm whether the application has already been probed.

Practical implication: combine urgent patching with log hunting for suspicious Flight protocol traffic and failed exploit attempts.

Threat narrative

Attacker objective: The attacker aims to gain unauthenticated server-side code execution on internet-facing React and Next.js applications.

1. Entry occurs when an attacker sends a crafted unauthenticated HTTP request to a public React or Next.js endpoint that processes the vulnerable server-side component path.
2. Escalation follows when unsafe deserialization in the Flight protocol causes attacker-supplied JavaScript to execute in the server context without default authentication checks.
3. Impact is achieved when the attacker can use server-side execution to probe the application, reach secrets, or stage broader compromise from the exposed web tier.

Breaches seen in the wild

• ASP.NET machine keys RCE attack — 3,000+ exposed ASP.NET machine keys enabled remote code execution.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

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

NHI Mgmt Group analysis

Framework-level trust is now an identity problem, not just a code problem. When an application framework allows unauthenticated execution, the server process itself becomes the first privileged identity under attack. That matters because the server often holds the credentials, tokens, and workload permissions that make lateral movement possible. For IAM and NHI teams, the lesson is to treat runtime trust boundaries as part of access governance, not as an isolated application concern. The control question is whether the server can be abused before any identity control has a chance to intervene.

Default configurations create the widest exposure window. Vulnerabilities that only affect specific optional features still matter when those features are enabled by default or bundled into common builds. That creates a fragile assumption that teams are secure because they never configured the risky path themselves. In reality, framework inheritance can place thousands of deployments into the same risk bucket overnight. Practitioners should assume inherited runtime risk until version inventories prove otherwise.

Public exploit code compresses the remediation timeline. Once the exploit pattern is circulating, the adversary does not need persistence or sophisticated tradecraft. Opportunistic scanning becomes the dominant model, which means patch latency directly increases compromise likelihood. The practical conclusion is that exposure management, log-based validation, and rapid rebuild pipelines are now core controls for web application governance.

Server-side execution expands the NHI attack surface. If a web server is compromised, attackers may inherit service account credentials, cloud tokens, or API keys embedded in build and runtime environments. That is why secrets governance belongs in the same conversation as application patching. A vulnerability like this can become an NHI incident the moment the attacker reaches privileged machine identities or automation credentials.

Named concept: server-side trust collapse. This is the point at which a framework boundary that was assumed to be safe becomes an execution boundary controlled by the attacker. Once that happens, traditional perimeter thinking and narrow application review both fail. The practitioner response is to correlate framework exposure with identity and secret-bearing assets, then treat patched versions as a minimum baseline rather than a finished control.

What this signals

Server-side trust collapse: this incident pattern shows why application teams must treat framework execution paths as part of identity governance. When code runs before authentication, the most relevant question becomes what secrets and machine identities the server can reach, not just whether the app is patched. That is where NHI governance, secrets rotation, and build-time inventory intersect with secure coding.

Patch latency will remain the practical determinant of impact whenever proof-of-concept code is public. Teams that cannot identify every framework instance, rebuild quickly, and verify runtime versions will keep operating with a hidden exposure window. The operating model needs to shift from reactive vulnerability handling to continuously confirmed deployment state.

For readers managing identity-heavy programmes, the immediate signal is to tighten the connection between application patching and secrets governance. Service accounts, API keys, and deployment tokens should be assumed exposed when a public server-side execution flaw exists until proven otherwise.

For practitioners

• Inventory all React and Next.js deployments Map every application using React Server Components or bundled Next.js server packages, including build artifacts in CI/CD, so you can confirm where the vulnerable code path exists.
• Prioritise emergency patching of exposed builds Move affected systems to the fixed React and Next.js versions, then rebuild and redeploy rather than assuming a package-lock update is enough.
• Review server logs for exploit probing Search for unusual Flight protocol requests, malformed POST bodies, and repeated unauthenticated attempts that may indicate scanning against the vulnerable path.
• Protect credentials reachable from the web tier Reduce the value of server compromise by separating runtime secrets from application logs, tightening service account scope, and rotating any credentials the affected servers could access.
• Validate CI/CD supply chain after remediation Confirm that your pipelines are shipping patched server bundles and that no cached artifact or outdated build image can reintroduce the vulnerable framework path.

Key takeaways

• A server-side React or Next.js execution flaw is also an identity-risk event because it can expose the secrets and service accounts the server can reach.
• Public proof-of-concept code makes patch latency the main risk multiplier, especially for internet-facing applications using shared framework packages.
• The most effective response is rapid version remediation backed by deployment inventory, log hunting, and credential containment around the affected web tier.

Key terms

• Flight protocol: Flight is the server-side data transport used by React Server Components to exchange component state between client and server. In this context, it matters because flaws in how that data is parsed or deserialized can turn ordinary requests into execution paths, especially when the server trusts input too early.
• Server-side rendering: Server-side rendering is the practice of generating application output on the server before it reaches the browser. It improves performance and user experience, but it also expands the trusted execution surface, which means bugs in parsing, hydration, or component transport can have server-level consequences.
• Public-facing application: A public-facing application is any internet-accessible service that can be reached directly by external users or attackers. These systems are attractive initial access targets because they are exposed by design, and flaws in them often create a direct path to code execution or data access.
• Server-side execution: Server-side execution occurs when code runs in the application host environment rather than in a user browser. If an attacker can trigger it through crafted input, the server may reveal secrets, access internal resources, or become a foothold for broader compromise.

What's in the full analysis

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

• Exact patched React and Next.js build versions and the affected release branches
• The analyst's recommended server-side audit steps for identifying vulnerable deployments
• The MITRE ATT&CK mapping and exploit context for public-facing application compromise
• The additional incident roundup items included in the weekly cyber watch post

👉 Anomali's full cyber watch post covers the patched versions, exploit context, and adjacent threat items.

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 practitioners connect application exposure to the identity controls that limit blast radius.