[GHSA-925w-6v3x-g4j4] Source Code Exposure Vulnerability in React Server Components

[MikeMoore63]

Updates

• Affected products

Comments
The packages match what is in GHSA-9qr9-h5gf-34mp advisory GHSA-9qr9-h5gf-34mp lacks alias to CVE-2025-55812 but suggestions for improvements lack the ability to suggest additional aliases. Given this CVE has correct aliases the alternate is adding packages here. This also then aligns with NVD data base for https://nvd.nist.gov/vuln/detail/CVE-2025-55182 I don't care if this is accepted or GHSA-9qr9-h5gf-34mp has the alias added but the github advisory database is incomplete and inacurate either way in terms of alias mapping or package coverage. Would appreciate this had some attention I have been tracking pr's since last week trying to resolve this and the data quality has dropped in my eyes as you lost the duplicate CVE on GHSA-9qr9-h5gf-34mp and did not add in the correct alias. I am sure impacting other people as well.

[github]

Hi there @zpao! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory

[MikeMoore63]

See comments on #6528 which is yet another attempt like mine to get data in a better state.

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.

As is the next package ranges have zero NVD linkage so is not appearing in my companies fedramp procedures and processes. Meaning we ar edealing with this CVE using manual procedures and processes and I suspect this is true beyond my use. All becuase of how Fedramp works and is oriented around NVD data.

So merge as per this pr ttps://github.com/#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 (see section 3)

"National Vulnerability Database (NVD): For any vulnerability listed in the latest version of the
National Institute of Standards and Technology (NIST) NVD, the Common Vulnerabilities and
Exposures (CVE) reference number must be included with the machine-readable findings data
for that vulnerability."

so not having identifier 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.