Seal Security raises $13M series A to secure open source code at scale. Read full press release.
.avif)
Update: On December 4th, multiple exploitation attempts by China-nexus threat groups such as Earth Lamia and Jackpot Panda were observed by Amazon threat intelligence. This underscores the importance of securing this CVSS 10.0 vulnerability to keep your React servers safe. In light of this CVE’s severity and active exploitation, Seal Security is providing a free, no-strings-attached patch for React and Next.js users. Reach out to our team today to get started.
On December 3rd, CVE-2025-55182 was published by CISA.
This CVSS 10.0 vulnerability allows unauthenticated remote code execution, where a threat actor can exploit a flaw in React’s process to decode payloads sent to React Server Function endpoints.
It is important to note that while not every team is using React Server Function endpoints in their app, they still may be vulnerable if their app supports React Server Components. Despite not impacting React code that does not use a server, this CVE still has a wide reach, as Wiz estimates that 39% of cloud environments contain instances impacted by this vulnerability.
For Seal Security users, the security patch for CVE-2025-55182 is available. If you are not using Seal Security yet but require a patch, we are offering this patch to all React and Next.js users for free. Reach out to us today for access.
Discovered on November 29th, this Remote Code Execution (RCE) vulnerability take advantage of React Server Functions, which allow clients to call a function on a server.
CVE-2025-55182 exists in versions 19.0, 19.1.0, 19.1.1, and 19.2.0 of 3 React packages:
It also exists in applications using React Server Components with the App Router if they are running these versions of Next.js:
React provides integration tools that frameworks and bundlers use to run React code on clients and servers, and translates requests on the client into HTTP requests that are forwarded to the server. On the server, React then translates this request into a function call, and data is returned to the client.
The vulnerabilities allow an unauthenticated attacker to execute code remotely by crafting a malicious HTTP request to any Server Function endpoint. The execution occurs once the request is deserialized by React.
Because of the severity of this CVE, the React and Next.js team urges users to fix impacted versions immediately. Additionally, more details on the vulnerability and its exploitation will be shared by the React team once the rollout of the fix is complete
The vulnerable piece of code is in React code. We’ll look into react-server-dom-turbopack but other affected packages have similar code. The vulnerable code is at packages/react-server-dom-turbopack/src/client/ReactFlightClientConfigBundlerTurbopack.js.
Fixing commit: https://github.com/facebook/react/compare/v19.2.0...v19.2.1
This is a classic prototype pollution vulnerability. A malicious actor can craft an HTTP request with content that React will deserialize into a JavaScript object. On deserialization into a JavaScript object, it will include user-controlled data in the prototype chain of the object.
The vulnerable code then accesses the object’s property in a way that checks the prototype chain of the object, causing the exploit code to run. Such access happened when React resolved module exports via dynamically supplied metadata.
The fix for this type of vulnerability is very simple - use R to verify the property is the object’s own, and not coming from its prototype chain.
As to Next.js, its code is not by itself vulnerable. Rather, it includes the vulnerable code from React, bundled in its code. Fixing commit: https://github.com/vercel/next.js/compare/v16.0.6...v16.0.7
It does not alter Next.js code, but upgrades the bundled React code to include the verification.
The recent disclosure of this vulnerability has led to a proliferation of published Proof-of-Concepts (PoCs), many of which were released without rigorous verification. This issue was specifically addressed by the original reporter, Lachlan Davidson, on his dedicated resource site, react2shell.com.
Critically, several PoCs rely on improbable prerequisites being present on target servers. For example, some demonstrations assume the server has modules like vm, child_process, and fs loaded, which is often an unrealistic assumption in the context of this specific exploit scenario.
Here is an example of such PoCs, although incorrect, can help understand the vulnerability code flow. In this case, the author explains why this POC does not represent exploitation of CVE-2025-55182, but also why it is educational for users.
In a blog announcing CVE-2025-55182’s discovery, the React team urged users to update immediately.
They also provided instructions for popular libraries that bundle react-server implementation, such as Next.js, Vite RSC plugin, Parcel RSC plugin, Reactor Router RSC preview, RedwoodSDK, and Waku.
The Next.js team shared an update announcing that the following releases have a patch that fully resolves CVE-2025-66478:
For users relying on Next.js 14.3.0-canary.77 or a later canary release, Next.js recommends downgrading to the latest stable 14.x release using the instructions provided in their update.
Another CVSS 10.0 open source CVE means another fire drill for everyone who works on application security in your organization. Updating is the only mitigation tactic shared by the React team, and for Next.js users, it’s the recommended tactic for anyone on a 15.x or 16.x release.
Relying on updates alone to secure critical vulnerabilities like this can leave your team exposed while you try and coordinate with dozens of technical stakeholders, each potentially needing to perform manual changes to their code for it to work with the updated version. A process that’s chaotic to manage, and disrupts many parts of the organization.
Earlier this year, our research team highlighted CVE-2025-8869 in pip, which was a moderate-severity CVE that was known and had a public fix, but was not patched in an official pip release. This is just one of many examples of times a CVE is known, but an official release doesn’t make a fix available, creating an exposure window for your team.
For some versions, there is also a risk that this update may never come. Take a look at Next.js 14.3.0-canary.77 for example. As of December 3rd, the official recommendation for organizations relying on this version is to downgrade to the latest stable version of Next.js 14.x.
While this solution may eliminate the CVE from your application, it may cause issues for some teams, as they will be forced to migrate to 14.2.x version or earlier, as Next.js has not released a stable version of 14.3 yet. If your team has deployed the 14.3.0-canary.77 version for a specific use case, you may be left without certain functionalities.
While updates may have been made available for most versions of React and Next.js that were impacted by this CVE, it still exposes a crack in the foundation of traditional approaches to open source security.
Our platform was designed with these problems in mind.
Instead of waiting for an update or staying on unpredictable latest versions of a package, teams using Seal Security can stay ahead of open source vulnerabilities with our one-click patches and Sealed versions of packages and base images.
It’s a simple process that can save countless hours of work and allow your security and developer teams to work in harmony.
First, a vulnerability is discovered. Once Seal backports the public fix for past affected versions and verifies it, your team can install the Sealed version of the affected library, package, or base image in all repos and artifact registries with just one click, no unnecessary disruptions to developers, all while achieving better security outcomes.
This means that any CVEs in the versions of open source assets you rely on can be patched in just minutes, instead of diverting developers to tedious manual upgrades that slow your team down.
Our team also goes the extra mile to make sure our platform supports versions that may not have received public updates or have reached End-of-Life, like Next.js 14.3.0-canary.77, so you can be confident that your application is CVE-free without compromise.
Take our Product Tour to see how we do it in action today, and stand tall against attacks with CVE-free versions of the libraries, containers, and operating systems.
