The CVE Program Explained: How to Get a CVE for Your Finding

April 7, 2026

A CVE ID is a short string like CVE-2024-3094 that uniquely identifies a vulnerability across every database, scanner, and advisory on the internet. When you report a bug through a bounty program, the platform or vendor usually handles CVE assignment behind the scenes. But if you do independent research, disclose directly to a vendor, or find something in an open-source project, you may need to request one yourself. The process is not hard once you understand who is involved and what they need from you.

What CVE actually is

The Common Vulnerabilities and Exposures program is a catalog, not a scoring system. It does not tell you how severe a bug is. That is what CVSS does (see our CVSS scoring guide). A CVE entry contains an ID, a short description, affected products, and references to advisories or patches. That is it.

The value is in the identifier itself. Once a vulnerability has a CVE ID, every downstream tool can reference the same issue unambiguously. Nessus, Qualys, the NVD, vendor advisories, GitHub security alerts - they all key off CVE IDs. Without one, your finding exists only in whatever report you wrote and whatever advisory the vendor published, if they published one at all.

I think of CVE as infrastructure. It is boring and essential, like DNS. You do not think about it until it breaks.

The 2025 funding crisis

It nearly broke in April 2025.

MITRE has operated the CVE program under contract with CISA (and before that, DHS directly) since 1999. On April 15, 2025, MITRE’s board sent a letter to the CVE community warning that their contract was about to expire the next day with no renewal in place. This was not a drill. The program that underpins vulnerability management worldwide came within hours of losing its funding.

CISA issued an 11-month emergency extension on April 16. That kept the lights on through March 2026, but the damage to confidence was real. Within days of the near-miss, a group of CVE board members announced the CVE Foundation, a non-profit intended to serve as a long-term backstop independent of any single government contract.

The European Union moved even faster. The EU had already been building EUVD (the European Vulnerability Database) under the NIS2 directive. The April 2025 scare accelerated that work. ENISA now operates a parallel vulnerability cataloging system that does not depend on US federal funding decisions.

As of early 2026, the CVE program’s funding is on firmer ground. Congress included CVE funding “above the line” in the January 2026 appropriations bill, meaning it is no longer subject to the same contract renewal uncertainty. The CVE Foundation exists but has not needed to take over operations. The practical effect for researchers today: the system works, CVE IDs are being assigned normally, and there is now a backup plan if funding gets shaky again.

Why does this matter to you? Because if you had submitted a CVE request in April 2025, it would have gone into a queue that nearly stopped processing. The crisis reinforced something the security community already knew - the CVE program is a single point of failure with surprisingly fragile funding. Keep this in mind when you plan disclosure timelines around CVE assignment.

CNAs and how the system is organized

CVE IDs are not all assigned by one central authority. The program uses a federated model built around CVE Numbering Authorities, or CNAs.

A CNA is any organization authorized to assign CVE IDs for vulnerabilities in their own products or in their defined scope. As of 2026, there are over 400 CNAs. Some examples:

Product vendors - Microsoft, Google, Apple, Red Hat, and most major software companies are CNAs for their own products.
Open-source projects - the Linux kernel, curl, Python, and many others have their own CNA assignments.
Bug bounty platforms - HackerOne is a CNA. If you report through their platform and the program participates, they can assign the CVE directly.
Coordinating bodies - CERT/CC, JPCERT, and similar organizations act as CNAs of last resort for vulnerabilities in products where the vendor is not a CNA.
MITRE - remains the CNA of last resort when no other CNA covers the affected product.

The CNA rules define scopes and responsibilities in detail. For practical purposes, what you need to know is: figure out which CNA covers the product you found a bug in, and send your request there.

Step by step: requesting a CVE ID

1. Determine if your finding qualifies

Not every bug gets a CVE. The vulnerability must be in a codebase that shipped to users or is publicly accessible. It must be fixable independently of other bugs. Configuration mistakes in a specific deployment do not qualify. A SQL injection in a web application framework does. A misconfigured S3 bucket at one company does not.

The rule of thumb: could another user of the same software be affected? If yes, it probably qualifies.

2. Identify the right CNA

Check the CNA list on cve.org to see if the affected vendor is a CNA. If the vendor runs a bug bounty program on HackerOne, Bugcrowd, or Intigriti, the platform may handle CVE assignment as part of their process - ask.

If the vendor is not a CNA and there is no platform involved, your options are:

CERT/CC - good for cases where the vendor is unresponsive or does not have a security team. CERT/CC will coordinate disclosure and assign the CVE.
MITRE’s CVE request form - the general intake for anything not covered by another CNA. Expect longer processing times.

3. Report the vulnerability first

Do not request a CVE before you have reported the issue to the vendor or coordinator. The CVE process assumes coordinated disclosure. Submit your vulnerability report through whatever channel is appropriate, then request CVE assignment.

If you are working through a CNA vendor, just ask them to assign a CVE when you submit your report. Most large vendors do this automatically.

4. Submit your CVE request

If you are going through MITRE’s form or a coordinating CNA, you will need:

A description of the vulnerability (what it is, not how to exploit it)
Affected product name and version(s)
The vulnerability type (CWE ID if you know it, plain language if you do not)
References - your report, any vendor advisory, relevant commits
Whether the vendor has been notified and their response status

Keep the description factual and concise. “A buffer overflow in libfoo’s parse_header function allows remote code execution via a crafted HTTP request” is better than three paragraphs of background.

5. Wait

Processing times vary. Vendor CNAs often assign IDs within days. MITRE’s general queue can take weeks, sometimes longer. If your request is time-sensitive because you have a disclosure deadline approaching, mention that explicitly. CERT/CC is generally faster than MITRE’s general intake for coordinated disclosures.

You will receive a CVE ID in the format CVE-YYYY-NNNNN. The entry starts in “RESERVED” state, meaning the ID exists but details are not yet public. It moves to “PUBLISHED” once the vendor ships a fix and advisories go out.

6. Update the record

After the vulnerability is public, make sure the CVE entry has accurate information. If you notice the description is wrong or incomplete, contact the assigning CNA to request corrections. NVD enrichment (CVSS scores, CPE entries) happens separately and can lag behind by days or weeks.

When a CVE helps your career

Having CVEs attached to your name is a real signal. It shows you found vulnerabilities significant enough to be cataloged, and that you went through a responsible process to get them documented. Hiring managers at security companies notice.

CVEs are especially valuable if you are building a reputation as an independent researcher. A list of CVE IDs on your website or resume is concrete in a way that “I do bug bounties” is not. Each one is verifiable. Anyone can look up CVE-2024-XXXXX and see what you found. See our guide on building your reputation for more on this.

That said, I want to be honest about when CVEs do not matter much:

Platform-based bounty hunting - if you mostly work through HackerOne or Bugcrowd, your signal and reputation scores on those platforms matter more to other hunters and to programs. Many valid bounty findings never get CVEs and that is fine.
Low-severity findings - a reflected XSS that requires social engineering and only affects a single page is technically CVE-worthy, but nobody is going to be impressed by a long list of CVEs that are all low-severity self-XSS variants.
Quantity over quality - some researchers chase CVE counts by filing against abandoned software or disputable issues. The community notices this, and it can hurt your credibility more than help.

The sweet spot is having a handful of well-documented CVEs for genuine, impactful findings. Quality matters far more than count.

Common mistakes

Requesting a CVE before contacting the vendor. The CNA will ask if the vendor knows. If they do not, your request goes to the back of the queue while you sort out disclosure. Report first.

Skipping the CNA and going straight to MITRE. If the vendor is a CNA, MITRE will bounce your request back to them anyway. Check the CNA list first and save yourself a round trip.

Expecting a CVE for every finding. Duplicates do not get new CVE IDs. Issues already covered by an existing CVE do not get new ones. Vulnerabilities in bespoke internal applications do not qualify. Not everything needs a CVE, and that is OK.

Confusing CVE with NVD. The CVE program assigns IDs and publishes basic records. The National Vulnerability Database, run by NIST, enriches those records with CVSS scores and CPE data. If you have a complaint about a CVSS score, that is an NVD issue, not a CVE issue.

The legal angle

Requesting a CVE does not create legal risk by itself. The CVE program is a documentation system, not a law enforcement tool. But the disclosure process around it can intersect with legal questions, especially around the CFAA and international equivalents. If you are concerned about the legal side of your research, read our legal guide and follow CISA’s coordinated disclosure guidelines.

The basic principle: if you found the vulnerability through authorized testing (a bug bounty program, your own software, or legitimate security research on publicly accessible systems) and you are disclosing responsibly, requesting a CVE is a normal part of the process.

Key terms

If you are new to this, check the glossary on our learn page for definitions of CVE, CNA, CVSS, CWE, and other acronyms that show up in vulnerability management. They overlap in confusing ways until you have worked with them a few times.