Understanding CVE-2025-55182

What You Need to Know

On November 29th, security researcher Lachlan Davidson reported a devastating flaw in how React decodes payloads sent to React Server Function endpoints. The vulnerability enables attackers to execute arbitrary code on servers without any authentication, making it one of the most severe security issues in React’s history.

Who Is Affected?

If you’re using React Server Components or React Server Functions in your application, you are potentially vulnerable. Even if you haven’t explicitly implemented Server Function endpoints, your application may still be at risk if it supports React Server Components.

Affected React Packages

The vulnerability exists in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of:

• react-server-dom-webpack
• react-server-dom-parcel
• react-server-dom-turbopack

Affected Frameworks and Tools

Popular frameworks and bundlers that depend on these packages are also affected:

• Next.js (versions 15.0.x through 16.0.x)
• React Router (unstable RSC APIs)
• Expo
• Redwood SDK
• Waku
• @vitejs/plugin-rsc
• @parcel/rsc

Understanding the Vulnerability

To understand how serious this is, let’s break down what makes this vulnerability so dangerous.

React Server Functions: The Attack Surface

React Server Functions enable clients to call functions on a server using an RPC-over-HTTP pattern. React translates client requests into HTTP requests, which are processed on the server and return data to the client. This architecture relies on the React Flight Protocol for serializing and deserializing data.

The Flaw: Insecure Prototype References

The vulnerability stems from how React handled object property traversal during deserialization. Prior to the patch, React didn’t verify whether a requested key was actually set on an object during reference resolution. This oversight allowed attackers to access JavaScript’s prototype chain, including the dangerous Function constructor.

Here’s a simplified example of how the attack works:

1. An attacker crafts a malicious HTTP request with specially formatted chunks
2. These chunks exploit prototype chain traversal to access Function.constructor
3. The payload tricks React into executing arbitrary code during the deserialization process
4. All of this happens before any authentication or validation checks

What Makes This Critical

Several factors elevate this to maximum severity:

• No authentication required: Attackers don’t need credentials
• Pre-validation execution: The exploit triggers during deserialization, before any security checks
• Wide attack surface: Any Server Function endpoint can be targeted
• Simple exploit: Setting a header like Next-Action: foo is sufficient to trigger the vulnerability
• Complete system compromise: Attackers achieve full remote code execution on the server

Immediate Action Required

Step 1: Check Your Dependencies

First, determine if you’re using any affected packages. Check your package.json for:

npm list react-server-dom-webpack react-server-dom-parcel react-server-dom-turbopack

Step 2: Update Immediately

React has released patched versions: 19.0.1, 19.1.2, and 19.2.1

For Next.js Users

Update to the latest patched version in your release line:

npm install next@15.0.5   # for 15.0.x
npm install next@15.1.9   # for 15.1.x
npm install next@15.2.6   # for 15.2.x
npm install next@15.3.6   # for 15.3.x
npm install next@15.4.8   # for 15.4.x
npm install next@15.5.7   # for 15.5.x
npm install next@16.0.7   # for 16.0.x

If you’re on a Next.js 14.3.0-canary.77 or later canary release, downgrade to the latest stable 14.x:

npm install next@14

For React Router Users

If using React Router’s unstable RSC APIs:

npm install react@latest react-dom@latest
npm install react-server-dom-parcel@latest
npm install react-server-dom-webpack@latest
npm install @vitejs/plugin-rsc@latest

For Other Frameworks

• Expo: Update to latest react-server-dom-webpack
• Redwood SDK: Ensure rwsdk>=1.0.0-alpha.0
• Waku: Update all React packages to latest versions
• @vitejs/plugin-rsc: Update plugin and React packages

Step 3: Verify and Test

After updating:

1. Run your test suite to ensure compatibility
2. Test critical user flows in a staging environment
3. Monitor your application logs for any issues
4. Verify the updated versions in your package-lock.json or yarn.lock

Are You Safe?

Your application is NOT affected if:

• Your React code doesn’t use a server at all (client-only applications)
• You don’t use a framework, bundler, or plugin that supports React Server Components
• You’re using React versions prior to 19.0 (though you should still update for other reasons)

Hosting Provider Mitigations

Many hosting providers have implemented temporary mitigations. However, these are not sufficient to fully secure your application. You must still update your dependencies immediately. Temporary mitigations are merely stopgaps while you deploy proper fixes.

The Technical Deep Dive

For those interested in the technical details, the vulnerability exploits several clever tricks:

1. Prototype pollution via chunk references: The attacker uses specially crafted chunk references with __proto__ to access the prototype chain
2. Self-referencing chunks: Using the $@ syntax, chunks can reference themselves, creating circular dependencies that bypass normal validation
3. Function constructor invocation: By overwriting the then method with Chunk.prototype.then, the exploit gains access to the JavaScript Function constructor
4. Execution during deserialization: The payload executes during the parsing phase, before any application-level security checks

The patch adds a simple but crucial check using hasOwnProperty to ensure only actual object properties are accessed, preventing prototype chain traversal.

Lessons Learned

This vulnerability highlights several important security principles:

1. Trust boundary validation: Never deserialize untrusted data without strict validation
2. Defense in depth: Security checks should occur at multiple layers, not just after processing
3. Prototype chain safety: JavaScript’s prototype chain can be a security risk when handling user input
4. Framework complexity: As frameworks become more sophisticated, the attack surface grows

Timeline of Events

• November 29, 2025: Vulnerability reported via Meta Bug Bounty
• November 30, 2025: Confirmed and fix development begins
• December 1, 2025: Fix validated and rollout coordination starts
• December 3, 2025: Public disclosure and patched versions released

What’s Next?

1. Update immediately - This cannot be overstated
2. Monitor security advisories - Subscribe to security notifications for your frameworks
3. Review your security practices - Ensure you have processes for rapid security updates
4. Consider security audits - If you’re building critical infrastructure, regular security audits are essential

Conclusion

CVE-2025-55182 represents a severe security threat to applications using React Server Components. The combination of no authentication requirement, pre-validation execution, and full remote code execution capability makes this vulnerability extremely dangerous.

The React team, Meta security researchers, and the broader community responded quickly with patches and coordinated disclosure. Now it’s up to developers to deploy these fixes immediately.

Don’t wait. Update now.

---

Additional Resources

• Official React Security Advisory
• CVE-2025-55182 Technical Analysis
• Next.js Security Update

Credits

Special thanks to Lachlan Davidson for discovering and responsibly disclosing this vulnerability, and to the React team and community for their rapid response.

---

Stay safe, keep your dependencies updated, and always validate user input.