Rebuttal: How to avoid headaches when publishing a CVE

On May 12, 2022, Adeeb Shah published an article on Help Net Security titled “How to avoid headaches when publishing a CVE”. Shah is a Senior Security Consultant with SpiderLabs, part of Trustwave. Note that it also appears on Trustwave’s blog and includes a second name in the byline, Bobby Cooke. For the sake of this blog, I will refer to Shah as the author as it appears in my first link.

Shah leads the blog with a comment, cheer, and a question: “You have discovered a vulnerability. Congratulations! So, what happens next?

Unfortunately, problems start with the second paragraph of his blog and carry through the entire thing. Ultimately the advice and direction Shah provides is misleading and shows a lack of understanding of the vulnerability discovery, disclosure, and CVE ID request process. This blog offers a rebuttal to Shah’s article and offers a different perspective based on more experience with parts of the process. Since Help Net Security is read by many in the hacker and security communities, including by those starting out, striving for accuracy is important.

Finding a CVE (Common Vulnerabilities and Exposures) is the first step in a process which starts with the identification of a zero-day and could end with fame and glory – if the discovery is significant enough.

Equating a CVE with a vulnerability is becoming more prevalent the last few years and it needs to stop. It is entirely inaccurate despite them seemingly being the same. While ‘Vulnerability’ appears in the CVE initialism, what happens if a vulnerability does not have a CVE ID assigned? Is it no longer a vulnerability? Of course not. Finding a vulnerability is the first step in the process of … finding a vulnerability. It isn’t “a CVE” until an ID is assigned at some point after discovery, and it isn’t necessarily a zero-day either. Vulnerabilities are discovered by one person despite being discovered by one or many others before them. Mutual discovery is a surprisingly common thing.

Newcomers to the security research field will know that publishing a CVE can be a great career move.

Do they know it can actually work against them? They should. Publishing an advisory that is full of errors or makes bad assumptions can hinder their career. Further, if they publish “a CVE”, meaning literally the ID and nothing else, it actually causes a world of headache for many other security professionals. Yes, an increasing number of people are doing just that and I have called it out in prior presentations and on Twitter periodically. A random CVE ID in a Twitter profile, a Tweet, a LinkedIn “honor”, and similar “disclosures” are not how CVE is designed to work. Having an ID means precisely nothing because MITRE rarely validates a vulnerability before assigning an ID. You can request one based on entirely made up information and you are likely to get an ID. Hundreds of researchers submit issues that are explicitly not a vulnerability and still receive an ID every year.

It can take a lot of trial and error to master the craft of CVE publication.

I won’t argue this. Instead I will point out that statement is pretty accurate and a damning indictment of the security industry, and more specifically, MITRE. In their 23 years have they ever published guidelines for researchers on disclosing vulnerabilities? I don’t believe so.

A zero-day is not a zero-day if it has been previously identified.

I fear that the definition of “zero-day” has been lost, like it has been for “hacker” and other terms. Historically a zero-day is a vulnerability that is known by at least one party, but not by the vendor, and without a solution. As such a zero-day can still be a zero-day if two different parties know about it, if they haven’t published it. Note the word ‘published’ there’, which is accurate, rather than ‘identified’.

The first place to check is the MITRE database. Searching GitHub, ExploitDB and PacketStorm can also prove whether the vulnerability is new. Even a quick Google search can work wonders.

Let me go ahead and save everyone some time. Start with Google as it has more of a chance of finding the information you are looking for. Google indexes those other sites and a lot more, including literally thousands of other sites, mail lists, and blogs where people publish vulnerabilities that do not have a CVE ID.

Once a researcher has proved that they have discovered something no-one else has spotted, it is time to move onto the next stage of the process.

Searching all those resources still doesn’t prove anything. It just proves you haven’t found a prior disclosure of that same issue. But it may be out there, out of view of Google. There is a lot in the realm of vulnerabilities that is out of view of Google so you simply can’t make this statement. It may also be indexed by Google, just using a different description than you used. Or a different language.

If a researcher manages to contact the right person, the next stage involves building a relationship and working together to coordinate disclosure with mitigation and the issuing of a patch.


Responsible disclosure is important because threat actors will seize upon any CVE made public.

This section started out good, but quickly went sideways when Shah switched “coordinated” (correct)” to “responsible” (incorrect). This goes all the way back to 2001 actually and I was blogging about it that far back. Cliff notes; use coordinated disclosure as it is a better description and not a loaded term that favors the vendor.

The next scenario in Shah’s list of two whole scenarios is confusing and seems to set researchers up for headache:

A vendor may ignore the researcher. In which case, the person who discovered a vulnerability should try other methods of communications.

If the vendor ignores you? You need to clarify what you mean there. There is a difference between ‘does not respond at all’ which may warrant following the rest of your advice, versus ‘acknowledged you and ignored your report’ in which case the subsequent advice is pointless harassment of the vendor. Details matter here.

If these attempts don’t end up working and the vendor continues to ignore you, the best approach is to wait for a set length of time after attempting to contact the vendor. Researchers tend to wait for 30, 60, 90 or 120 days – but there are no rules about disclosure, so this is up to individual researchers.

Again, it will depend on what you mean by “continues to ignore you” exactly, but waiting even 30 days is pointless if the vendor acknowledged your contact and then ‘ignored’ you after that for any number of reasons. Vendors are busy. Some ‘vendors’ don’t get paid for the software they maintain so your notion of what responsive or timely is will be very different to them. You have to take into account who the vendor is, what the software is, and what might prompt them to ignore you (for any reason).

At this stage, it is worth filing a CVE request form on the MITRE website because waiting for it to respond can introduce delays to the process.

This too is bad advice. CVE was originally put forward by some as a way to assign an ID that could be used to refer to a distinct vulnerability, useful during the research, triage, and disclosure process. Back in the day, the early CVE Numbering Authorities (CNA) would often assign an ID upon receiving details and each subsequent communication would refer to that CVE ID. 

In the case of two researchers discovering the same issue, the vendor could refer to that ID with both parties without disclosing any details from one to the other, and regardless of what each researcher called the issue. One might call it a “remote stack overflow denial of service” while the other did more research and discovered it was actually a buffer overflow that could lead to code execution. By referring to the assigned CVE, the vendor didn’t have to tell the first party their analysis was wrong and didn’t have to keep referring to the issue incorrectly even when they knew better.

Once you discover a vulnerability, if it doesn’t fall under any vendor CNA, you can request the CVE ID from MITRE right away. That way when you submit the vulnerability to the vendor you can include the CVE for tracking purposes. For vendors aware of CVE, this also indicates to them that you likely do plan to disclose the vulnerability at some point.

MITRE refers to most companies as a CVE Numbering Authority (CNA) and you will be able to select which CNA the vulnerability applies to.

As of this blog, there are 221 CNAs. That is most certainly not “most companies”.

Our experience suggests that a CVE will be accepted in roughly 30 days.

Yeah? What experience is that? Because a CVE can be assigned in as little as 30 minutes lately to more than 300 days in years prior. The CVE program changes over time, sometimes for the better, sometimes for the worse. If you are telling people it takes 30 days to get an ID and you are telling them to request an ID after/if the vendor ignores you “because waiting for [CVE] to respond can introduce delays to the process“, then you are explicitly giving advice that further slows down the process. That is why you should just request an ID after you discover and validate that the vulnerability is legitimate.

When it is approved, researchers will receive a CVE ID by email and the vulnerability will be in a “reserved” state – which means it is accepted by [sic] not published. At this stage, MITRE has acknowledged the CVE is genuine but is awaiting disclosure.

This is incorrect. First, the ID is actually in RESERVED state before it is even assigned to you. Second, assignment of the ID only means that MITRE has acknowledged you submitted a vulnerability to them. It does not mean the vulnerability is “genuine”. MITRE does not validate vulnerability submissions; they literally cannot most of the time as they aren’t provided enough details to do so.

If MITRE has accepted the CVE it is time to disclose.

Statements like these make it very difficult for me to be diplomatic in these rebuttal blogs. This is absolutely absurd and makes no sense. MITRE accepting your vulnerability submission and assigning an ID has nothing to do with dictating when to disclose. That is up the researcher entirely. If you request an ID early in the process before contacting the vendor, which is certainly one valid way to approach this process, the above advice is wrong. Even if you follow the rest of Shah’s advice, this can still be wrong.

A POC/ exploit can be sent to PacketStorm Security/CX Security. Be sure to include the ID MITRE number and follow these guidelines to make sure your message has the correct header.

This section makes it appear as if Shah is quite new to vulnerability disclosures and a big warning sign to take his advice with a few grains of sand. PacketStorm, CX Security, and Exploit-DB (linked to) are just three of many thousands of sites or ways you can disclose. While all three have a steady stream of disclosures, consider that Exploit-DB is just approaching ID# 51,000. Consider that VulnDB has over 288,000 vulnerabilities cataloged. That shows that there are a lot of other options for disclosing, and those three sites may not be the best for you. Especially if you want to use the CVE for “a great career move“.

And that is it – a vulnerability has been published!

Yeah, just like that? This process is more likely to scare people away from following these convoluted steps than anything. One alternative to all of the above is to just write a blog explaining your disclosure and posting it (hopefully after reading these advisory writing guidelines). No CVE needed, you can reference your blog on your resume, and employers will judge you based on your technical merit rather than Shah’s misunderstanding of the CVE ecosystem.

Leave a Reply