RSC Vulnerabilities in Next.js: December 2025 Pt. 2

Written by Rafter Team
January 30, 2026

React Server Components (RSC) have quickly become a cornerstone of modern Next.js applications. They promise performance, better data-fetching ergonomics, and cleaner mental models. But over the past year, security research has shown that RSC isn't just a rendering abstraction—it's a new server-side protocol surface.
After the React2Shell incident pushed the community to scrutinize RSC more closely, two additional vulnerabilities have now been disclosed: CVE-2025-55184 and CVE-2025-55183. These issues affect frameworks that handle React Server Components requests, including the Next.js App Router, and were responsibly disclosed through Vercel and Meta's bug bounty program by an external security researcher.
There's no evidence of active exploitation. Still, the implications are serious enough that every team using RSC should understand what's happening—and act.
Why React Server Components Are a Security Boundary
React Server Components change how requests flow through your application. Instead of traditional REST or RPC endpoints, RSC relies on serialized payloads that the server deserializes and executes to determine what to render.
This introduces several important properties from a security perspective:
- Requests may be unauthenticated
- Payloads can be deeply nested and non-obvious
- Deserialization happens before your application logic
- Execution paths are framework-controlled, not app-controlled
React2Shell was the first major wake-up call that RSC parsing logic could be abused. These newly disclosed CVEs reinforce the same lesson: RSC requests should be treated as untrusted input, just like JSON, protobufs, or file uploads.
CVE-2025-55184: High-Severity Denial of Service via RSC Deserialization
Severity: High
Impact: Denial of Service (DoS)
This vulnerability allows a malicious HTTP request sent to any App Router endpoint to cause the server process to hang and consume CPU indefinitely when the RSC payload is deserialized.
Why this is dangerous
- No authentication required
- A single crafted request can stall a server process
- CPU exhaustion can cascade under load
- Easy to automate at scale
From an attacker's perspective, this is a low-cost, high-impact denial-of-service vector. From a defender's perspective, it's particularly troubling because it operates below the application layer—your own code never gets a chance to reject the request.
The incomplete fix problem
An initial fix was released after discovery, but follow-up analysis revealed that it did not fully mitigate all payload variants. This led to an additional related issue being tracked as CVE-2025-67779.
This matters for two reasons:
- Teams that believed they were fully protected may still be vulnerable
- It highlights how hard it is to comprehensively secure serialization protocols
Key takeaway: Even if you patched for React2Shell or early RSC issues, you must upgrade again to the latest versions.
CVE-2025-55183: Source Code Exposure of Server Actions
Severity: Medium
Impact: Source code exposure
The second vulnerability allows a malicious HTTP request to retrieve the compiled source code of Server Actions from an App Router endpoint.
What attackers can see
- Business logic
- Validation rules
- Control flow
- Internal assumptions
What attackers cannot see
- Environment variables
- Secrets stored in runtime configuration
- External credentials (unless hardcoded)
That last caveat is important. This vulnerability does not automatically expose secrets, but it will reveal anything you've embedded directly into a Server Action's code. That includes proprietary logic and security-sensitive assumptions.
Why this still matters
Even without secrets, source exposure can:
- Leak intellectual property
- Enable targeted exploit development
- Reveal undocumented internal APIs
- Reduce the cost of reverse engineering
In isolation, this is a medium-severity issue. In combination with other vulnerabilities, it can become much more serious.
Key takeaway: Server Actions should be written as if their code might eventually be read.
Who Is Affected?
These vulnerabilities impact:
- Next.js App Router
- Any framework handling React Server Components requests
- All versions prior to the latest patched releases
Importantly, even applications that patched against React2Shell may still be affected. The fixes are cumulative, and security hardening is ongoing.
There is currently no evidence of exploitation in the wild, but that should not be interpreted as a safety guarantee. Many protocol-level vulnerabilities are exploited quietly or opportunistically long after disclosure.
What You Should Do Right Now
- Update to the Latest Patched Versions
This is non-negotiable.
- Upgrade Next.js and React to the latest security-patched releases
- Do not rely on partial or historical fixes
- Monitor official advisories closely
Updates related to React2Shell and these new CVEs will continue to be published in the React2Shell Security Bulletin.
- Audit Your Server Actions
Treat Server Actions as semi-public code:
- Remove sensitive logic where possible
- Never hardcode secrets or credentials
- Keep business rules minimal and composable
- Move critical logic behind authenticated APIs when appropriate
- Add Defensive Controls Around RSC Endpoints
While framework fixes are primary, defense-in-depth still matters:
- Apply rate limiting where possible
- Monitor CPU usage spikes
- Set alerts for abnormal request patterns
- Isolate workloads if feasible
- Track Security Bulletins, Not Just Releases
Security fixes don't always align cleanly with major releases. Subscribe to advisories and bulletins rather than relying solely on version bumps.
Lessons for Framework Security (and for Developers)
These disclosures reinforce a broader pattern we've seen across modern frameworks:
- Serialization formats are attack surfaces
- "Framework magic" often hides complex execution paths
- Server-side abstractions need protocol-level scrutiny
- Community security research is essential—and effective
The React ecosystem benefits enormously from external researchers and responsible disclosure programs. These vulnerabilities were found because the community kept digging after React2Shell, not because everyone assumed the problem was solved.
At Rafter, this is exactly the class of issue we pay attention to: vulnerabilities that don't live in application code, but in the infrastructure and abstractions developers trust by default.
Final Takeaways
- Two new CVEs affect React Server Components in Next.js
- CVE-2025-55184 enables high-severity denial-of-service
- CVE-2025-55183 exposes Server Action source code
- No known exploitation—but real, practical risk
- Even previously patched apps must upgrade again
React Server Components are powerful, but power comes with responsibility. Treat RSC requests as untrusted input, stay current on patches, and design your server-side logic with the assumption that abstractions can leak.
Security is not a one-time fix—it's an ongoing process.
Related Resources
Critical React Security Vulnerability: Upgrade Now (CVE-2025-55182)
A Crash Course on Vulnerabilities
Automated Security Scanning Best Practices
Need Help Securing Your App?
Vulnerabilities like this are why automated security scanning is essential. Rafter helps you catch security issues before they become emergencies.