TL;DR: CVE-2025-55182 and CVE-2025-66478 expose React Server Components and some Next.js deployments to unauthenticated server-side RCE through insecure deserialization, according to Uptycs research, while additional React flaws can drive denial of service and source code exposure. The pattern is a dependency trust problem, not just a patching problem: production frameworks inherit risk when defaults ship unsafe assumptions.
At a glance
What this is: Uptycs says React Server Components and certain Next.js releases contain critical flaws that can enable unauthenticated RCE, plus separate React vulnerabilities that affect availability and code exposure.
Why it matters: This matters because application security teams must treat framework and dependency risk as a deployment control issue, not just a code review issue, especially where defaults expose production systems immediately.
By the numbers:
- React 19.0.0, 19.1.0, 19.1.1 and 19.2.0 are vulnerable packages named in the advisory.
- Next.js 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 and 16.0.7 are the fixed releases listed in the advisory.
- CVE-2025-55183 is rated CVSS 5.3 in the article.
Context
React Server Components changed how modern JavaScript frameworks move data and render content, but that also changed the trust boundary. When a framework serialises and deserialises complex component state, a flaw in that process can become a server-side execution path rather than a simple application bug. insecure deserialisation becomes especially dangerous when it sits inside default framework behaviour.
This article is mainly about supply-chain style application risk rather than isolated code defects. If your production posture depends on React or Next.js defaults, the exposure is immediate because the vulnerable path can exist before any custom hardening is added. That is a familiar pattern in modern web delivery, and it is usually worse in teams that assume framework updates are handled centrally.
Key questions
Q: What should teams do first when a framework RCE flaw exposes server-side application code?
A: Start by identifying which workloads expose the vulnerable endpoint, then patch the affected framework versions and isolate any public assets that may already have been touched. If the vulnerable process held secrets or service credentials, rotate them as part of containment. The priority is to remove the reachable attack path before assuming the application is clean.
Q: Why do React Server Components vulnerabilities create outsized risk in modern application stacks?
A: React Server Components run on the server, so flaws can affect both availability and confidentiality at the same time. A denial of service issue can stop an application from responding, while source code exposure can reveal implementation details, credentials, or secrets embedded in code. That combination makes rapid patching and dependency visibility essential.
Q: What are the signs that a framework issue is affecting production systems?
A: Look for unexplained crashes, service hangs, repeated server errors, abnormal resource consumption and version drift between build artefacts and approved patch levels. In source-code exposure cases, also review logs and error responses for leaked component details. These are operational symptoms that tell you the framework layer, not just the application code, needs attention.
Q: How should teams decide between patching the application and patching the framework?
A: When the flaw is in a shared framework component, patch the framework first because the application may not be able to compensate for a broken parser or runtime trust path. Application changes can harden exposure, but they do not remove a vulnerable inherited dependency. Use application fixes only as a compensating control while you move to the secured framework release.
Technical breakdown
How insecure deserialisation in React Server Components becomes code execution
React Server Components use the Flight protocol to move structured data between client and server. When that data is deserialised unsafely, an attacker can supply a crafted payload that the server interprets in an unintended way. In practice, the flaw is not about parsing text alone, but about letting attacker-controlled structure influence runtime behaviour inside the server rendering pipeline. That is why the issue can escalate from a malformed request to executable server-side logic. The dangerous part is the placement of the parser inside a trusted framework path, where application teams may not see or override the risk easily. See the Insecure Deserialisation Guide.
Practical implication: Treat framework deserialisation paths as attack surface and validate whether patched versions fully remove the vulnerable parser path.
Why default framework configurations widen exposure
The article stresses that the vulnerability appears in default configurations, which matters because default settings define the real-world blast radius of a framework issue. If a component ships enabled by default, most teams inherit the risk without a deliberate security decision. That turns patching into an operational dependency problem, since the affected package may sit inside an application framework, a bundled runtime, or a transitive component. This is why modern application security cannot stop at application code review. Teams need dependency visibility, version control, and release governance across the runtime stack, not just the repository. See the Zero-Day and Exploited Vulnerabilities Guide.
Practical implication: Inventory framework versions across build and runtime environments so default-exposed components are visible before attackers find them.
How availability and source-code exposure emerge from the same framework layer
The additional React issues show that one framework layer can produce different security outcomes depending on the failure mode. Malformed component trees and uncontrolled resource consumption can create denial of service, while flawed error serialization can leak source code or JSX components. These are not the same impact, but they come from the same governance weakness: trusting framework internals to remain safe under malformed or adversarial input. For practitioners, that means availability testing, debug-path review, and release hygiene all belong in the same control plane as vulnerability management. See the Secure Coding Guide.
Practical implication: Review SSR, error boundaries and debugging middleware together, because one framework defect can affect both resilience and confidentiality.
Threat narrative
Attacker objective: The attacker wants server-side execution or service disruption by turning framework trust assumptions into an execution or availability failure.
- Entry occurs when a remote, unauthenticated attacker sends a maliciously crafted payload to a vulnerable React Server Function endpoint.
- Credential access is not the issue here; the attacker instead abuses unsafe deserialisation inside the RSC Flight protocol to influence server behaviour.
- Escalation follows when the malformed payload is processed as trusted framework data and the server executes attacker-influenced logic.
- Impact is remote code execution on the server, with adjacent React flaws also enabling denial of service or source code exposure.
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.
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
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
Framework defaults are now security decisions, not convenience settings. The article shows that a vulnerable default configuration can expose production systems immediately, even when teams believe they have not changed anything risky. That is a governance problem as much as an engineering problem, because the control failure sits in the dependency chain, not the application logic. Practitioners should treat framework baseline approval as part of secure deployment governance, not a post-release clean-up activity.
Insecure deserialisation is still one of the cleanest paths from input to execution. React Server Components place structured data inside a server-side render path, which means malformed input can influence code flow if the parser trusts the payload too much. That is why deserialisation flaws remain especially dangerous in modern frameworks that abstract away runtime mechanics. The right takeaway is not only to patch, but to understand which runtime paths are no longer safe by design.
Dependency governance now has to cover framework inheritance. Next.js illustrates how one upstream weakness can cascade into widely deployed application stacks, and that makes version governance part of application security rather than an adjacent discipline. Teams that only track first-party code will miss the risk introduced by bundled frameworks, build-time defaults, and transitive runtime behaviour. Practitioners should connect software inventory, release control and vulnerability response into one operating model.
Source-code exposure and denial of service are governance failures in different clothes. The same framework family can fail confidentiality, integrity and availability depending on how malformed input is handled. That makes release review and error-path hardening part of the same assurance conversation, especially in server-side rendering environments. The practical conclusion is simple: if a framework owns the trust boundary, then it also owns the failure domain.
What this signals
Framework inheritance is becoming a core application security issue. Teams no longer manage only their own code. They also manage the security consequences of runtime frameworks that ship with trusted defaults, shared parsing logic and transitive exposure across multiple products.
Release governance now needs to cover render paths, not only package versions. A patched dependency is not enough if SSR settings, error handling and debugging middleware still leak useful information or preserve unsafe execution paths. Security teams should watch for this class of issue whenever a framework owns both data handling and server execution.
Dependency trust gaps will keep surfacing in modern web stacks. As frameworks take on more server-side responsibility, the security boundary moves farther from the application team and closer to the ecosystem. That makes continuous inventory, version enforcement and runtime validation part of normal programme hygiene, not exceptional response.
For practitioners
- Patch affected React and Next.js versions immediately Move vulnerable React and Next.js releases to the secured versions listed in the advisory, including the patched 15.x, 16.x and React 19 builds, and verify that bundled frameworks in other RSC-enabled products are updated too.
- Inventory all RSC-enabled applications and bundles Search build outputs, package manifests and runtime inventories for react-server-dom packages, Next.js App Router deployments and other frameworks that bundle react-server versions so you know where the exposure exists.
- Review server-side rendering and error handling paths Examine SSR configurations, error boundaries and debugging middleware to reduce the chance that malformed input or verbose errors can trigger denial of service or source code exposure.
Key takeaways
- The article shows how a framework deserialisation flaw can turn ordinary server-side rendering traffic into unauthenticated code execution.
- The same framework family also produced denial-of-service and source-code exposure issues, which means the risk is broader than one CVE.
- The most effective control is prompt framework patching paired with inventory, SSR review and stricter dependency governance.
Related NHI Mgmt Group resources: Insecure Deserialisation Guide · Zero-Day and Exploited Vulnerabilities Guide · Secure Coding Guide · Vulnerability Management Guide
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centers on default framework exposure and unsafe runtime handling. |
| Recommendation — Harden framework defaults and validate deployment settings before allowing production traffic. | ||
| MITRE ATT&CK | TA0001; TA0006; TA0040 — Initial Access; Credential Access; Impact | The flaw enables unauthenticated entry and then server-side impact through malicious payloads. |
| Recommendation — Map this issue to initial access and impact patterns, then hunt for exploitation attempts on exposed endpoints. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The advisory is fundamentally about identifying, prioritising and remediating vulnerable components. |
| Recommendation — Continuously inventory affected packages and verify that patched versions are deployed everywhere. | ||
| NIST CSF 2.0 | PR.DS-10 — Integrity is protected | Unsafe deserialisation undermines the integrity of server-side data processing and execution flow. |
| Recommendation — Apply integrity controls to framework data paths and validate that untrusted input cannot steer execution. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The flaw arises from insecure architecture and unsafe handling of untrusted framework data. |
| Recommendation — Review framework architecture and serialization boundaries so untrusted data cannot reach privileged server logic. | ||
Key terms
- Insecure deserialisation: Insecure deserialisation is a flaw where software rebuilds objects from incoming data without tightly controlling what can be instantiated. In platform software, it can turn a management interface into a code execution path when hostile payloads are accepted from a trusted channel.
- React Server Components: A server-side rendering model that moves part of the React component tree to the server and streams rendered output to the client. Because it runs inside the application trust boundary, flaws in this layer can expose code, secrets, or processing logic rather than only visual behaviour.
- 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.
- Dependency Governance Noise: Dependency governance noise is the gap between the number of issues a scanner reports and the number of issues a team can actually act on. High noise weakens trust in the programme, slows remediation, and can cause developers to ignore findings that matter.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the course when your programme needs a structured way to connect identity governance to adjacent security controls.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org