Allow a CVE to be linked to multiple GHSAs (or expose CVE relationships in structured data) so reviewed advisories don't lose their CVE #10224

Summary

A CVE can currently be attached to only one GHSA in the database backend. When the same vulnerability exists as more than one GHSA, only one of them can carry the CVE alias. The others end up with no CVE alias, and the relationship exists only as a reference URL or in free text, or not at all.

This makes it hard for consumers to join GHSA data with CVE-keyed sources such as CISA KEV, EPSS, NVD, and PoC/exploit databases.

Example 1: downstream advisory (Next.js)

• CVE-2025-55182 is attached to GHSA-fv66-9v8q-g76r (React).
• GHSA-9qr9-h5gf-34mp (Next.js) originally had CVE-2025-66478, which was rejected in accordance with CVE CNA rule 4.1.12. That rule says a downstream product advisory SHOULD reference the CVE ID of the vulnerable library.
• However, CVE-2025-55182 cannot be added as an alias to GHSA-9qr9-h5gf-34mp because it is already attached to GHSA-fv66-9v8q-g76r. The NVD URL was added to references instead.
• NVD lists Next.js CPEs under CVE-2025-55182, so NVD and GHSA now disagree on which products are associated with that CVE in structured form.

Discussion: #6496, #6521

Example 2: reviewed and unreviewed duplicates (renovate)

• GHSA-v7x3-7hw7-pcjg (renovate, npm, reviewed) has no CVE alias.
• CVE-2019-25766 was later assigned for this vulnerability, and the CVE record references GHSA-v7x3-7hw7-pcjg.
• CVE-2019-25766 is attached to a separate unreviewed advisory, GHSA-3r27-cgcx-x497, which has no affected packages.
• As a result, a CVE lookup returns only the unreviewed advisory without package or version information, while the reviewed advisory that consumers match against their dependencies cannot be found by CVE.

Scale

I cross-checked the 3,611 non-withdrawn reviewed advisories that have no CVE in aliases against the CVE List (CVEProject/cvelistV5, records that reference the GHSA ID, excluding rejected CVEs) and against Go vulndb, PyPA and RustSec aliases. Data as of 2026-10-08.

At least 768 reviewed advisories (about 21%) have an existing CVE that is not reflected in their aliases.

The remaining 2,843 could not be matched with this method. That does not mean no CVE exists, since a CVE record does not always reference the GHSA, and downstream advisories that should use an upstream CVE are not detected. The actual number is likely higher.

Impact

• Tools that look up GHSA by CVE ID (or CVE by GHSA ID) either find nothing or find an advisory without package and version information.
• Reviewed advisories cannot be enriched with CVE-keyed data such as KEV status, EPSS score, or public PoC/exploit availability, so their risk can be underestimated during triage.
• Consumers have to parse references URLs or free text to recover the CVE, which is fragile and not part of any documented contract, and does not work at all when the CVE is not mentioned.
• The CNA rule 4.1.12 guidance ("reference the library's CVE") cannot be expressed in structured data on the downstream GHSA.

Possible solutions

1. Allow 1 CVE : N GHSA aliasing. Let multiple GHSAs list the same CVE in aliases (in the OSV export as well).
2. Attach later-assigned CVEs to the existing reviewed GHSA. When a CVE is published for a vulnerability that already has a reviewed GHSA, add the CVE to that GHSA instead of creating a new unreviewed advisory, or merge the unreviewed one into it.
3. Consolidate downstream advisories into a single GHSA. When a downstream advisory exists only because of a vulnerable dependency, merge its affected packages and version ranges into the upstream GHSA, since a GHSA can already list multiple affected packages.
4. Add a structured relationship field. If changing aliases semantics is not acceptable, expose the related CVE/GHSA in a dedicated structured field (e.g. OSV related / upstream) rather than only in references.

Option 2 would address the largest group in the data above, and option 1 or 4 would cover the downstream case with the least disruption for existing consumers.