How to Get a CVE ID: The CNA Process for Small Vendors and Maintainers

Version 4.2.0 of the CVE Program's CNA Operational Rules carries an approval date of 20 August 2026 and a version date of 25 August 2026. It is the document that decides who may assign a CVE ID, in what order, and what happens when someone says no. If your product has a security hole and a researcher asks "can I get a CVE?", this is the rulebook behind the answer.

The short version: you do not need to be a CVE Numbering Authority (CNA) to get an ID. You need to know which CNA has the right to assign first.

What's affected

Vendors, maintainers and researchers who need a CVE ID for a vulnerability. I counted the CNA partner list that powers cve.org (CNAsList.json in the CVEProject cve-website repository, fetched 18 October 2026):

The same program's metrics file shows 15,163 published CVE records in the first quarter of 2026 and 20,709 in the second. The system is busy, and most assignments happen through one of these 557 organizations, not through a central desk.

How to check if you're exposed

Use this to reproduce the counts and to find the CNA for your project.

import json, urllib.request
url = "https://raw.githubusercontent.com/CVEProject/cve-website/dev/src/assets/data/CNAsList.json"
cnas = json.load(urllib.request.urlopen(url))
print(len(cnas))
print(sum(1 for c in cnas if any(p.get("url") for p in c.get("disclosurePolicy", []))))
print(sum(1 for c in cnas if "Open Source" in c["CNA"].get("type", [])))
needle = "django"  # a word from your product, host or company name
for c in cnas:
    if needle in c["scope"].lower() or needle in c["organizationName"].lower():
        print(c["shortName"], c["scope"][:120])

Then answer three questions. Is your own company on the list? Does a CNA's scope cover your product, such as your hosting platform or a vendor whose component you wrap? If neither, MITRE's scope is "All vulnerabilities, and Open Source software product vulnerabilities, not already covered by a CNA listed on this website."

What to do now

1. Identify the CNA with the most appropriate scope. The rules say it "MUST be contacted and given the first opportunity to assign" (4.2.1.1), and it is often the supplier of the product. If you build the product and are not a CNA, the next best is a CNA whose scope includes your code host. GitHub's CNA entry covers CVEs requested through GitHub Security Advisories, and GitHub says it usually reviews a request within 72 hours.
2. Fix first, or at least have a fix in hand. A CVE ID can be reserved before disclosure, but the rules require that a vulnerability with an assigned ID be publicly disclosed by the CNA or another party, or the ID must be rejected (4.2.4).
3. Prepare the record text: affected product and versions, vulnerability type, impact, fixed version, and a reference to your advisory. Descriptions in CVE records are typically written by the CNA or the requester.
4. If the CNA with scope does not respond within 72 hours, or declines, and the vulnerability is already public, the rules direct a Root to make a determination and have a CNA of Last Resort assign within 72 hours of learning of the first refusal (4.2.1.2).
5. After assignment, publish. CNAs must publish the CVE record within 72 hours of publicly disclosing an ID they assigned (4.5.1.4).
6. If you disagree with a CVE someone else obtained for your product, follow the dispute process in section 4.6. A DISPUTED tag has no fixed duration and means the program takes no side.

How to avoid this trap

1. Do not email MITRE first. The rules give the CNA with scope the right of first refusal, and a skipped step creates duplicate IDs. The CNA Rules ask CNAs to work to prevent duplicates.
2. Do not request an ID for something you will not disclose. An undisclosed assignment can be rejected.
3. Write your own CVE policy page now. CNAs must publish how they assign IDs and a URL to their disclosure policy (3.2.6.1 and 3.2.6.2). Even if you are not a CNA, a paragraph saying which CNA you use removes confusion.
4. Keep one person responsible for CVE requests so the same issue is not requested twice through different channels.
5. Do not tie a CVE to the type of technology. Rule 4.2.3 says CNAs must not consider technology type, such as cloud or AI, as the sole basis for assignment.

Why it matters

CVE is how scanners, customers and regulators identify your vulnerability. If you fix quietly and the world has no ID, customers cannot match their inventory to your fix. If you request an ID in a hurry from the wrong place, you get duplicates and disputes.

It also ties back to disclosure policy. The CNA rules list common elements of a vulnerability disclosure policy: attempts to notify suppliers, report quality, intake process, bug bounty details, response expectations, embargo and coordinated public disclosure. A small vendor that writes these down once saves every future reporter a round of questions.

Try it yourself

Pick one open vulnerability, real or hypothetical, in a product you maintain. Run the script above, name the CNA with scope, write the record description in three sentences, and decide whether a fix could ship within the response window your VDP promises.

Quick check

Sources

• CVE Program CNA Rules data, version 4.2.0 (cnaRules.json)
• CNA partner list data (CNAsList.json), fetched 18 October 2026
• CVE Program FAQs data (faqs.json)
• CVE Program metrics data (metrics.json)
• GitHub Docs: About repository security advisories