What Happened
CVE-2025-55182 enables unauthenticated remote code execution through unsafe deserialization in React Server Components (RSC). Security researcher Lachlan Davidson reported the vulnerability, affecting applications using RSC in React 19 and Next.js. An attacker can craft a malicious HTTP request containing serialized data that, when processed by the server, executes arbitrary code with the privileges of the application server.
The vulnerability arises from how RSC handles data serialization between client and server. React Server Components serialize complex objects—including functions and references—to transmit them from server to client. The deserialization process on the server side lacked sufficient validation, treating incoming serialized payloads as trusted input.
Timeline
Key events include:
- Lachlan Davidson identified and reported the vulnerability.
- React team released patches for React 19.
- Next.js team released corresponding patches.
- Public disclosure occurred with CVE assignment.
- Immediate update recommendations were issued to all users.
The quick response from maintainers highlights the critical nature of this security issue.
Which Controls Failed
Input Validation on Deserialization: The application processed serialized data from HTTP requests without validating the structure or contents before deserialization. This was the primary control failure—treating external input as inherently safe.
Secure Defaults: Next.js applications using RSC were vulnerable by default. No additional configuration was required to enable the attack surface. Your application became exploitable simply by adopting the framework's recommended patterns.
Defense in Depth: Applications lacked secondary controls to detect or prevent code execution even if deserialization succeeded. No runtime monitoring flagged suspicious deserialization patterns. No application-layer sandboxing limited what deserialized code could access.
Dependency Management: Organizations running unpatched versions failed to maintain current security updates. While patches were released promptly, the window between disclosure and patching created exposure.
What the Standards Require
OWASP Top 10 2021 - A08:2021 Software and Data Integrity Failures addresses insecure deserialization. Applications must not deserialize untrusted data without integrity checks. Your deserialization routines should validate object types, enforce allowlists of acceptable classes, and implement signature verification for serialized data.
OWASP ASVS v4.0.3 - Requirement 5.5.3 mandates that deserialization of untrusted data be avoided or performed in a low-privilege environment with strict validation. If your application must deserialize external input, implement type checking before instantiation and run deserialization in an isolated context.
PCI DSS v4.0.1 - Requirement 6.3.2 requires that software development follows secure coding practices to prevent common vulnerabilities. This includes validating all inputs, which extends to serialized data formats. If your application processes cardholder data, accepting unvalidated serialized input violates this requirement.
NIST 800-53 Rev 5 - SI-10 (Information Input Validation) specifies that systems must check information inputs for accuracy, completeness, and validity. Serialized objects are information inputs. Your validation must occur before deserialization, not after—by the time you've deserialized malicious code, it's already executing.
ISO/IEC 27001:2022 - Annex A.8.16 (Monitoring activities) requires monitoring for anomalous behavior. Unusual deserialization patterns—large payloads, unexpected object types, deserialization from untrusted sources—should trigger alerts. Most organizations had no monitoring in place to detect exploitation attempts.
Lessons and Action Items
Patch immediately: If you run React 19 or Next.js with Server Components, update now. This is not a "patch in the next sprint" situation. Schedule emergency maintenance windows if necessary. The patches are available, and the vulnerability is public.
Inventory your deserialization points: Map every location in your codebase where you deserialize data from external sources—not just RSC, but JSON parsing, XML processing, protocol buffers, any format transformation. For each point, document what validation occurs before deserialization.
Implement deserialization allowlists: Maintain an explicit list of object types permitted during deserialization. Reject any serialized data that attempts to instantiate types outside this list. This is more secure than blocklisting dangerous types—attackers find new dangerous types faster than you can block them.
Add runtime monitoring: Deploy application-layer monitoring that flags deserialization of unexpected object types, deserialization from unusual sources, or deserialization volumes exceeding baseline patterns. Consider a scenario where your application normally deserializes 50 objects per request but suddenly receives requests with 5,000 serialized objects—that's a detection opportunity.
Isolate deserialization contexts: Run deserialization operations in restricted execution environments. If an attacker does achieve code execution through deserialization, containment limits the damage. Use separate service accounts with minimal privileges for components that handle external serialized data.
Test your patch deployment process: This incident reveals how fast you can actually push emergency updates to production. If it took you more than 24 hours to patch after release, your process needs improvement. Build runbooks for emergency patching that include testing procedures, rollback plans, and communication templates.
Review your framework adoption criteria: Before adopting new framework features—especially those involving serialization, code generation, or dynamic execution—require security review. Server Components introduced powerful capabilities but also expanded the attack surface. Your adoption checklist should include "What new deserialization or execution contexts does this create?"
Update your secure coding training: Many developers don't recognize serialized data as untrusted input requiring validation. Your training should explicitly cover deserialization risks and include code examples showing both vulnerable and secure patterns in the frameworks your team uses.
The core lesson: serialization is execution. When you deserialize data, you're running code—the code that reconstructs objects, invokes constructors, and restores state. Treat every deserialization point as an execution boundary requiring the same validation rigor you'd apply to eval() or exec(). One unvalidated deserialization endpoint is one remote code execution vulnerability.
