The Myth of the Meteoric Rise in Vulnerabilities

The Myth of the Meteoric Rise in Vulnerabilities

Speakers: Scott Moore, VulnCheck

Conference: VulnCon

YouTube: https://www.youtube.com/watch?v=H8sYl2fPtDs

Overview

In his compelling VulnCon talk, "The Myth of the Meteoric Rise in Vulnerabilities," Scott Moore of VulnCheck challenges the prevailing narrative that the number of security vulnerabilities is skyrocketing uncontrollably. While acknowledging that the raw count of Common Vulnerabilities and Exposures (CVEs) has indeed risen dramatically, Moore meticulously dissects the underlying factors contributing to this trend, revealing that a significant portion of the increase is attributed to "noise" rather than a genuine surge in critical, exploitable flaws in widely adopted software. His presentation underscores a critical issue in modern vulnerability management: the signal-to-noise ratio in vulnerability intelligence is deteriorating, making it increasingly difficult for security teams to prioritize and address actual threats.

Moore, a veteran in the vulnerability intelligence space with a deep history in data collection and database creation, argues that this artificial inflation of CVE numbers has profound implications for the security industry. It misallocates defensive resources, distorts risk assessments, and makes the job of security professionals unnecessarily complex. By meticulously tracing the history of CVE assignments and exposing questionable practices by certain CVE Numbering Authorities (CNAs), particularly concerning low-quality, re-skinned software projects, Moore provides a data-driven indictment of the current state of vulnerability reporting. His talk serves as a call to action for the community to critically evaluate the sources of vulnerability data and strive for greater accuracy and relevance.

The central thesis of Moore's talk is that while vulnerabilities persist and new threats emerge, the perceived "meteoric rise" is largely a statistical artifact. The sheer volume of reported CVEs, often for identical, non-production-grade code, creates an illusion of widespread catastrophe. This "noise" can lead to alarmist trend reports that fail to differentiate between a critical flaw in enterprise software and a trivial bug in a student project. Understanding this distinction is paramount for effective cybersecurity strategy and resource allocation in an increasingly complex threat landscape.

Background

▶ Watch: Introduction, data hoarding, and early career in security (0:00)

Scott Moore’s journey into the world of vulnerability data began early, rooted in a childhood knack for collecting and cataloging. Growing up in Oak Ridge, Tennessee, a town born of the atomic age, and having early access to computers, he developed a passion for understanding how systems worked and, more interestingly, how they could be made to do things they weren't designed to do. This led him to collect exploits in 1993-94, eventually publishing them on an early World Wide Web site. This personal initiative caught the attention of Internet Security Systems (ISS), which hired him in 1997 to establish what became the X-Force database. This database was one of the four foundational sources used to create the CVE program, a standardized identifier system for publicly known information security vulnerabilities.

The early years of CVE saw a gradual increase in reported vulnerabilities. However, Moore highlights several key events that dramatically altered the landscape of CVE reporting. A significant spike occurred before 2005, when a hacker known as "stroke" and the group Milworm launched a public exploit database. This database contained thousands of vulnerabilities, including a thousand cross-site scripting (XSS) and 700 SQL injection flaws, which MITRE, the organization overseeing the CVE program, was compelled to assign CVEs for. This event alone saw the number of reported vulnerabilities jump from approximately 1,600 to 6,300 in a single year.

Another notable event, though less impactful on the overall numbers due to intervention, was Will Dormann's work in 2014. Dormann developed a tool to identify SSL vulnerabilities in Android applications, which he ran against one million apps. His team found a staggering number of flaws, issuing 1,420 CVEs, but this represented only about 8% of their total findings. MITRE intervened, asking them to stop, preventing what could have been an issuance of 60,000 CVEs. This instance demonstrates that the potential for rapid CVE inflation has existed for some time, often mitigated by external factors or decisions.

The landscape further shifted in 2015 with the addition of 25 new CNAs, including major corporations like IBM and HP. This expansion was necessary as MITRE struggled to keep pace with the volume of incoming vulnerability reports. However, the most significant change, according to Moore, occurred in 2021 when Research CNAs were permitted to assign CVEs for vulnerabilities reported to them, even if they hadn't discovered the flaws themselves. This policy change, Moore contends, marked a turning point where "all hell breaks loose," leading to the current inflated numbers and the proliferation of "noise" in the CVE system. Moore himself acknowledges being "part of that problem" in his capacity. This historical context sets the stage for understanding why the current vulnerability reporting system is, in his view, fundamentally flawed.

Key Findings

▶ Watch: Distinguishing 'real' CVE growth from inflated numbers (11:50)

Scott Moore's core finding is that the perceived "meteoric rise" in CVEs is largely an illusion, significantly inflated by the proliferation of vulnerabilities assigned to low-quality, non-production-grade software. He identifies several key factors contributing to this phenomenon, fundamentally challenging the alarmist "sky is falling" reports frequently published by security vendors.

The primary culprit, according to Moore, is the existence of "CVE factories" – specific websites that host vast collections of identical, re-skinned PHP student projects. Websites such as SourceCodester, Code Projects, PGP Gurukul, ItSource, Code Canyon, and PHP Jabbers are highlighted as prime examples. These platforms, designed primarily for ad revenue, offer free source code for projects with comical, generic names like "Hospital Management System," "Zoo Management System," or "Blood Bank Management." Moore's investigation revealed that many of these projects, despite their different names and superficial appearances, are built upon the exact same underlying code template. They are merely re-skinned versions of a single, vulnerable codebase, often bundled with presentation materials for academic assignments.

Moore's deep dive into these projects confirmed that they are riddled with basic, easily discoverable vulnerabilities. A pervasive example is SQL injection in common files like login.php, where user input is directly concatenated into SQL queries without proper sanitization (e.g., select star from table where user equals input and password equals input). He found that every single SQL query in these projects was vulnerable. Crucially, he discovered that CNAs were assigning separate CVEs for the same underlying vulnerability when it appeared in different, re-skinned versions of these projects, directly contradicting the CVE operational rule that states "one CVE for one independently fixable vulnerability" – especially if they share the same code.

Quantitatively, Moore presented startling figures. SourceCodester alone hosts 369 "different" vulnerable applications, which he asserts are effectively 369 instances of one template. He found over 1,700 CVEs already assigned to projects on this single site. His full scan estimated that only 16% of the potential vulnerabilities in these CVE-assigned projects have been reported, leaving an estimated 15,243 CVEs immediately assignable. Extending this to the total number of projects on SourceCodester (1,700), he conservatively estimates that 81,000 CVEs could be assigned tomorrow for this essentially identical, non-production code.

Moore contrasts this with legitimate software like WordPress plugins, which are used by billions worldwide and genuinely warrant CVEs when vulnerabilities are found. He demonstrated that finding real vulnerabilities in such software is still relatively easy, having personally discovered 203 CVE-able flaws in 15 WordPress plugins within two hours using an AI assistant. This stark comparison underscores his argument: the current system is flooded with irrelevant noise while actual threats in widely deployed software compete for attention.

Finally, Moore also points out questionable practices by some CNAs, such as advertising their products within CVE descriptions, only to delete the advertisements hours later. He speculates this could be a deliberate tactic to "pollute large language models" that scan vulnerability data, ensuring their product is associated with CVEs even after the direct advertising is removed. This highlights a broader issue of data integrity and potential manipulation within the vulnerability ecosystem.

Technical Deep Dive

▶ Watch: Speaker demonstrates mass SQL injection in student projects (17:50)

The technical core of Moore's argument lies in the fundamental flaws present across the "CVE factory" projects and how these flaws are systematically reported and assigned CVEs in a manner that inflates the overall count. The vulnerabilities are not complex zero-days but rather basic, easily exploitable errors indicative of poor coding practices, often characteristic of early-stage software development.

The most prevalent vulnerability Moore identified across these projects is SQL injection. He specifically cites the common pattern found in files like login.php. In these instances, user-supplied data (such as username and password) is directly inserted into SQL queries without any form of input sanitization or parameterized queries. A typical vulnerable code snippet would look something like select * from table where user = 'input_username' AND password = 'input_password', where input_username and input_password are directly concatenated strings derived from user input. This allows an attacker to inject malicious SQL code, bypassing authentication, extracting data, or even manipulating the database. Moore states unequivocally that "every single SQL query in all of these projects is not concatenated. You can put whatever you want in them. They're all SQL injectable to your local Maria database."

These projects, often labeled as "management systems" (e.g., Hospital Management System, Salon Management System, Bank Management System), are typically written in PHP and designed to run on a local HTTP server with a database like MariaDB. The re-skinning process means that while the project names, graphical interfaces, or specific features might differ, the underlying PHP code, including the vulnerable SQL queries and other insecure practices, remains identical across multiple "products." This directly violates the spirit, if not the letter, of the CVE program's operational rules.

Moore emphasizes the CVE operational rule which states: "if multiple products are affected by the same independently fixable vulnerability... the CNA must not assign more than one CVE. So, one CVE for one piece of code. If they share the same code, one CVE." The practice of assigning a new CVE for the exact same SQL injection vulnerability in login.php across 369 different "SourceCodester projects" (which are, in essence, the same codebase) directly contravenes this principle. This duplication creates an artificial surge in CVE numbers, as a single underlying flaw is counted dozens or hundreds of times.

He also notes other types of vulnerabilities, such as incorrect reports of file upload functionalities where no such code exists. This points to a lack of thorough verification by some CNAs or researchers, further contributing to the unreliability of the reported data. The ease of finding these vulnerabilities is underscored by Moore's personal experiment: he found 203 CVE-able issues in 15 WordPress plugins in just two hours, demonstrating that real, impactful vulnerabilities are still abundant but are being overshadowed by the noise from these "CVE factories." This technical analysis reveals a systemic issue where quantity is prioritized over quality and adherence to established vulnerability reporting guidelines.

Demo / Proof of Concept

▶ Watch: Estimated 81,000 potential 'noise' CVEs from these sources (22:00)

While Scott Moore's presentation did not feature a live, interactive demonstration in the traditional sense, his "Technical Deep Dive" section serves as a compelling proof of concept through his personal investigative journey, which he describes as going "down the rabbit hole." His methodology directly validates his claims about the prevalence and nature of vulnerabilities in the "CVE factory" projects.

Moore's process began by downloading a sample of these projects locally. He specifically mentioned acquiring 10 projects, including four from SourceCodester and others from similar sites. Among the projects he downloaded were those with generic names like "Human Resources," "Hospital Management System," and "Salon Management System." His objective was to verify the commonalities and specific vulnerabilities he suspected.

His investigation involved a manual code review, focusing on common entry points for user input, particularly in PHP files that handle authentication or data submission. He specifically looked at login.php files, which are ubiquitous in such applications. There, he confirmed his hypothesis: "They had the exact same code in every login.php, which was select star from table where user equals input and password equals input." This direct concatenation of user input into SQL queries without sanitization confirmed the widespread presence of SQL injection vulnerabilities. He states, "every single SQL query in all of these projects is not concatenated. You can put whatever you want in them. They're all SQL injectable to your local Maria database."

Moore further illustrated the ease of discovering and reporting these flaws by outlining a "playbook" for anyone seeking to generate CVEs from these sources:

1. Download one of these projects.
2. Look for any GET and any POST parameters in the PHP code.
3. Identify variables directly concatenated into SQL queries.
4. File for a CVE for each vulnerable parameter.

He pointed out the absurdity of this process, noting that some comments on these project sites even contained full SQL injection exploits, with CVEs subsequently issued for them days later. This anecdotal evidence further solidifies the claim that these are not complex, novel vulnerabilities but rather elementary flaws being systematically identified and individually reported across re-skinned codebases.

Furthermore, Moore's estimation of 81,000 potential CVEs from SourceCodester alone, based on his analysis of the underlying code and the existing CVEs, acts as a quantitative proof of concept. He demonstrated that only 16% of the vulnerabilities in projects that already have CVEs have been reported, and there's a 25% average accuracy in the CVEs that have been reported for these projects. This extensive analysis, rooted in practical code examination, serves as the cornerstone of his argument that the CVE system is being polluted by redundant reports for fundamentally identical, low-impact vulnerabilities.

Defensive Implications

▶ Watch: Community role in preventing CVE pollution, LLM concerns (27:00)

The "myth of the meteoric rise" in vulnerabilities, as debunked by Scott Moore, carries significant defensive implications for cybersecurity professionals and organizations. The primary concern is the dramatic deterioration of the signal-to-noise ratio in vulnerability intelligence. When security teams are inundated with thousands of CVEs, many of which pertain to irrelevant or low-impact software, it becomes exceedingly difficult to identify and prioritize the truly critical threats that pose a risk to their specific environments.

This influx of "noise" leads directly to resource misallocation. Security analysts, already stretched thin, spend valuable time and effort sifting through CVEs for obscure student projects or re-skinned code that will never be deployed in a production enterprise setting. This distracts from addressing vulnerabilities in widely used software, operating systems, and critical infrastructure, where real-world exploitation could have severe consequences. Moore's analogy of assigning a CVE to a "cardboard box" compared to an "automobile" perfectly encapsulates this challenge – not all vulnerabilities are created equal, and treating them as such is detrimental.

The pollution of vulnerability databases, such as the National Vulnerability Database (NVD), also impacts automated security tooling. Security scanners, vulnerability management platforms, and risk assessment systems rely on comprehensive and accurate CVE data. When these databases are filled with irrelevant entries, automated tools may generate false positives, inflate risk scores for non-existent threats, or simply become less effective at highlighting actual dangers. This can lead to alert fatigue and a diminished trust in the very systems designed to aid defenders.

For defenders, Moore's insights necessitate a more critical and discerning approach to vulnerability intelligence:

• Scrutinize CVE Sources and Applicability: Organizations must move beyond raw CVE counts and assess the source and context of each vulnerability. Is the affected software genuinely deployed in their environment? Is it production-grade, widely used software, or a niche, unsupported project?
• Focus on Real-World Impact: Prioritize vulnerabilities based on their potential for impact within their specific context, considering factors like exploitability, active exploitation, and the criticality of the affected asset, rather than just the number of assigned CVEs.
• Advocate for CVE Program Integrity: While individual defenders may not directly influence CNA policies, understanding these issues allows them to advocate for stricter adherence to CVE rules and better quality control in vulnerability reporting. The community needs to demand a higher standard from CNAs, especially regarding the "one CVE for one independently fixable vulnerability" rule.
• Leverage Contextual Intelligence: Supplement generic CVE feeds with threat intelligence that focuses on vulnerabilities actively exploited in the wild or those targeting technologies relevant to their industry.
• Awareness of LLM Pollution: Moore's observation about CNAs advertising in CVE descriptions and then deleting them to "pollute large language models" highlights a future concern. Defenders relying on AI-driven threat intelligence should be aware of potential biases or misleading information introduced through such tactics.

Ultimately, Moore's talk is a call for greater discernment and a pushback against the uncritical acceptance of inflated vulnerability statistics. By understanding the "myth" and its origins, defenders can better allocate their finite resources, focus on true risks, and improve the overall effectiveness of their security posture.

Key Takeaways

• The perceived "meteoric rise" in CVE numbers is significantly inflated by vulnerabilities in non-production-grade software, leading to a distorted view of the actual threat landscape.
• "CVE factories" – websites like SourceCodester and Code Projects – host re-skinned, identical PHP student projects that are riddled with basic vulnerabilities, primarily SQL injection.
• Many CVEs are assigned redundantly to the same underlying vulnerability across these different, yet identical, software projects, directly violating CVE operational rules.
• This proliferation of "noise" in vulnerability intelligence makes it increasingly difficult for security teams to effectively prioritize and manage real, impactful threats in widely deployed software.
• Defenders must critically evaluate CVE sources, focus on the applicability of vulnerabilities to their specific environments, and prioritize based on real-world impact rather than raw CVE counts.
• A stricter adherence to CVE program rules and greater quality control in vulnerability reporting by CNAs is essential to restore the integrity and utility of the CVE system.

About the Speaker(s)

Scott Moore is a distinguished figure in the vulnerability intelligence community, currently associated with VulnCheck. With a career spanning decades, Moore has a profound passion for collecting and analyzing data, a trait he developed from a young age. His early work involved compiling exploit databases on the nascent World Wide Web, which led to his pivotal role in the security industry. In 1997, he was instrumental in establishing the X-Force database at Internet Security Systems (ISS), a foundational vulnerability database that later contributed significantly to the creation of the CVE program. His extensive background provides him with a unique historical perspective on the evolution of vulnerability reporting and the challenges facing the industry today. Moore is known for his data-driven approach and his commitment to uncovering the truth behind security statistics.