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.

[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 https://github.com/github/advisory-database/pull/6524 but as per comment https://github.com/github/advisory-database/pull/6496#issuecomment-3629103557 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 https://github.com/advisories/GHSA-9qr9-h5gf-34mp doesn't have the correct CVE attached. Scanners may pick up https://github.com/advisories/GHSA-9qr9-h5gf-34mp and alert on it, but we cannot determine the canonical ID (CVE) associated with https://github.com/advisories/GHSA-9qr9-h5gf-34mp.

Either the next versions affected by CVE-2025-55182 should be added to https://github.com/advisories/GHSA-fv66-9v8q-g76r, or CVE-2025-55182 needs to be associated as an alias on https://github.com/advisories/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 https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp and https://github.com/vitejs/vite-plugin-react/security/advisories/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 https://github.com/github/advisory-database/pull/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/github/advisory-database/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.

[Serubin]

I strongly agree with @MikeMoore63. Not including the correct CVEs for GHSA-fv66-9v8q-g76r is an incorrect representation of the CVE data.

[taladrane]

Please see our response in this thread in regard to CVE-2025-55182 🙇‍♀️