How to Get a CVE: Finding the Right CNA and Filing a Request

CVE IDs are not issued by one desk. The CVE Program delegates assignment to CVE Numbering Authorities (CNAs), each with a defined scope: usually its own products, sometimes a platform or a whole ecosystem. Vendors such as Microsoft, Google, and Red Hat are CNAs for their own software. The Linux kernel project became its own CNA in 2024. GitHub is a CNA for vulnerabilities in projects hosted on it. Coordinators such as CERT/CC are CNAs that can handle cases where a vendor is unresponsive.

CNAs sit under Roots and Top-Level Roots. MITRE operates a Top-Level Root and, within it, the CNA of Last Resort (CNA-LR), which assigns IDs when no other CNA covers the product. CISA operates a separate Top-Level Root, and MITRE's CNA-LR says it does not handle matters within another Top-Level Root's scope.

The practical consequence: the first job is not filling in a form. It is finding the CNA whose scope includes the affected product.

A CVE ID names one vulnerability in one product, so the CNA will ask a few questions before assigning.

Is it a vulnerability?

Is it independently fixable?

Is it public, or will it be?

Search the CNA partner list on cve.org by organisation name and read each candidate's scope statement. Work in this order:

1. The vendor itself. If the vendor is a CNA and the product is in scope, report to the vendor's security contact. They assign the ID and publish the record on the coordinated disclosure date.
2. A platform or ecosystem CNA. Open source on GitHub can get an ID through GitHub. Some language ecosystems and distributions run CNAs for their packages.
3. A coordinator. If the vendor is not a CNA and will not engage, a coordinator such as CERT/CC can take the case, handle vendor contact, and assign.
4. The CNA of Last Resort. Only when nobody else covers it.

Going to the CNA-LR when the vendor is a CNA with the product in scope usually gets you redirected, which costs days.

Maintainers can create a draft repository security advisory, fill in the affected package and version ranges, and click Request CVE. GitHub, acting as a CNA, reviews the request and assigns an ID, which stays private until the advisory is published. Enabling private vulnerability reporting lets outside researchers submit findings straight into that draft workflow, which keeps the embargo inside one system instead of an email thread.

MITRE refreshed its CNA-LR web form in May 2026 as part of a wider change to CVE Program contact methods, and says the legacy form at cveform-legacy.mitre.org remains available if the new one gives trouble. The current form is linked from MITRE's CNA-LR page.

Set expectations accordingly. MITRE says the CNA-LR prioritises vulnerabilities that can be identified cost-effectively and whose inclusion best serves the public interest, and that requesters are not entitled to extra resources. It does not publish a turnaround time. Before publishing, it checks for reasonable evidence that the vulnerability exists and that its essential details are public. Ideally the supplier submits; a discoverer can submit when the supplier will not, provided the claim is unique and valid.

Whichever CNA you use, the record will need the same facts. Requests that arrive complete get assigned faster.

• Vendor and product, exactly as the vendor names them.
• Affected versions and the fixed version, as ranges, not "latest".
• Weakness type, ideally a CWE identifier.
• Impact and attack vector: remote or local, authenticated or not, what the attacker gains.
• A short description in the usual CVE style: component, flaw, consequence.
• References: advisory URL, fix commit, release notes, or your write-up once public.
• Credit: how you want to be named.

Keep exploit detail out of the description. The record exists to identify the flaw, not to teach it. If you include a CVSS score, expect it to be treated as one input; NVD and vendors may score separately.

During coordinated disclosure, the CNA reserves the ID and the record stays unpublished. Agree a disclosure date with the vendor and CNA, and make sure the advisory or release notes exist on that date so the record has a reference. If someone discloses early, MITRE says the CNA-LR may publish ahead of the planned date where that helps defenders. If you disagree with a published record, the CVE Record Dispute Policy is the route, not a second request.

Vendors that handle a steady flow of reports often find it simpler to become a CNA. You decide what is in scope, assign IDs on your own timeline, and publish records alongside your advisories. The obligations are real: a public vulnerability disclosure policy, a public place where advisories are published, and following the CNA Operational Rules. The trade-off is control in exchange for process. Without it, researchers request IDs about your product from someone else, on their timeline.

• Filing with the CNA-LR when the vendor is a CNA for the product.
• One request covering several independently fixable bugs.
• Version ranges like "all versions" with no fixed release.
• No public reference planned for the disclosure date.
• Treating the CVE ID as the severity rating. Severity, exploitation status, and enrichment come from elsewhere.