Did you know that the number of assigned Common Vulnerabilities and Exposures (CVEs) has been increasing yearly? While in 2021, approximately 20,000 CVEs were assigned, the number rose to 29,065 CVEs by 2023. Beyond serving as a system to catalog vulnerabilities, CVEs have evolved into a means of demonstrating expertise in the field. People often highlight their CVEs in their bios on platforms like X (Twitter) or their personal websites. In academic circles, a CVE can signify the real-world applicability of one’s approach, a factor that reflects in positive attention from peer reviewers. However, the current system is not without criticism, with some arguing that the database is becoming flooded with unnecessary issues and false claims. Driven by curiosity about the CVE assignment process and the question in mind of how prestige a CVE really is, I embarked on an experiment to get a CVE with the least effort possible.

Motivated by my mission to obtain a CVE, the easiest way I could think of was to turn to GitHub, a treasure trove of source code ready for analysis. I decided to focus on identifying a straightforward vulnerability that requires little effort to validate, so I chose to look for SQL injections.

To keep the manual effort as low as possible, I utilized GitHub’s search functionality. With GitHub’s search engine you can seek specific strings in code, for example, you can look for patterns that hint at SQL injections. Such a pattern could, for instance, be the following search string that looks for SQL statements that have a WHERE clause that matches an ID to some concatenated input (indicated by the .) provided from a potentially user-provided variable.

Id LIKE '".

Of course, this search returned numerous false positive results, yet it only took me a few minutes to uncover a promising repository: ExamSys.

ExamSys is a web application to run online exams. Thanks to a docker-compose file the developer offered, I could quickly deploy and test the application for SQL injection vulnerabilities. Although the entire web application was in Chinese, I was able (with the help of Google Translator) to exploit my local instance in just a matter of minutes using the classic UNION SELECT. The vulnerability allows an attacker to access usernames and passwords of all users.

You might consider this a critical vulnerability. And that assumption is generally true. However, the repository hadn’t been updated for three years, and the README explicitly states that the project was essentially abandoned. Additionally, a Shodan search didn’t reveal any publicly accessible instances of this application. Given these circumstances, I consider the vulnerability as not critical and I was curious if it even would qualify for a CVE. Only one way to find out!

The next step was to request a CVE. A brief online search led me to the CVE Form to submit CVE requests. On September 27, 2023, I filled out the form and sent it off. Waiting… waiting… waiting… After a three-month wait, during which I had almost forgotten about my little experiment, I received an unexpected email on December 31, 2023: “Use CVE-2023–55285“. A CVE was reserved!

With the CVE assigned, it was necessary to include a public reference in the CVE ID entry before publication. This could either be in the form of a blog post, a GitHub issue, or a similar disclosure. After informing the developer about the issue, I composed a brief blog post detailing the vulnerability and published it on January 14, 2024.

After submitting my public reference, the CVE was officially published in the National Vulnerability Database on January 17, 2024. And that was it, I got a CVE with the least effort possible. That was almost too easy.

The minimal effort it took to obtain a CVE made me wonder how easy it would be to trick or exploit the CVE system. A recent incident that went viral on X (Twitter) and sparked controversy hints that CVEs cannot always be trusted: Someone had the great idea to request CVEs for the Damn Vulnerable Web App; an application that is intentionally vulnerable for exercise purposes. While some people found the idea funny, it highlighted that the CVE assignment system is not without flaws. Of course, it led to lots of criticism in the community as such incidents undermine the credibility of the CVE system itself. Another excellent example of criticism comes from Daniel Stenberg, the maintainer of curl. His project was assigned a CVE for a bug rather than a security issue that was still graded with a CVSS of 9.8. Although the CVEs for both the DVWA and curl CVE were eventually invalidated after community backlash, the incidents left a sour taste as they caused unnecessary confusion and wasted valuable time.

Such CVEs claimed for problems that do not exist are not negligible. Misattributions and false claims complicate the task of monitoring vulnerabilities. It also slows down the assignment process for legitimate CVEs and makes it more inaccurate. It comes not from nothing that many CVEs are assigned for false versions. This leads to headaches keeping up with current security and a logistical nightmare for system administrators. In contemplating these issues I wonder, does the current CVE system serve its intended purpose effectively, or does it require reform to maintain its integrity and utility?

To be honest, I don’t know the path to reforming the CVE system. My own experience acquiring a CVE — not a very crucial CVE for the security ecosystem in general yet rated with a high score — highlights a dissonance within the system. For sure, it is a valid vulnerability. However, it raises questions about the necessity of cataloging every issue from small open-source projects, especially those that are no longer maintained and likely were never publicly deployed. Should these projects be included in the primary vulnerability database, or should they maybe be collected in a separate database? I’m unsure and would be happy to hear different opinions on that thought.

One point I can say for sure is that we need to recalibrate how we perceive and value CVEs. Of course, many of the CVEs demonstrate one’s expertise in cybersecurity, yet my experiment shows that obtaining a CVE does not always require advanced technical skills. Overemphasizing the prestige of CVEs could inadvertently encourage the exploitation of the CVE system leading to an increase in unnecessary CVEs and the various problems mentioned earlier. It’s crucial that the substance and context of a CVE, rather than its mere existence, be the true measure of expertise and knowledge.

Nevertheless, it’s essential to acknowledge the crucial role of the CVE system in our current digital infrastructure. Its function as a centralized database of vulnerabilities is indispensable, grounding numerous security scanners and warning systems. Despite the critiques and challenges laid out, the system’s significance is unquestionable. Still, as discussed, the system is not without flaws. And while I may not have the blueprint for reform, I am optimistic about our security community to come up with alternative proposals and new systems to overcome these flaws in the future.