CVE Blog

The purpose of this blog is to establish a dialogue and get your input on issues and topics important to CVE. Send feedback about this page to Right-click and copy a URL to share a post.

Please use our LinkedIn page to comment on the posts below.

CNA Rules, Version 2.0 to Take Effect on January 1st

Comment on LinkedIn | Share this post

The policies and processes managing the CVE Numbering Authorities (CNAs) Program, known as the “CNA Rules,” have been revised with significant input from the CNA community. These revised rules, CVE Numbering Authorities (CNA) Rules, Version 2.0, will go into effect on January 1, 2018.

CNA Rules, Version 2.0, which is updated from Version 1.1, includes the following clarifications and improvements:

For detailed information about the changes, please see the issue tracker and change logs.

If you have any questions or comments about the revised CNA Rules document, please contact us via our CVE Request web form by selecting “Other” from the dropdown menu, or email us directly at

We look forward to hearing from you!

- The CVE Team
  October 13, 2017

Become a CNA

Comment on LinkedIn | Share this post

CVE Numbering Authorities, or “CNAs,” are how the CVE List is built. Every CVE ID added to the list is assigned by a CNA.

The majority of CNAs are currently software vendors that assign CVE IDs to issues in their own products, but many vulnerability researchers and third-party coordinators also participate by assigning CVE IDs to issues in third-party products per their specified scopes of coverage. In all cases, by issuing CVE IDs themselves without directly involving MITRE in the details of the specific vulnerabilities, CNAs are able to ensure CVE IDs are available for inclusion in the first-time public announcement of a new vulnerability, which greatly benefits the overall cyber security community as organizations share information about the vulnerabilities and remediate them.

Actively Expanding the Number of CNAs

As of today, August 2, 2017, there are 69 total CNAs participating in the CVE program: 57 software vendors, 7 third-party coordinators, 4 vulnerability researchers, and MITRE as the Primary CNA.

And the CVE program has been actively growing the list of participating CNAs, which now includes organizations from around the world with 14 countries represented as illustrated in this map:

CNAs World Map - August 2017

NUMBER OF CNAS BY COUNTRY, AS OF AUGUST 2017: Australia: 1; Austria: 1; Canada: 3; China: 6; France: 1;
Germany: 1; Israel: 1; Japan: 3; Netherlands: 1; Russia: 1; South Korea: 1; Taiwan: 1; UK: 1; and USA: 47.

You too can become a CNA

Please consider joining us as a CNA. Participation is voluntary, and the benefits of participation include the ability to publicly disclose a vulnerability with an already assigned CVE ID, the ability to control the disclosure of vulnerability information without pre-publishing, and notification of vulnerabilities in products within a CNA's scope by researchers who request a CVE ID from them.

If your organization would like to become a CNA, please follow these three steps:

  1. Review the “CVE Numbering Authorities (CNA) Rules” document in its entirety.
  2. Closely review the Become a CNA section of this website, which is excerpted from the “CNA Rules” above.
  3. Contact us via our CVE Request web form by selecting “Other” from the dropdown menu.

We look forward to hearing from you!

- The CVE Team
  August 2, 2017

Come Meet with CVE at Black Hat 2017 on July 27 and DEF CON 25 on July 28

Comment on LinkedIn | Share this post

CVE Numbering Authority Program Lead Dan Adinolfi, and CVE Team Member Anthony Singleton, will be at Black Hat USA 2017 and DEF CON 25 next week in Las Vegas, Nevada, USA.

We invite you to join us to talk CVE at either or both events:

CVE Meet-Up, July 27

Please join us for an informal get together to talk CVE at Black Hat USA 2017. If you're interested, please meet us at 12:00 p.m. PT outside the House of Blues in the Mandalay Bay Casino.

We will determine the final location once we have everyone together. Questions or concerns:

CVE Talk, July 28

Dan and Anthony will present a talk entitled "CVE IDs and How to Get Them" at 1:10 p.m. PT in the Neopolitan Ballroom and Milano VIII at Caesars Palace at the "Wall of Sheep" at DEF CON 25.

Talk synopsis from the conference website:

"The Common Vulnerabilities and Exposures (CVE) program uniquely identifies and names publicly-disclosed vulnerabilities in software and other codebases. Whether you are a vulnerability researcher, a vendor, or a project maintainer, it has never been easier to have CVE IDs assigned to vulnerabilities you are disclosing or coordinating around. This presentation will be an opportunity to find out how to participate as well as a chance to offer your thoughts, questions, or feedback about CVE. Attendees will learn what is considered a vulnerability for CVE, how to assign CVE IDs to vulnerabilities, how to describe those vulnerabilities within CVE ID entries, how to submit those assignments, and where to get more information about CVE assignment."

Please stop by either or both events and say hello. We look forward to seeing you!

- The CVE Team
  July 20, 2017

Why is a CVE entry marked as "RESERVED" when a CVE ID is being publicly used?

Comment on LinkedIn | Share this post

A CVE Identifier (CVE ID) is marked as "RESERVED" when it has been reserved for use by a CVE Numbering Authority (CNA) or security researcher, but the details of it are not yet included in the CVE entry. Often, this is because the original requester of the CVE ID assignment has not sent an update to MITRE with the information needed to populate the CVE entry.

If you are aware of a CVE ID that is being used publicly but is not yet included in the CVE List, you can request that the CVE ID be updated through the CVE Request web form. MITRE will coordinate with the original requester to have the missing public information added to the entry.

CVE IDs are made public on countless forums, mailing lists, and other publications. CVE ID entries cannot be published without public references and other descriptive information. Searching the Internet for any public reference to a reserved CVE ID is a non-trivial problem to solve, and MITRE must rely on the community to assist with updating CVE information as it becomes public. MITRE is looking for new ways to automate and expand discovery processes, but the scale and breadth of the searchable space is growing exponentially. We hope that stakeholders will assist with this process by notifying MITRE when they see a discrepancy, and MITRE will work to quickly and accurately update outdated entries that are reported to them.

Do you have a suggestion for how MITRE could more effectively find public references scattered around the (ever-growing) Internet? You can share your ideas through the CVE Request web form or by emailing

- The CVE Team
  May 10, 2017

Now you can easily comment on CVE Blog posts using our new "CVE-CWE-CAPEC" page on LinkedIn

Comment on LinkedIn | Share this post

We have created a CVE-CWE-CAPEC page on LinkedIn as an easy way for you to comment on and share CVE Blog posts.

Current and past CVE Blog content will be available there. Feel free to leave comments on any of the older posts. Please use this new page to comment on, ask questions about, and share our newest posts as we move forward.

We will also be posting news items on the LinkedIn page that may be of interest to you. Feel free to comment on, ask questions about, and share these posts as well.

As you probably noted from the title of our new LinkedIn page above, it's not solely about CVE. We also hope to encourage discussion about issues and topics related to Common Weakness Enumeration (CWE™) and Common Attack Pattern Enumeration and Classification (CAPEC™). As with CVE, both CWE and CAPEC are community-driven standardization projects addressing common needs among IT and cybersecurity professionals, and we encourage you to visit their websites to check them out.

Finally, if you have any suggestions about what you want to see as future posts on the new LinkedIn page, please let us know by commenting on any of the posts already available there, or by contacting us directly at,, or

Our new "CVE-CWE-CAPEC" page is available on LinkedIn at Please stop by and say hello. We look forward to hearing from you.

- The CVE Team
  March 9, 2017

Summary of your feedback about updating info in CVE ID Descriptions

Comment on LinkedIn | Share this post

Thank you for your responses to our most recent post "What's your opinion on updating CVE ID Descriptions?" about whether or not CVE ID Descriptions should be updated as new information becomes available, or if we should we reject and recreate the CVE IDs instead.

Updating of CVE ID Descriptions is preferred

The majority of respondents indicated that updating CVE ID Descriptions with new information is preferable to rejecting and issuing new CVE IDs.

The goals of CVE entries are to help people find the information they need about a vulnerability and provide enough information to allow people to be confident they are talking about the same vulnerability. Ensuring that CVE entries contain the most recent information on a vulnerability, either by updating an existing CVE entry or rejecting and issuing a new CVE entry, supports these goals.

Moving forward

As the CVE program continues to develop its policies and practices, we will consider the feedback from the CVE community on the benefits of updating CVE entries versus issuing new CVE entries.

If you have any further comments on the practice of updating CVE descriptions, please let us know. You can offer your feedback through the CVE Request form at or via email at

Thank you again to all who participated.

- The CVE Team
  February 2, 2017

What's your opinion on updating CVE ID Descriptions?

Comment on LinkedIn | Share this post

Last month, we asked the CVE community how you used CVE ID Descriptions. This month, we are following up on that question, asking about another aspect of how CVE ID Descriptions and their content are used.

Specifically, we would like to hear your thoughts on updating CVE ID Descriptions when new details about the vulnerability become available.

When a CVE ID is published, the Description of the vulnerability includes the details that are available about the vulnerability at that time. But as time goes by, more information may come to light regarding the vulnerability that should be reflected in the Description.

For example, the products or versions of products that are affected by the vulnerability may need to be updated after a vendor releases new information. Also, the CVE ID could change from covering a single product to a library or protocol that affects many products.

To update or not update

When such changes happen, CVE could update existing CVE ID Descriptions with that new information. But is doing so a problem for CVE consumers?

For example, in December, someone may see a new CVE ID describing a vulnerability in version 1.2 of ProductX. They use version 1.3, so they can ignore the vulnerability. But then the following February, ProductX's vendor finds that the vulnerability does affect version 1.3, and CVE updates the CVE ID Description to include that detail. At this point, the consumer may not notice the change, or they find themselves suddenly susceptible to a vulnerability to which they thought they weren't vulnerable.

Alternately, CVE could assign a new CVE ID that includes both version 1.2 and 1.3 and reject the original CVE ID. The scope and affected products of the new CVE ID would be unambiguous, and the new CVE ID would be picked up by the usual vulnerability management processes that an organization might follow. The downside of this methodology is confusion about the state of the original CVE ID, which is still valid but not complete.

One scenario that CVE has seen commonly is as follows: A vendor wants to issue an advisory before they know what the fixed patch version will be. They could include the currently known, affected versions, but this could mistakenly mean that later versions are not affected. Alternatively, they could leave out mentioning any version information in the first place and update the description when they know what is the complete range is.

What do you think?

Should CVE update CVE ID Descriptions as new information becomes available, or should we reject and recreate CVE IDs instead? Is there another practice that you would find more helpful?

Please email us at with your thoughts regarding updating CVE ID Descriptions before the end of this month.

All feedback will be collected, aggregated, and posted on this page the first week or so of January. Also, please let us know in your message if you do not want your feedback included in the publicly posted results.

We look forward to hearing from you!

- The CVE Team
  December 15, 2016

Summary of your feedback about how Descriptions are used in CVE IDs

Comment on LinkedIn | Share this post

Thank you for your responses to our CVE blog question "What's your opinion on how Descriptions are used in CVE IDs?". We received five responses from various CVE users, and we look forward to hearing more from across the CVE community.

A business need for Description in CVE IDs

Overall, there appears to be a business need for CVE ID Descriptions. The details provided in the Descriptions strengthen an organization's business case by providing the details required to add credibility to the vulnerability claim and to differentiate between vulnerabilities. CVE ID Descriptions are not dependent on a reference website, improving availability. The Descriptions are searchable, users can track changes, and they can be used in different formats and presentations.

CVE ID Descriptions are often used internally to facilitate the discussion about a vulnerability. A concise CVE ID Description is easier to read on different devices then a linked reference. In addition, linked references are not always available, relevant information is not always evident, and websites do not display properly on different types of devices.

All the information provided in the CVE ID Description is seen as valuable, with the affected product/impacted version being the most important. The priorities of other fields can vary, however the more extensive or expensive the fix, the more all Description fields are important.

Moving forward

In October 2016, other entities were given the ability to write CVE ID Descriptions. Feedback on the quality of CVE ID Descriptions will be very useful for understanding the effects of that change.

If you find the content of CVE ID Descriptions does not match your needs, please let us know through the CVE Request form at or via email at

Thank you again to all who participated.

- The CVE Team
  December 2, 2016

What's your opinion on how Descriptions are used in CVE IDs?

Comment on LinkedIn | Share this post

Since its inception in 1999, the CVE Program has included IDs, references, and descriptions in CVEs. Descriptions have primarily functioned as a method for the CVE Program to search CVEs, identify duplicates, and perform other similar functions.

We believe that other members of the community use Descriptions as well, but are unsure how they are used today or which parts of Descriptions are considered valuable.

The CVE Team invites you to email us at between now and November 17, 2016 to tell us about your experience using Descriptions. All feedback will be collected, aggregated, and posted on this page the week of November 28, 2016. Please let us know in your message if you do not want your feedback included in the publicly posted results.

Any and all feedback about Descriptions in CVE IDs is welcome, but in your response we ask that you please answer these three specific questions:

  1. Do you use or have a business need for Descriptions in CVE IDs as they exist today? If yes, can you explain the use or need? If not, would a CVE ID still be useful to you without the Description (i.e., an ID and one or more references)?
  2. Descriptions include information such as affected products and versions, affected components, attack types, attack vectors, and impact. Do you find all of this information equally valuable? If yes, what information is of most value and can you prioritize it? Is there any information that you would suggest CVE add or include when available (i.e., are Descriptions in CVE IDs missing anything)? Is there information included in a CVE Description that is not valuable to you? Why?
  3. What industry or community do you associate yourself with (e.g., government, vulnerability discloser, security product vendor, security product user, security industry, other)? This will help us identify how valuable descriptions are to CVE Program stakeholders.

We look forward to hearing from you!

- The CVE Team
November 3, 2016

Page Last Updated or Reviewed: October 13, 2017