Version 4.2.0 of the CVE Program's CNA Operational Rules was approved on 20 August 2026 and carries a version date of 25 August 2026. I pulled the rules data and the partner list from the CVE Program's cve-website repository on 18 October 2026. The list holds 557 CVE Numbering Authorities (CNAs), and the rules run to a few dozen pages that most small vendors never read.
You only need to answer one question: which of the three routes fits your company. This post is about choosing a route and about what the record must contain.
What's affected
Companies and maintainers who have a confirmed vulnerability and want an identifier customers and scanners can match. The three routes:
| Route | Fits you if | What the sources say |
|---|---|---|
| GitHub as CNA | Your code lives on GitHub and you can open a repository security advisory | GitHub's CNA scope covers "CVEs requested by code owners using the GitHub Security Advisories feature". GitHub says it usually reviews requests within 72 hours and cannot assign if another CNA covers your project |
| A CNA with your scope | A vendor, hosting platform or ecosystem CNA already covers your product | Example: Wordfence, Patchstack and WPScan list WordPress plugins and themes in their scopes |
| CNA of Last Resort | Nobody else covers you | MITRE's scope is "All vulnerabilities, and Open Source software product vulnerabilities, not already covered by a CNA" |
A fourth route is becoming a CNA yourself. The CVE FAQ gives three basic requirements: a public vulnerability disclosure policy, a public source for new vulnerability disclosures, and agreement to the CVE Terms of Use. There is no fee and no contract. It makes sense when you will have a steady stream of CVEs, not for one bug a year.
How to check if you're exposed
Search the partner list for a CNA that already covers your product. If one does, the rules say it "MUST be contacted and given the first opportunity to assign" (4.2.1.1).
import json, urllib.request
u = "https://raw.githubusercontent.com/CVEProject/cve-website/dev/src/assets/data/CNAsList.json"
cnas = json.load(urllib.request.urlopen(u))
needle = "wordpress" # your ecosystem, host or product name
for c in cnas:
if needle in c["scope"].lower():
print(c["shortName"], "|", c["organizationName"])
Run it with your ecosystem and your code host in place of the needle. If the output is empty, you are in last resort territory.
What to do now
- Pick the route from the table. For most small teams on GitHub it is the advisory route: create a draft repository security advisory, add affected versions, then choose Request CVE. GitHub's docs say any admin of the advisory can do this.
- Ship the fix and the advisory together. Rule 5.3.1 says a public reference must exist before or with the CVE Record, and the record "MUST NOT be the first Public Disclosure" of the flaw.
- Write the record content. Section 5.1 of the rules is the minimum:
- at least one affected product, with supplier, product name and versions, marked affected or unknown
- the type or cause of the flaw, ideally as a CWE
- a prose description in English
- at least one public reference that is not the CVE Record itself
- fixed versions, which the rules say it SHOULD list
- Keep credit out of the description. Rule 5.2.4 says the description "MUST NOT credit people, organizations, or tools". Use the optional credits element or your own advisory.
- If a CNA with scope ignores you and the flaw is already public, the rules (4.2.1.2) have a Root direct a CNA of Last Resort to assign within 72 hours of learning of the refusal.
A skeleton of what the CNA container carries, in CVE Record Format 5.x. The schema requires providerMetadata, descriptions, affected and references:
{
"affected": [{
"vendor": "Example Co",
"product": "Example SDK",
"versions": [{ "version": "0", "status": "affected",
"lessThan": "2.4.1", "versionType": "semver" }]
}],
"problemTypes": [{ "descriptions": [{
"lang": "en", "type": "CWE", "cweId": "CWE-79",
"description": "CWE-79 Improper Neutralization of Input During Web Page Generation" }]}],
"descriptions": [{ "lang": "en",
"value": "Example SDK before 2.4.1 does not escape user input in the report viewer." }],
"references": [{ "url": "https://example.com/security/advisories/2026-01" }]
}
How to avoid this trap
- Do not email MITRE first. The first refusal rule exists to prevent duplicate IDs.
- Do not request an ID before you have a disclosure plan. The assignment expects a public disclosure.
- Name one owner for CVE requests so the same flaw is not requested through two channels.
- Write a one line "CVE policy" on your security page: which CNA you use and how long you wait.
Why it matters
A fix without an identifier is invisible to scanners. Customers see nothing to match against their inventory, and your advisory has to be read by a human to be useful. The identifier is what lets a customer's tooling flag the right component on the right version.
The program is also busy. The metrics file in the same repository shows 20,709 published CVE records in the second quarter of 2026. A well-formed record from a small vendor, with fixed versions and a CWE, stands out in that volume.
Try it yourself
Take one past vulnerability from your changelog. Run the script, pick the route, and write the four required record fields in a text file. Then see how a vulnerability management view turns a CVE record into a prioritized fix.
Click through it at your own pace, or open it full screen.
Quick check
Your project is on GitHub but a hosting vendor's CNA already lists your product in its scope. Can GitHub assign the CVE?
No. GitHub's docs say it cannot assign CVEs to a project covered by another CNA. Contact the CNA with scope first.
Can the CVE description thank the researcher?
No. Rule 5.2.4 forbids crediting people, organizations or tools in the description. Use the credits element or your advisory.
What are the CNA requirements in the CVE FAQ?
A public disclosure policy, a public source for new disclosures, and agreement to the CVE Terms of Use. There is no fee.
