Unpacking CVE-2025-55182: React Server Components RCE Exploit Deep Dive and SBOM-Driven Identification

On December 3, 2025, a pre-authenticated remote code execution (RCE) vulnerability was disclosed in React Server Components, tracked as CVE-2025-55182. The vulnerability affects following React components:

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

Versions:

• 19.0.0
• 19.1.0
• 19.1.1
• 19.2.0

The vulnerability is caused by unsafe deserialization of user supplied data from HTTP requests to Server Function Endpoints. PR 35277 includes a fix for the vulnerability. nextjs is impacted by this vulnerability due to its dependency on React Server Components. The nextjs vulnerability is tracked as CVE-2025-66478 and issue 86790.

Nextjs applications using the React Server Components with the App Router are impacted by this vulnerability. Next.js 15.x, Next.js 16.x, Next.js 14.3.0-canary.77 and later canary releases are affected. Following versions of Nextjs includes the fix:

• 15.0.5
• 15.1.9
• 15.2.6
• 15.3.6
• 15.4.8
• 15.5.7
• 16.0.7

The vulnerability is considered critical because multiple default configurations of React Server Components are vulnerable. Nextjs applications created using npx create-next-app are affected by default. Immediate remediation steps are to upgrade to the patched versions of Nextjs and React.

Technical Analysis

Note: Following analysis was performed on v19.2.0 in react repository. Use git checkout --detach v19.2.0 to checkout the tag.

React Server Components leverage the Flight Protocol for interacting with client components. This protocol takes care of serialization, deserialization and streaming of data between server and client. The server components use a module resolution system to lookup and execute server-side code based on request. The vulnerability stems from the requireModule function directly accessing object’s properties based on user supplied data without validation, resulting in Prototype Pollution vulnerability.

Looking at the following snippet from packages/react-server-dom-webpack/src/client/ReactFlightClientConfigBundlerWebpack.js, which is one of the vulnerable code paths and patched in #35277, we can see evidence of the vulnerability.

1
export function requireModule<T>(metadata: ClientReference<T>): T {
2
  let moduleExports = __webpack_require__(metadata[ID]);
3

4
  return moduleExports[metadata[NAME]];
5
}

The vulnerability occurs when the metadata[NAME] is set to __proto__ or other internal properties of the object, and the moduleExports is accessed using the metadata[NAME] key. Typically it would mean that the attacker will have to find useful Javascript gadgets referenceable from the moduleExports to be able to exploit the vulnerability.

Real-world exploit code as seen in whiteov3rflow/CVE-2025-55182-poc, X/jlongster however was simpler than what we expected. Following payload could be used to execute arbitrary Javascript code on the server.

1
{
2
  "$ACTION_REF_0": "",
3
  "$ACTION_0:0": "{\"id\": \"vm#runInThisContext\", \"bound\": [\"console.log(\'Hello World\')"]}"
4
}

Here code can be anything like require('child_process').execSync('ls -la') to list the files in the directory by executing ls -la command. The payload references vm.runInThisContext Node.js builtin module to execute the code on the server.

Looking at the patch #35277, we can see the following hunk in packages/react-server/src/ReactFlightReplyServer.js, which specifically adds a guard against prototype pollution attempts by leveraging the __proto__ as the key name.

1
@@ -427,7 +574,7 @@ function reviveModel(
2
             value[key],
3
             childRef,
4
           );
5
-          if (newValue !== undefined) {
6
+          if (newValue !== undefined || key === '__proto__') {
7
             // $FlowFixMe[cannot-write]
8
             value[key] = newValue;
9
           } else {
10
@@ -441,24 +588,42 @@ function reviveModel(
11
   return value;
12
 }

The patch also fixes the vulnerable code by introducing a check using hasOwnProperty to ensure that the metadata[NAME] refers to a valid property of the moduleExports object and not inherited from the prototype.

1
--- a/packages/react-server-dom-parcel/src/client/ReactFlightClientConfigBundlerParcel.js
2
+++ b/packages/react-server-dom-parcel/src/client/ReactFlightClientConfigBundlerParcel.js
3
@@ -19,6 +19,8 @@ import {
4
} from '../shared/ReactFlightImportMetadata';
5
import {prepareDestinationWithChunks} from 'react-client/src/ReactFlightClientConfig';
6

7
+import hasOwnProperty from 'shared/hasOwnProperty';
8
+
9
export type ServerManifest = {
10
  [string]: Array<string>,
11
};
12
@@ -78,7 +80,10 @@ export function preloadModule<T>(
13

14
export function requireModule<T>(metadata: ClientReference<T>): T {
15
  const moduleExports = parcelRequire(metadata[ID]);
16
-  return moduleExports[metadata[NAME]];
17
+  if (hasOwnProperty.call(moduleExports, metadata[NAME])) {
18
+    return moduleExports[metadata[NAME]];
19
+  }
20
+  return (undefined: any);
21
}

Vulnerability Response

Security Teams who are required to respond to this vulnerability will be greatly benefited by maintaining a Software Bill of Materials (SBOM) for their applications. SBOMs are machine readable, standardized format for maintaining the inventory of various software components, their metadata and dependencies. SBOMs are useful only when they are adopted as a practice rather than an adhoc activity. For example, SBOMs can be used to:

• Identify applications that are vulnerable
• Identify vulnerable versions of Nextjs and React Server Components
• Identify point in code where the vulnerability was introduced and remediated

CISA’s Shared Vision on SBOM provides concise guidance on how SBOM can help in vulnerability management. At a minimum, security teams should build the following capabilities:

• Generate SBOMs for all applications meeting minimum elements
• Keep SBOMs up to date as part of the software development lifecycle
• Ability to query SBOMs for vulnerabilities and compliance

There are multiple free and open source tools available for SBOM generation such as trivy, syft, cdxgen, vet and more.

Using SafeDep for SBOM Generation and Query

SafeDep can help in generating and maintaining SBOMs, continuously, as part of the software development lifecycle. Following options are available:

• Using SafeDep free and open source tools for DIY SBOM generation and query
• Using SafeDep Cloud (SaaS) for continuous SBOM generation and query

SafeDep Open Source Tools

SafeDep vet can be used to generate SBOMs from source code, export it in a queryable format, and query it for vulnerabilities and compliance. In this specific case, we will demonstrate how to use vet to scan a GitHub organization to identify repositories that are vulnerable to CVE-2025-55182 and CVE-2025-66478.

Make sure you have vet installed in your system. For help with installation, refer to the vet Installation Guide.

Optional: Generate and setup a read-only GitHub Personal Access Token to provide larger rate limit for vet to scan GitHub repositories. Example: export GITHUB_TOKEN=your-token-here

Run vet to scan your GitHub organization and generate the report as an sqlite3 database.

1
vet scan --github-org https://github.com/your-github-org --report-sqlite3 /tmp/gh-org-vet.db

Note: The scan will take some time to complete depending on the number of repositories in the organization.

Run the following query to identify repositories that are vulnerable to CVE-2025-55182 and CVE-2025-66478.

1
SELECT
2
  p.name,
3
  m.namespace as repository,
4
  p.version,
5
  p.is_direct,
6
  m.display_path as manifest
7
FROM report_packages p
8
  JOIN report_package_manifest_packages mp ON p.id = mp.report_package_id
9
  JOIN report_package_manifests m ON mp.report_package_manifest_id = m.id
10
WHERE p.ecosystem = 'npm'
11
  AND p.name IN ('next', 'react')
12
  AND p.version IN ('19.0.0', '19.1.0', '19.1.1', '19.2.0', '15.0.4', `16.0.6`)
13
ORDER BY p.name, m.namespace, p.version;

Note: Not all vulnerable versions are included in the query.

Example output:

1
react|https://github.com/your-github-org/your-repository1.git|19.2.0|1|package.json
2
react|https://github.com/your-github-org/your-repository2.git|19.2.0|1|pnpm-lock.yaml
3
react|https://github.com/your-github-org/your-repository3.git|19.2.0|1|package.json

vet also supports an Agent Mode that can be used to query the SBOM database using natural language. See vet Agent documentation for more details. To use it, run the following command:

Set one of the supported LLM service API keys:

1
export GEMINI_API_KEY=your-gemini-api-key

Start vet in agent mode (query agent):

1
vet agent query --db /tmp/gh-org-vet.db --fast

Note: The --fast flag sets a fast model such as gemini-2.5-flash for the query agent. Omit it to use a reasoning model such as gemini-2.5-pro.

SafeDep Cloud

The following guidance is applicable only for users of SafeDep Cloud with GitHub App or one of the supported integrations already connected with their version control system. Here is how you can use SQL queries to find vulnerable repositories.

1. Login to SafeDep Cloud
2. Navigate to the Query tab
3. Execute the following SQL query:

1
SELECT projects.name,
2
  projects.version,
3
  packages.name,
4
  packages.version
5
FROM projects
6
  WHERE packages.name = 'react' and packages.version = '19.2.0'

Note: SafeDep Cloud SQL schema is denormalized to make it easier to query. It is not compatible with vet sqlite3 database schema.

References

• https://www.wiz.io/blog/critical-vulnerability-in-react-cve-2025-55182
• https://www.openwall.com/lists/oss-security/2025/12/03/4
• https://tonyalicea.dev/blog/understanding-react-server-components/
• https://gitnation.com/contents/meet-react-flight-and-become-a-rsc-expert