chore(deps): update react and next (CVE-2025-55182)

[bottarocarlo]

This pull request updates the advisory data for GHSA-fv66-9v8q-g76r.json by adding version range information for the affected next and react npm packages. These additions clarify which versions are impacted and when fixes were introduced, improving the accuracy of vulnerability tracking for downstream consumers.

[Copilot]

Pull request overview

This PR enhances the GitHub Security Advisory (GHSA-fv66-9v8q-g76r) for CVE-2025-55182 by adding version range information for the next and react npm packages. The advisory tracks a critical RCE vulnerability in React Server Components that affects multiple React packages and Next.js framework versions.

Key Changes:

• Added 7 version range entries for the next package covering canary and stable releases from 14.3.0-canary.77 through 16.0.7
• Added 3 version range entries for the react package (19.0.0, 19.1.0, and 19.2.0 series) with corresponding fixes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Serubin]

@bottarocarlo perhaps the existing GHSA for Next should be updated to include the CVE alias - advisories/github-reviewed/2025/12/GHSA-9qr9-h5gf-34mp/GHSA-9qr9-h5gf-34mp.json?

[bottarocarlo]

@Serubin this was my initial though #6524 but as per comment #6496 (comment) the cveid cannot be added there

[Serubin]

@bottarocarlo makes sense. You may need to clean up the style issues from Copilot before this gets merged. I would also recommend removing/rejecting the old GHSA as a part of this PR or an immediate follow-up.

[shelbyc]

@bottarocarlo I have a question about the scanning tool you're using and other advisories about CVE-2025-55182, such as GHSA-fmh4-wr37-44fp. The global advisory for GHSA-fmh4-wr37-44fp doesn't have CVE-2025-55182 attached because CVE-2025-55182 is already attached to GHSA-fv66-9v8q-g76r, but the repository advisory for GHSA-fmh4-wr37-44fp lists CVE-2025-55182 as the CVE ID. Would your tool pick up the information from GHSA-9qr9-h5gf-34mp if the repository advisory listed CVE-2025-55182 as the CVE ID?

[Serubin]

@shelbyc, the issue is that GHSA-9qr9-h5gf-34mp doesn't have the correct CVE attached. Scanners may pick up GHSA-9qr9-h5gf-34mp and alert on it, but we cannot determine the canonical ID (CVE) associated with GHSA-9qr9-h5gf-34mp.

Either the next versions affected by CVE-2025-55182 should be added to GHSA-fv66-9v8q-g76r, or CVE-2025-55182 needs to be associated as an alias on GHSA-9qr9-h5gf-34mp (but I understand there is a technical limitation here).

[shelbyc]

@bottarocarlo @Serubin our team reviewed CVE-2025-55182 and discussed what we could do to maximize alert reach. The short answer is that we can't add CVE-2025-55182 to more than one global advisory, and adding more products to GHSA-fv66-9v8q-g76r will result in duplicate alerts for end users. We do not want to degrade the quality of data in the ADB to accommodate limitations of other vendors' scanners.

What we can do is add more information to description and references of the advisory to make the connection clearer.

For GHSA-fv66-9v8q-g76r/CVE-2025-55182/React:

• We will add GHSA-9qr9-h5gf-34mp and GHSA-fmh4-wr37-44fp as references.
• We will add the following line to the description: "This vulnerability is known to have downstream impact (see GHSA-9qr9-h5gf-34mp) and has actively been exploited."

[MikeMoore63]

So just to be clear as CVE-2025-55812 not being linked to package ranges causes downstream more issues than duplicates.

Certainly in my use cases. I think you need to merge and withdraw one of the issues to get to a better state I have raised yet another pr trying to resolve this here #6553 I have seen many attempts by people trying to get the data and this alias linked correctly. The data is far more important for downstream processing than the text. As a human or maybe with AI I can work out the linkage. But this should be solvable with data. Given NVD withdrew the incorrect next CVE. Following their lead would seem to be the approach that would align with what the industry is working on and possibly a good approach.

So merge as per my pr ttps://github.com//pull/6553 and then withdraw GHSA-9qr9-h5gf-34mp by setting the withdrawn field. That way you end up with one mapping ranges correct and unique match.

Again just some context I can provide. The NVD is basis for Fedramp procedures and process and not having the aliases correct and linked to package ranges breaks the procedures and processes supporting FedRamp. While adding comments is easy the real world impact on people and processes and manual effort increases dramatically when the data is incorrect especially the bigger the company tha leverage the data.

From osv spec https://ossf.github.io/osv-schema/

withdrawn field

{
"withdrawn": string
}

The withdrawn field gives the time the entry should be considered to have been withdrawn, as an RFC3339-formatted timestamp in UTC (ending in “Z”). If the field is missing, then the entry has not been withdrawn. Any rationale for why the vulnerability has been withdrawn should go into the summary text.

The withdrawal reason would be clearer for GHSA-9qr9-h5gf-34mp is the old alias of withdrawn CVE had been kept. Anyone downstream should be handling withdrawn correctly.

In context the number of attempts so far to resolve this issue shows as is this is clearly causing issues and why the suggestion sadly from @shelbyc is really will remain unacceptable for such a critical CVE.