Notifications
Clear all
Topic starter
07/06/2026 8:41 pm
TL;DR: A critical CVSS 10.0 RCE flaw in React Server Components and Next.js lets an unauthenticated attacker trigger server-side code execution with a crafted HTTP request, affecting common production frameworks, according to Oligo Security. Static inventory alone is not enough; teams need runtime evidence of what is actually executed.
NHIMG editorial — based on content published by Oligo Security: Critical React and Next.js RCE Vulnerability (CVE-2025-55182 & CVE-2025-66478): What You Need To Know
By the numbers:
- A critical 10.0 CVSS remote code execution (RCE) vulnerability was disclosed on December 3, 2025 in React Server Components (RSC) and Next.js.
- Next.js 15.x and 16.x are affected, while patched releases include 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, and 16.0.7.
Questions worth separating out
Q: How should security teams respond when a framework RCE affects production applications?
A: Start by identifying which deployed services actually execute the vulnerable code path, then patch only the runtime instances that are confirmed active.
Q: Why do package inventories often miss the real risk in framework vulnerabilities?
A: Package inventories show presence, not execution.
Q: What should teams do when a vulnerability exists before authentication checks?
A: Treat the affected endpoint as a pre-authentication execution surface and reduce exposure immediately.
Practitioner guidance
- Patch every affected React and Next.js runtime Move React Server Components packages to 19.0.1, 19.1.2, or 19.2.1, and upgrade Next.js to the patched release that matches your branch.
- Verify active execution paths in production Check whether vulnerable components are loaded and running in production, then rank remediation only for paths that are truly executed.
- Block or isolate exposed Server Function endpoints Reduce immediate exposure by restricting public access to endpoints that accept RSC payloads, especially where authentication is not yet enforced.
What's in the full article
Oligo Security's full security research covers the operational detail this post intentionally leaves for the source:
- Version-by-version remediation guidance for affected React packages and Next.js branches.
- Dependency search workflow for confirming which components are actually executed in production.
- Runtime inspection examples for distinguishing exploitable code paths from dormant dependencies.
- Detection guidance for spotting active exploitation attempts in live application processes.
👉 Read Oligo Security's analysis of the React and Next.js RCE vulnerability →
React and Next.js RCE vulnerability: are your controls keeping up?
Explore further
08/06/2026 8:20 am
Runtime deserialization exposure is now an application identity problem, not just an AppSec bug. When framework internals can execute attacker-controlled input before authentication, the security boundary has shifted from login control to runtime trust. That means the control question is no longer only whether code is patched, but whether the live process is allowed to execute untrusted payloads at all. Practitioners should treat exposed RSC paths as privileged execution surfaces.
A few things that frame the scale:
- 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
- 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage.
A question worth separating out:
Q: How do you know if zero-day response is actually reducing exposure?
A: You know it is working when the set of running vulnerable components shrinks, exploit attempts are visible in runtime telemetry, and patched versions replace active instances in production. The goal is not just fewer findings in a scanner. It is a measurable reduction in live, reachable execution paths.
👉 Read our full editorial: Critical React and Next.js RCE exposes runtime deserialization risk
