TL;DR: React and Next.js server-side rendering flaws can let an unauthenticated request trigger remote code execution on exposed applications, and proof-of-concept code is already public, according to Anomali. Rapid patching, workload inventory, and server-side request review now matter more than assuming default frameworks are safe.
At a glance
What this is: Anomali flags two related React and Next.js remote code execution flaws that can be triggered without authentication on exposed server-side apps.
Why it matters: IAM and security teams should treat framework exposure as a runtime control problem because unauthenticated server-side execution can bypass normal access assumptions and expand blast radius quickly.
Context
React Server Components process data on the server, which means a flaw in that path can turn a normal web request into code execution before application-level controls ever have a chance to act. In this case, the issue affects React itself and the Next.js builds that embed the vulnerable server packages, so the security problem is not limited to teams that deliberately adopted a bespoke architecture.
The governance gap is assumption drift: teams often trust a modern framework to abstract away security decisions, but server-side component handling still inherits all the risks of public exposure, patch lag, and incomplete inventory. Where server-side apps sit behind cloud infrastructure, identity and access controls only help if the runtime itself is patched and the deployment path is understood.
Key questions
Q: What breaks when a server-side rendering flaw is present in a public React or Next.js app?
A: A public server-side rendering flaw can let a crafted HTTP request reach code execution before the application’s normal access checks matter. That breaks the assumption that only authenticated users can influence server behavior. The practical effect is that internet exposure, not just identity compromise, becomes the immediate risk driver.
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: What do security teams get wrong about severity-based patching?
A: They often assume a high score means equal urgency everywhere. In practice, exploitability depends on reachability, authentication, and the configuration actually deployed in your environment. A lower-scoring vulnerability on a privileged or internet-facing asset may be more dangerous than a higher-scoring flaw on an isolated system.
Q: What should teams do when a public RCE in a framework is already being exploited?
A: Treat the issue as a potential incident, not a simple patch task. Patch affected systems, isolate exposed applications where needed, review authentication and secret exposure around those workloads, and search for compromise indicators before declaring recovery. If internet-facing systems were vulnerable, assume the attacker may already have attempted or achieved execution.
Technical breakdown
Server-side component deserialization creates execution risk
React Server Components use the Flight protocol to move component data between client and server. The weakness described here sits in unsafe deserialization, where attacker-controlled input is processed in a way that can reconstitute executable server-side behavior. That matters because deserialization bugs are rarely about authentication alone; they are about whether the application trusts structured input before it has fully validated the message shape and content. When server frameworks embed this logic, every exposed deployment inherits the flaw until patched.
Practical implication: Treat any exposed server-side component path as exploitable until patched builds are confirmed in production.
Why unauthenticated HTTP requests are enough here
The article says a crafted HTTP request can trigger attacker-supplied JavaScript on the server without authentication. That removes the need for stolen credentials, session abuse, or privilege escalation as a prerequisite. In practical terms, this shifts the defender's task from access governance to exposure management, because the attack surface is any internet-reachable application running the vulnerable code path. Once proof-of-concept code becomes public, opportunistic scanning usually follows quickly.
Practical implication: Prioritise external exposure review and emergency patch validation over credential-centric triage.
Framework bundling turns one flaw into a broad platform issue
Next.js bundled the vulnerable React server packages, which is why the same flaw appeared across both product lines. This is a supply chain and dependency management problem as much as an application bug, because downstream applications inherit upstream server code paths they may not fully understand. The control gap is incomplete component inventory combined with patch delay, especially where teams rely on default framework scaffolding and assume security is handled elsewhere.
Practical implication: Inventory framework versions across environments and verify that build pipelines are shipping the patched server packages.
Threat narrative
Attacker objective: Gain arbitrary code execution on vulnerable public-facing applications without needing valid credentials.
- Entry occurs through a crafted HTTP request sent to an exposed server-side application running the vulnerable React or Next.js code path.
- Credential access is not required because the request exploits unsafe deserialization in the Flight protocol and reaches server execution directly.
- Impact is remote code execution on the server, which can support follow-on webshell-style activity, data theft, or further intrusions.
Breaches seen in the wild
- ASP.NET machine key attacks 2025: Developers copied ASP.NET machine keys from public sources; attackers used one to run Godzilla via ViewState. Microsoft found 3,000+ such keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Server-side framework trust is the real governance failure here: teams often assume that a modern web framework absorbs risk, but unauthenticated execution on the server proves the opposite. The issue is not simply a patchable bug, it is a failure to treat framework internals as part of the attack surface. Practitioners should manage server-side component paths with the same discipline they apply to internet-facing infrastructure.
Public proof-of-concept code changes exploit economics fast: once working code circulates, scanning shifts from targeted abuse to broad opportunistic exploitation. That makes patch latency and exposure inventory the most important variables in the first response window. The practical conclusion is simple: if a vulnerable build is reachable, assume it will be found.
Dependency bundling creates invisible shared risk: when one upstream package is embedded in many downstream applications, a single flaw becomes a platform-wide governance issue. This is especially relevant for identity and access teams that rely on application boundaries as a control assumption, because those boundaries collapse when runtime code is the entry point. The control lesson is to govern version drift as an exposure problem, not just a software hygiene issue.
Server-side request review is a control gap, not a nice-to-have: server logs and request analytics are part of the detection layer for exploit attempts against public-facing frameworks. Where organisations do not review unusual protocol-specific requests, they lose the chance to spot exploitation patterns before impact broadens. The practitioner implication is to make framework-specific telemetry part of the security baseline.
What this signals
Exposure management now sits alongside identity governance for application risk: when framework internals can be triggered by a single request, the control question is not who is allowed in, but what code is reachable from the internet. That is a useful reminder for IAM and PAM teams that application runtime exposure can bypass well-designed access policy if the underlying build is unsafe.
Protocol-specific telemetry becomes part of the security baseline: organisations that can distinguish normal server-rendering traffic from exploit-shaped requests are better placed to catch abuse early. The practical signal is to integrate framework-aware logging into detection engineering and to treat unusual server component requests as a real investigation trigger.
For practitioners
- Inventory every React and Next.js workload Map all internet-facing and internal applications to their exact React and Next.js versions, including build pipelines that may ship different packages than production code appears to show.
- Upgrade to patched framework releases Move exposed instances to the patched React and Next.js builds listed in the article, then verify that deployment artefacts and containers actually contain the fixed server packages.
- Review server logs for Flight protocol abuse Hunt for unusual server-side component requests, especially crafted HTTP traffic that deviates from normal application request patterns or arrives in bursts after public disclosure.
- Reassess internet exposure for server-side apps Confirm which applications are publicly reachable, whether edge controls and WAF rules can reduce exposure, and whether any legacy routes still expose vulnerable server rendering paths.
Key takeaways
- A server-side framework flaw can bypass normal authentication assumptions because the request itself becomes the attack vehicle.
- Public proof-of-concept code makes patch latency and internet exposure the main determinants of risk.
- The most effective limiters are version inventory, rapid upgrade, and log review for exploit-shaped server requests.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | The article describes unauthenticated exploitation of exposed server-side apps. |
| T1059 — Command and Scripting Interpreter | The flaw enables attacker-supplied JavaScript execution on the server. | |
| Recommendation — Map exposed React and Next.js endpoints to T1190 and prioritise internet-reachable instances for patching. Hunt for exploit attempts that result in server-side command or scripting execution. | ||
| NIST CSF 2.0 | PR.DS-10 — Availability of Information and Technology Resources | Rapid patching and exposure control support resilient service delivery after disclosure. |
| DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events | The article recommends reviewing logs for suspicious server-side request patterns. | |
| Recommendation — Use PR.DS-10 to reduce service disruption by accelerating patch rollout for exposed applications. Use DE.CM-01 to monitor for abnormal server-side requests and trigger investigation on unusual Flight traffic. | ||
| OWASP ASVS | V13 — Configuration | The issue arises from vulnerable framework configuration and deployment assumptions. |
| Recommendation — Apply V13 to verify framework versions and deployment settings before exposing server-rendered applications. | ||
Key terms
- Server-Side Components: Server-side components are application elements executed on the server before a response is returned to the client. They reduce client complexity, but they also expand the trusted computing base because malformed requests can influence code paths that run with server privileges.
- 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.
- 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.
- Proof Of Concept Exploit: A proof of concept exploit is working code or request logic that demonstrates a vulnerability can be triggered in practice. It does not always equal mass exploitation, but once released publicly it often lowers the barrier for attackers, speeds up scanning, and increases the urgency of patching and monitoring.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management for practitioners who need to connect identity control to broader security operations. It helps security and architecture teams align governance decisions with the access and exposure problems that shape real-world risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org