github
[GHSA-925w-6v3x-g4j4] Source Code Exposure Vulnerability in React Server Components
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.
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
See comments on https://github.com/github/advisory-database/pull/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 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.
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/https://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 (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 https://github.com/advisories/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.
Thanks for putting this together @MikeMoore63 - hopefully the GHSA team will make the necessary change to correctly represent how MITRE and NVD are classifying the vulnerability.
Thank you for your contribution and for raising this @MikeMoore63. I understand the confusion around how this CVE relates to both React and Next.js advisories, and since this has repeatedly come into question, I want to take the opportunity in this PR to clarify our current handling and the challenges we face.
How We've Handled CVE-2025-55182
CVE-2025-55182 has been assigned to GHSA-fv66-9v8q-g76r, which is the React advisory. This is the correct placement because the vulnerability exists in React's implementation of the flight protocol—this is where the vulnerable code actually lives.
We have cross-referenced the advisories to help users understand the relationship:
- GHSA-fv66-9v8q-g76r (React advisory) contains CVE-2025-55182
- GHSA-9qr9-h5gf-34mp (Next.js advisory) references the upstream React vulnerability in both the description and references and explains how Next.js users are affected
We have additionally reached out to the Next.js maintainers to update the CVE listed on their associated repository GHSA, and https://github.com/vercel/next.js/security/advisories/GHSA-9qr9-h5gf-34mp now includes CVE-2025-55182.
What the Community is Requesting
Based on the PRs we've received so far, the community is asking for:
- CVE-2025-55182 to be explicitly listed on the global Next.js advisory (GHSA-9qr9-h5gf-34mp)
- Clear indication that Next.js users need to update due to this CVE
- Assurance that Dependabot will alert Next.js users about CVE-2025-55182
What We Cannot Accommodate
The root issue is a fundamental tension between CVE counting rules and the reality of package dependency. Per CVE rules, if using the library, protocol, or standard requires the product to be vulnerable, then only a single CVE ID should be assigned.
CVE-2025-55182 represents a vulnerability in React's flight protocol implementation, and Next.js is vulnerable because it depends on React. Per CVE counting rules, this should only receive one CVE ID assigned to the package where the vulnerability actually exists (React), which is why we've rejected CVE-2025-66478 as a duplicate of CVE-2025-55182.
We cannot assign CVE-2025-55182 to multiple global advisories. The CVE ID is a unique identifier for a given vulnerability in our architecture, and therefore can only reference a single global advisory.
You've correctly identified the fundamental issue regarding the existing CVE record, and inability to create duplicate IDs. A CVE ID is intended to be a unique identifier for a single vulnerability. The CVE ecosystem wasn't designed to easily handle transitive dependency vulnerabilities where end users of a transitive package want to know they're affected due to an upstream vulnerability.
Please note: CVE records have limitations in representing transitive dependency relationships, and the canonical CVE record for CVE-2025-55182 is not assigned, owned, or maintained by GitHub.
How Our Advisory Structure DOES Alert Next.js Users
While we cannot include CVE-2025-55182 on GHSA-9qr9-h5gf-34mp, Next.js users ARE being alerted:
For Next.js Developers
- GHSA-9qr9-h5gf-34mp specifically addresses the Next.js impact
- Dependabot alerts WILL trigger for vulnerable Next.js versions based on this advisory
- The advisory cross-references the React vulnerability (GHSA-fv66-9v8q-g76r) and explains the dependency relationship
- A clear, Next.js specific upgrade path is provided
For React Developers
- GHSA-fv66-9v8q-g76r covers the React vulnerability with CVE-2025-55182
- Dependabot alerts trigger for direct React consumers
- React-specific version information is accurate
For the Ecosystem
- Both advisories cross-reference each other in description and references
- The full vulnerability context is preserved
- React and Next developers are actively receiving Dependabot alerts
Bottom Line
Next.js users WILL be alerted through GHSA-9qr9-h5gf-34mp, which accurately describes how Next.js is impacted by the upstream React vulnerability. The advisory structure correctly represents the vulnerability according to both:
- CVE Program rules (one CVE for the root cause in React)
- Our database architecture (one advisory per CVE record to enable Dependabot alerts)
The community's concern is understandable - it's not obvious from the base CVE record alone that Next.js users are affected. However, the solution for the Advisory Database is already in place through our advisory structure. GHSA-9qr9-h5gf-34mp ensures Next.js developers will receive alerts and understand they need to update, even though CVE-2025-55182 itself is only formally assigned to the React advisory where the vulnerability actually exists.
We appreciate the community's vigilance in ensuring our data is accurate. The cross-referencing between GHSA-fv66-9v8q-g76r and GHSA-9qr9-h5gf-34mp is the appropriate way to represent this transitive vulnerability relationship within the constraints of both the CVE Program and our advisory database architecture.
If you have specific concerns about the advisory content, version ranges, or how we're communicating the relationship between these advisories, please let us know so we can continue improving how we serve both maintainers and users.
