CVE-2025-55183

What it actually does

The flaw affects React Server Components transport packages react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack in versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1. The vulnerability can cause server-side application source code or implementation details to be exposed through React Server Components request/response handling. Although categorized as a deserialization-related issue, the practical impact is information disclosure rather than direct code execution based on the provided description. Exposed source can include server component logic, routing behavior, internal API usage, secrets accidentally embedded in code, authentication assumptions, and business logic that attackers can use to plan follow-on attacks.

Why it matters to the business

A successful attack can give an unauthenticated or low-privileged attacker visibility into proprietary application code and security-relevant implementation details. Even if the immediate CVSS score is medium, the EPSS score is high at 0.63073, indicating a comparatively elevated likelihood of exploitation activity. Because React Server Components are used in modern web application stacks and the issue has been public for 242 days, exposed internet-facing applications should be treated as higher priority for review. Business consequences include loss of intellectual property, increased risk of credential or secret exposure if sensitive values were hardcoded, faster discovery of secondary vulnerabilities, reputational impact, and potential compliance issues if source code reveals protected data handling logic.

How an attack unfolds

An attacker first identifies a web application using vulnerable React Server Components infrastructure, often by fingerprinting HTTP behavior, JavaScript bundles, framework-specific routes, response headers, or package disclosures. The attacker then sends crafted requests to endpoints that produce or consume React Server Components payloads. If the application is using an affected react-server-dom-* version, vulnerable request handling may cause source code or server-side component details to be returned or made inferable from the response. The attacker saves the exposed content, reviews it for secrets, privileged internal endpoints, authorization flaws, business logic weaknesses, dependency versions, and deployment assumptions, then uses that knowledge to conduct more targeted attacks such as credential abuse, API probing, access-control bypass attempts, or exploitation of unrelated bugs discovered in the exposed code. No CISA KEV listing or named threat actor exploitation is provided, and exploit maturity is listed as none, but the high EPSS score warrants proactive mitigation and retrospective review.

How to fix it

Update affected React Server Components packages immediately. Specifically audit and replace vulnerable versions 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, and 19.2.1 of react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack with a vendor-fixed version when available from the React/npm advisory stream. Regenerate lockfiles, rebuild application artifacts, redeploy all affected services, and verify that transitive dependencies are not pinning the vulnerable versions. If immediate upgrade is not possible, restrict access to RSC endpoints where feasible, place WAF/CDN controls in front of internet-facing applications, disable or remove unused React Server Components functionality, ensure source maps are not publicly served, and remove secrets from source code. The supplied package data also lists Ubuntu linux-aws for Ubuntu Pro 14.04 LTS fixed in 4.4.0-1113.119; where that package is actually in scope for an asset inventory item, apply the vendor kernel update as normal, but do not treat that OS kernel update as a substitute for updating the affected npm React packages.

How to confirm the fix worked

Confirm remediation by inspecting package manifests and resolved lockfiles for react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack and verifying that none resolve to 19.0.0, 19.0.1, 19.1.0, 19.1.1, 19.1.2, 19.2.0, or 19.2.1. Use npm ls, pnpm why, yarn why, software composition analysis, container image scanning, and CI dependency reports to detect both direct and transitive vulnerable versions. Rebuild and redeploy rather than only changing package.json. Validate running containers or serverless bundles by checking embedded node_modules, lockfiles, SBOMs, and build metadata. Perform a controlled request test against application RSC endpoints and confirm responses do not expose source code, server component implementation, raw module source, local file paths, or secrets. For Ubuntu linux-aws assets where applicable, verify the installed package version is 4.4.0-1113.119 or later using the platform package manager.

Typical attack path

1. Fingerprint public web applications for React Server Components usage or affected framework behavior.
2. Identify routes or requests that return React Server Components or Flight-style responses.
3. Send crafted unauthenticated or low-privileged requests to vulnerable RSC endpoints.
4. Collect responses that disclose source code, component implementation details, module references, or server-side logic.
5. Analyze exposed code for secrets, internal routes, authorization mistakes, dependency versions, and business logic weaknesses.
6. Use the recovered information to perform follow-on attacks against APIs, authentication flows, administrative functionality, or related infrastructure.

How to detect it

To determine whether exploitation already occurred, review web server, CDN, WAF, reverse proxy, and application logs for unusual access to routes that serve React Server Components or framework-specific server-rendered payloads. Look for high request counts from single IPs, unauthenticated enumeration of many routes, requests with RSC-related headers, unusual query parameters, repeated 200 responses with large response bodies, and requests followed by probing of internal-looking API paths discovered from code. If response-body logging, WAF capture, CDN sampling, or application telemetry is available, search for responses containing source-code markers such as "use server", "use client", import statements, local file paths, module source, environment variable names, or secrets. Review object storage, CDN caches, and static hosting origins for accidentally cached source disclosures. Correlate any suspicious source-code retrieval with later authentication failures, API enumeration, administrative route probing, secret use, or unusual outbound activity. Also search SBOMs, build logs, package-lock.json, yarn.lock, pnpm-lock.yaml, and deployed artifacts for vulnerable package names and versions to identify exposure windows.

• react-server-dom-webpack@19.0.0
• react-server-dom-webpack@19.0.1
• react-server-dom-webpack@19.1.0
• react-server-dom-webpack@19.1.1
• react-server-dom-webpack@19.1.2
• react-server-dom-webpack@19.2.0
• react-server-dom-webpack@19.2.1
• react-server-dom-parcel@19.0.0
• react-server-dom-parcel@19.0.1
• react-server-dom-parcel@19.1.0
• react-server-dom-parcel@19.1.1
• react-server-dom-parcel@19.1.2
• react-server-dom-parcel@19.2.0
• react-server-dom-parcel@19.2.1
• react-server-dom-turbopack@19.0.0
• react-server-dom-turbopack@19.0.1
• react-server-dom-turbopack@19.1.0
• react-server-dom-turbopack@19.1.1
• react-server-dom-turbopack@19.1.2
• react-server-dom-turbopack@19.2.0
• react-server-dom-turbopack@19.2.1
• "react-server-dom-webpack": "19.0.0"
• "react-server-dom-webpack": "19.0.1"
• "react-server-dom-webpack": "19.1.0"
• "react-server-dom-webpack": "19.1.1"
• "react-server-dom-webpack": "19.1.2"
• "react-server-dom-webpack": "19.2.0"
• "react-server-dom-webpack": "19.2.1"
• "react-server-dom-parcel": "19.0.0"
• "react-server-dom-parcel": "19.0.1"
• "react-server-dom-parcel": "19.1.0"
• "react-server-dom-parcel": "19.1.1"
• "react-server-dom-parcel": "19.1.2"
• "react-server-dom-parcel": "19.2.0"
• "react-server-dom-parcel": "19.2.1"
• "react-server-dom-turbopack": "19.0.0"
• "react-server-dom-turbopack": "19.0.1"
• "react-server-dom-turbopack": "19.1.0"
• "react-server-dom-turbopack": "19.1.1"
• "react-server-dom-turbopack": "19.1.2"
• "react-server-dom-turbopack": "19.2.0"
• "react-server-dom-turbopack": "19.2.1"
• Accept: text/x-component
• Content-Type: text/x-component
• RSC: 1
• Next-Router-State-Tree
• use server
• use client

What your security team should do

• Immediately inventory internet-facing applications using React Server Components and identify any use of react-server-dom-webpack, react-server-dom-parcel, or react-server-dom-turbopack in the affected versions.
• Prioritize patching public production applications first because the EPSS score is high and the issue has been public for an extended period.
• Regenerate lockfiles, rebuild artifacts, and redeploy; do not rely only on dependency manifest changes.
• Search repositories and exposed responses for hardcoded credentials, API tokens, private endpoints, signing keys, and other sensitive values that could have been disclosed through source exposure.
• Review CDN, WAF, reverse proxy, and application logs for unusual RSC endpoint enumeration or large-volume unauthenticated requests.
• If source exposure is suspected, rotate secrets present in application source or configuration and review access logs for follow-on use of those secrets.
• Add CI/CD policy gates to block the vulnerable react-server-dom-* versions from being introduced again.
• Disable public source maps and verify production builds do not expose debugging artifacts.
• Where applicable to asset inventory, also ensure Ubuntu linux-aws packages are updated to 4.4.0-1113.119 or later, while separately remediating the React npm packages.