Explore all React2Shell and framework vulnerability guides →
A completed React2Shell ticket is not evidence that every subsequent React Server Components issue has been resolved. React published a separate advisory on December 11, 2025 and updated it on January 26, 2026. This follow-up concerns availability and source code exposure, and deserves its own deployment verification.
Which CVEs does the follow-up cover?
- Denial of service: CVE-2025-55184, CVE-2025-67779 and CVE-2026-23864, rated high severity (CVSS 7.5).
- Source code exposure: CVE-2025-55183, rated medium severity (CVSS 5.3).
- These issues do not provide remote code execution; React states that the React2Shell RCE patch remains effective against that RCE issue.
The advisory names react-server-dom-webpack, react-server-dom-parcel and react-server-dom-turbopack. Its January update identifies 19.0.4, 19.1.5 and 19.2.4 as fixed versions for this group of vulnerabilities. Earlier fixes were incomplete. Treat these as historical advisory-specific minimums and consult current framework guidance for later security updates.
Why availability and code exposure need different reviews
An availability investigation asks whether the service can continue processing normal requests. Review application errors, response latency and resource usage against a normal baseline. Traffic spikes can have many causes, so an overloaded server alone is not proof that a particular vulnerability was exploited. Keep timestamps, release identifiers and supporting logs with the incident record.
A source exposure review asks what information could become visible outside its intended audience. Examine how sensitive configuration reaches server code, and whether secrets were embedded in application source. Do not assume that a source disclosure advisory means every environment variable was exposed. Scope the investigation to the affected mechanism and your actual application; rotate credentials when the evidence and incident-response assessment call for it.
A practical RSC patch-verification checklist
- Identify every deployed application using RSC, including preview and staging systems with external access.
- Record the resolved RSC dependency versions for each deployed artifact. Compare them with the advisory rather than relying on the date of a previous patch ticket.
- Upgrade through the framework's supported release path, rebuild and deploy. Preserve the new artifact identifier and dependency evidence.
- Confirm production is serving the patched artifact, then test normal workflows and observe error and resource metrics.
- Keep unknown or inaccessible environments open in the tracking record until someone verifies them. Avoid marking a whole organization patched from a sample of one service.
What to ask of a website vulnerability report
Look for a clear test scope and an explanation of each result. A confirmed issue, a negative result for one executed check and an untested component are different outcomes. An external website scan can complement the release review, but it cannot read every dependency or configuration inside your deployment. Avoid attempting resource-exhaustion experiments against production just to obtain a visible failure.
Use MyPentest to run supported checks against your authorized website and review actionable findings. Coverage for these specific RSC CVEs is not confirmed here. Pair the scan with dependency verification and the official React advisory before deciding whether your application is affected.