The Trouble with CVE Misconceptions

A CVE is simply a unique tracking identifier assigned to a security vulnerability. Yet several widespread misconceptions paint it as something more ominous: that it signals a critical flaw, that it tarnishes a project’s reputation, or that low-severity issues don’t warrant one. Some even view a CVE as a badge of severity awarded by an official body like NIST, or a trophy for the researcher who found the bug. Others assume the process of obtaining one is painfully slow.

These beliefs often make maintainers hesitant to request a CVE for less severe vulnerabilities. The better approach, as we see it at GitHub Security Lab, is to favor transparency: always request a CVE and publish an advisory, regardless of severity. Use the advisory to lay out the technical details so users can make informed decisions about whether the issue truly demands immediate action.

How CVEs Are Actually Assigned

CVEs are issued by a CVE Numbering Authority (CNA). Large companies like Google, Microsoft, and Apple typically act as CNAs for their own products, but their scope rarely extends to other projects. GitHub, however, serves as a CNA for any open source project hosted on GitHub via the GHSA system. Other CNAs with broader scopes, such as MITRE and CERT/CC, may also assign CVEs to open source projects—even those you didn’t request yourself by creating a GHSA. This is especially likely if a security researcher contacts you about a vulnerability and you don’t respond. In that scenario, there’s a higher risk that inaccurate information about the vulnerability will be published.

The GitHub Advisory Database aggregates most maintainer-created GHSAs along with advisories imported from other CNAs. Our curation team reviews these imported advisories and enriches them with details like mapping the affected product to a specific package. When we import from other CNAs, we generally rely on their provided description and severity rating. Maintainers who want accurate data in the GitHub Advisory Database are therefore better off creating or collaborating on their own advisory first.

When and How to Contest a CVE

If a CVE is assigned to your project incorrectly, contest it with the CNA that actually assigned it. GitHub can only assist with CVEs assigned by GitHub through the GitHub Security Advisory process. Valid reasons to contest include:

  • The assignment violates CVE rules—potentially resulting in a disputed CVE.
  • It isn’t a real vulnerability—leading to a rejected CVE.
  • Information is insufficient or incorrect—possibly an updated CVE.
  • Multiple CVE IDs point to the same vulnerability—resulting in a merged CVE.

You cannot contest a CVE assignment simply because you disagree with its severity. You can discuss the severity with the assigning CNA and request changes based on evidence you provide, but if the vulnerability is valid, a CVE will still exist for it.

What GitHub Does When You Request a CVE

When you click the button in a GitHub Security Advisory to request a CVE, GitHub Security Lab handles it—typically within 72 hours. This is an editorial service: we assign the number only after verifying your request complies with CVE Program rules. We write a condensed summary suitable for sharing with external databases like NIST’s National Vulnerability Database (NVD). Following a style guide, we keep that summary concise but information-rich, and we attempt to link to related pull requests, issues, and fix commits. We also assign a severity score based on what you’ve provided. The CVE number is shared with you while the advisory is still in draft, but nothing becomes public until you publish the GHSA.

Writing a Useful Advisory

More information is almost always better. Detailed descriptions help us craft an accurate CVE summary, and they let your users evaluate the real impact for their own systems. Consider including:

  • Details of the attack vector: What triggers the vulnerability? Does the user have to click a link or install a non-standard plugin? Does the attacker need special privileges?
  • Potential impact: crash the app, steal passwords, or something else.
  • Affected and safe version numbers.
  • Links to the fix commit, pull request, or related issue.
  • Your own assessment of severity—is it purely hypothetical or a pressing threat?

Describing the attack scenario is particularly valuable. Explain what the victim would need to be doing and what the attacker must do to succeed. Is the software vulnerable by default, or does it require non-standard user action? Can the flaw be exploited without interaction, or must the attacker trick a user first?

Publishing a proof-of-concept (PoC) is a judgment call. If the bug is only theoretical and no exploit is confirmed, definitely state that in the advisory—it lowers the perceived risk. A PoC can help users understand the issue, self-test for exposure, and check for prior breaches. On the other hand, it could be used to attack unpatched users. Think carefully about the trade-offs.

Transparency Beats Silence

When in doubt, publish a security advisory rather than staying quiet. Demonstrating that you take vulnerabilities seriously builds trust in your project. A CVE is not a mark of shame—it’s just a tracking number with no inherent severity attached. Using the GitHub Security Advisory system to publish an advisory and request a CVE ensures the public record is accurate, so your users can rationally assess the risk and decide what to do next.