Add alias CVE-2025-55182 to GHSA-9qr9-h5gf-34mp

[tockn]

Summary

This PR adds CVE-2025-55182 as an alias to this advisory.

Details

According to NVD, CVE-2025-66478 has been REJECTED as a duplicate of CVE-2025-55182.
This change adds the active CVE ID to the aliases to correctly map this vulnerability.

References

• Rejected CVE: https://nvd.nist.gov/vuln/detail/CVE-2025-66478
• Active CVE: https://nvd.nist.gov/vuln/detail/CVE-2025-55182

[Copilot]

Pull request overview

This PR updates the security advisory GHSA-9qr9-h5gf-34mp to replace a rejected CVE ID with the active one. CVE-2025-66478 was rejected by NVD as a duplicate of CVE-2025-55182, so both IDs are now listed as aliases to ensure proper vulnerability tracking.

Key changes:

• Added CVE-2025-55182 to the aliases array
• Retained CVE-2025-66478 for reference
• Updated the modification timestamp

---

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

[mswilson]

Per the OSV schema, https://ossf.github.io/osv-schema/#aliases-field

Aliases should not be used to refer to vulnerabilities in packages upstream or downstream in a software supply chain from the given OSV record’s affected package(s). For example, if a CVE describes a vulnerability in a language library, and a Linux distribution package contains that library and therefore publishes an advisory, the distribution’s OSV record must not list the CVE ID as an alias. Similarly, distributions often bundle multiple upstream vulnerabilities into a single record. To refer to these upstream vulnerabilities, upstream should be used.

[tockn]

@mswilson Thanks for the comment!
I checked the NVD record for CVE-2025-55182, and they already include next.js in the CPE configurations. Given that, wouldn't it be sufficient to just use this CVE as an alias?
https://nvd.nist.gov/vuln/detail/CVE-2025-55182

[mswilson]

As long as CVE-2025-66478 is removed as an alias, as it is causing unwanted suppression of alerts in vulnerability checking tools. Otherwise, I'd defer to the GitHub staff and OSV community for the best way to represent the relationships for vendored dependencies that are not represented in a typical way (e.g., via a package lock file).

[shelbyc]

Hi @tockn and @mswilson, I'm removing CVE-2025-66478 as a CVE ID and changing the reference link https://nvd.nist.gov/vuln/detail/CVE-2025-66478 to https://nvd.nist.gov/vuln/detail/CVE-2025-55182 to clarify that GHSA-9qr9-h5gf-34mp refers to CVE-2025-55182. However, I can't add CVE-2025-55182 as an alias to GHSA-9qr9-h5gf-34mp because CVE-2025-55182 is already attached to GHSA-fv66-9v8q-g76r in the database backend.

[advisory-database]

Hi @tockn! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!