TL;DR: CVE-2025-55182 and related CVE-2025-66478 in Next.js can allow unauthenticated remote code execution through a crafted HTTP request against React Server Components, putting server-side code, data, and credentials at risk according to Cymulate. The vulnerability shows how application-layer trust collapses when exposed frameworks, dependency chains, and patch drift are not tightly governed.
At a glance
What this is: Cymulate reports that React Server Components CVE-2025-55182, and related Next.js CVE-2025-66478, can allow unauthenticated remote code execution through a crafted HTTP request.
Why it matters: This matters because web application teams often assume framework-level controls are already baked in, but exposed server components can still create direct server compromise risk, secret exposure, and infrastructure-level blast radius.
Context
React Server Components change where application logic executes, moving part of the rendering and data-handling path onto the server. That creates a security boundary that is easy to overlook when teams focus only on the browser-facing application layer.
The governance gap is not just patching, but knowing which deployed packages, bundlers, and plugins actually ship vulnerable modules. For IAM and NHI teams, the downstream risk is clear: server compromise can expose tokens, credentials, configuration secrets, and other machine-access material stored in the application runtime.
Key questions
Q: What breaks when a web framework can process attacker-controlled server-component input?
A: The trust boundary breaks first, because the application starts treating framework parsing and deserialization as safe when they are actually attacker-influenced. That can lead to unauthenticated code execution, secret exposure, and server compromise even when application authentication is intact. Teams should test the vulnerable request path itself, not only the surrounding perimeter controls.
Q: Why do vulnerable server components create such a large blast radius in web applications?
A: Because server-side rendering paths often sit close to configuration files, runtime secrets, APIs, and internal services. Once an attacker reaches code execution, the compromise can extend far beyond the browser-facing layer into tokens, data stores, and back-end systems. The risk is therefore architectural, not just patch-related.
Q: How do security teams know whether patching has actually removed React Server Components exposure?
A: They should verify the installed packages, lock files, build artefacts, and deployed images, then test whether the vulnerable deserialization path still responds in the characteristic way. A manifest that points to a fixed range is not enough if the runtime still contains vulnerable modules. Validation must happen at the artefact level.
Q: Should teams treat this as an application issue or a secrets governance issue?
A: They should treat it as both, because the application flaw becomes an identity and secrets problem once the server can read tokens, keys, or configuration material. That is why runtime secret scope, credential placement, and dependency inventory all matter. A narrow patch-only response leaves the governance gap intact.
Technical breakdown
How a crafted HTTP request reaches the vulnerable RSC Flight path
React Server Components use a serialized transport layer to move data between client and server rendering boundaries. In this case, the vulnerable Flight component accepts specially crafted requests that reach deserialization logic before normal application controls can intervene. That matters because the exploit path does not depend on user interaction or valid credentials. Once the parser accepts attacker-controlled input, the framework can be induced into unsafe server-side execution behaviour. The key issue is not just application code, but the trust placed in framework internals that are assumed to be safe by default.
Practical implication: treat framework transport paths as attack surface and validate them with targeted simulation, not just generic web scanning.
Why patch drift in React and Next.js creates hidden exposure
The article highlights that React 19, Next.js App Router deployments, and any tooling that embeds react-server-dom-* modules can inherit the flaw. In practice, teams may believe they are safe because a package manifest points to a patched range, while lock files or transitive dependencies still pin vulnerable code. That is a classic supply-chain and inventory problem, not merely a versioning problem. Security ownership therefore extends beyond the main application repository to build tooling, component trees, and deployment artefacts.
Practical implication: audit installed versions, transitive dependencies, and build outputs together, or the vulnerable code path may remain live after the manifest looks fixed.
What server compromise means for credentials, tokens, and data
Unauthenticated RCE on a web application server changes the incident from application weakness to full environment exposure. Once code execution is obtained, attackers can read configuration files, access session material, steal tokens, and modify server-side logic or content. For identity practitioners, the important point is that server compromise frequently becomes credential compromise because secrets are often colocated with runtime services. The framework flaw becomes an identity security event as soon as the server can reach secrets, APIs, or privileged back-end services.
Practical implication: assume exposed runtime code paths can become secret-exfiltration paths and tighten secret scoping around web application servers.
Threat narrative
Attacker objective: The attacker’s objective is to turn a single web request into server control that can be used for data theft, secret harvesting, and broader compromise.
- Entry occurs through a specially crafted HTTP request sent to the vulnerable React Server Components Flight component.
- Credential access is not required because the flaw permits unauthenticated remote code execution on the server.
- Impact follows as attackers gain a foothold that can expose data, steal tokens, modify server-side code, or disrupt service.
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.
- 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
App-layer trust is not a control boundary when the framework itself can execute attacker-supplied input. This article is a reminder that modern web stacks often inherit implicit trust in framework internals, especially around server components and deserialization paths. Once that trust is broken, the security model shifts from authentication and authorization to exploitability of the runtime itself. Practitioners should treat framework transport layers as first-class risk surfaces, not implementation detail.
Patch governance matters more than declared dependency ranges. The practical failure mode here is not simply a missing update, but a false sense of safety created by version ranges, transitive modules, and bundled tooling. That is especially relevant where build systems, plugins, and app frameworks distribute server-side code outside the main application owner’s direct view. Security teams need inventory confidence before they can claim remediation.
React and Next.js exposure becomes NHI risk the moment server-side secrets are reachable. This is where application security and identity governance meet. If the compromised runtime can access API keys, tokens, session material, or configuration secrets, then the incident expands into NHI credential exposure and privilege abuse. The governance lesson is to reduce runtime secret reach, not just to chase the vulnerable package.
Detection and simulation should focus on the actual deserialization path, not just perimeter signatures. The article’s validation approach shows why exploit simulation has to mirror the framework’s vulnerable behaviour to be useful. Generic blocks may miss requests that look structurally normal but trigger unsafe server processing. Security teams should base control testing on exploit mechanics, because that is what reveals whether monitoring, WAF rules, and endpoint controls can truly see the attack.
What this signals
Runtime trust has to move from assumption to verification. React and Next.js teams should assume that any server-side framework path can become an attacker entry point until versions, bundles, and deployed artefacts are verified against the fixed release set. The practical change is to test the runtime you actually ship, not the dependency declaration you intended to ship.
Secret exposure is the downstream consequence that matters most to identity teams. When a framework flaw gives code execution on a web server, the next question is which credentials, tokens, and service accounts sit within reach. That makes runtime secret scoping and dependency inventory part of identity governance, not just application hygiene.
For practitioners
- Validate installed React and Next.js versions Inspect lock files, container images, and deployed artefacts to confirm the actually installed react-server-dom-* and Next.js versions, not just the manifest range.
- Prioritise patching of vulnerable server components Upgrade affected react-server-dom-* packages to the vendor-specified fixed releases and move any impacted Next.js instances to patched versions before extending the fix to embedded tooling.
- Audit transitive dependencies and bundled plugins Check frameworks, bundlers, and plugins that package vulnerable RSC modules so the exposure is removed from every build and deployment path.
- Test detection with benign exploit simulation Use safe attack simulation to verify whether SIEM, WAF, endpoint security, and response workflows detect the vulnerable RSC deserialization pattern without executing malicious code.
- Reduce secret reach from web runtimes Review which tokens, API keys, and configuration secrets are available to server-side application processes and narrow that access to the minimum necessary scope.
Key takeaways
- The central risk is not only unauthenticated RCE, but the collapse of trust in a framework path that teams often assume is safe by design.
- The practical exposure includes server-side data, tokens, configuration material, and any back-end service reachable from the compromised runtime.
- Teams reduce risk by verifying installed artefacts, removing vulnerable modules from every build path, and tightening secret reach around application servers.
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, MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Exposed React Server Components and Next.js builds create framework-level misconfiguration exposure. |
| Recommendation — Audit framework deployments for security misconfiguration and remove vulnerable server-component paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Server compromise becomes identity risk when runtime services can reach secrets and back-end entitlements. |
| Recommendation — Restrict application runtime entitlements to the minimum required for server-side execution. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | The article centers on identifying, validating, and patching a critical framework vulnerability. |
| Recommendation — Continuously inventory and patch affected framework components across build and deployment pipelines. | ||
| MITRE ATT&CK | TA0001;TA0006;TA0007;TA0008 — Initial Access; Credential Access; Discovery; Lateral Movement | The exploit chain starts with unauthenticated access and can progress into secret theft and wider compromise. |
| Recommendation — Map the exploit path to ATT&CK and hunt for request patterns that precede server-side compromise. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Server-side compromise can expose tokens, API keys, and configuration secrets accessible to the runtime. |
| Recommendation — Scan application runtimes for exposed secrets and revoke any credentials reachable from vulnerable servers. | ||
Key terms
- Server Component Deserialization: The process of turning encoded framework messages back into executable server-side structures. In React Server Components, unsafe deserialization can become a code execution path if attacker-controlled input reaches trusted processing logic without proper validation.
- Patch Drift: A condition where the intended fixed version and the version actually running in production are not the same. It often appears through lock-file changes, bundled dependencies, container rebuilds, or transitive modules that keep vulnerable code in place.
- Runtime Secret Reach: The set of credentials, tokens, keys, and configuration material that a live application process can access. Reducing that reach limits how far a compromise can go, especially when server-side code execution exposes data and privileged back-end services.
- Framework Transport Path: The internal request-and-response channel a framework uses to move data between client and server components. Security teams need to treat this path as attack surface because flaws here can bypass normal application-layer expectations and trigger unsafe server behaviour.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners who need to reduce credential exposure paths. It helps security and identity teams connect runtime compromise to secret scoping, ownership, and lifecycle control.
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