The Journey to 300,000 Vulnerabilities: The Good, The Bad, and The Bizarre

Recently, our VulnDB team reached a tremendous milestone in our pursuit of best-in-class vulnerability intelligence: aggregating our 300,000th vulnerability disclosure. While that is a significant accomplishment and cause for celebration, it is also a grim reminder of what security teams face every day.

Instead of constantly reminding vulnerability managers and information security teams how bad software can be, we want to showcase the sometimes weird path our research has taken us. Here are some of the most interesting and colorful vulnerability disclosures we’ve come across.

Tracking the First Vulnerability

When many think about the computer security industry, they tend to believe that it is relatively young. However, it is actually over a century old! In a previous post, we took a deep dive into the world’s oldest vulnerabilities affecting Guglielmo Marconi’s wireless telegraph. And although these issues are more than a hundred years old, something can still be learned.

The first two recorded vulnerabilities resulted in the world’s first Man-in-the-Middle (MitM) interception, with Marconi’s vulnerabilities being unencrypted message transmissions that can trivially be intercepted, and a message spoofing weakness due to no authenticity being established. But looking now, this same kind of attack has been seen as recently as September 29, 2002, where a disclosure detailed MitM issues affecting multiple Mitsubishi Electric products. 

The second, message spoofing due to lack of authenticity checking, can be seen in a variety of spoofing issues ranging from improperly verifying SSL/TLS certificates, to relying on e.g. IP addresses as the authenticity check. Over 120 years later and many vendors still don’t heed the lessons that Marconi experienced in such a grand, albeit embarrassing, manner.

SQL Injections and Cross-site Scripting: Low-hanging Fruit

In the early 2000s, the world witnessed a mass migration to web applications as the desired interface for users and computer nerds alike. Accessing the web was easy, and the popularity of the internet helped create a single application designed to access an incredibly wide variety of systems and resources. But with this new technology came some hard lessons in writing secure code that led to a significant number of web application vulnerabilities such as cross-site scripting (XSS) and SQL injection (SQLi).

Since XSS flaws are arguably the easiest to find, it is no surprise that we saw significant numbers in the decade after 2000, and another significant spike in 2012:

SQL injection, which is easy to trigger a potential flaw, also took off in 2005 and a second significant spike in 2008. Many researchers, especially neophytes, would input a single character in an attempt to trigger an SQL error before definitively declaring they found a vulnerability. That error message is indicative of a potential SQL injection flaw, but it most certainly is not definitive. That made it difficult for the majority of vulnerability databases to weed out what was legitimate, but not VulnDB.

Rounding that out we saw significant spikes in the disclosure of cross-site request forgery (CSRF) flaws in web applications in 2010 and 2012. These flaws are relatively easy to discover and until 2010 there was no significant knowledge of the issue in developer circles. One might argue it is still that way given how prevalent CSRF flaws are—even in some of the most high profile applications and products.

Megavulns: Log4Shell, POODLE, Spectre, and More

In VulnDB, we have some entries that are simply incredible. Often the vulnerabilities with familiar names like Log4Shell, POODLE, Spectre, or Heartbleed to name a few, contain thousands of references and many thousands of affected products. We have dubbed these “megavulns” due to the sheer size each one represents and how prevalent they are. 

Examining these megavulns by number of products affected, Log4Shell comes in first place, followed by POODLE, Spectre v2, Spectre, and SWEET32. While the name is more common than some listed, Heartbleed only comes in at number twelve. Looking at the top 30 megavulns by product affected, 10 are in the Linux Kernel, five in OpenSSL, four in Oracle Java, four in multiple CPU vendors, and three are in Apache libraries. As of this blog, Log4Shell is now the king of all vulnerabilities with the most references, unique products, unique vendors, and vendor/product combinations.

In the scope of a vulnerability database, these entries are challenging. When given a name that becomes popular due to news coverage sticking to it, it results in more vendors feeling compelled to issue their own advisories. As more vendors do that, we have to aggregate all that data and constantly update these entries. Sometimes, we find ourselves still updating megavuln entries five years later.

Fun Oddities

Along the way we have seen some interesting, to say the least, vulnerability disclosures. Twenty four years ago, the r00t group posted a dark-humored advisory to Bugtraq warning of a serious race condition in a LitterMaid product. The automated kitty litter box, they said, could crush the cat “forcing the administrator to find a new best friend.” While this was a parody advisory, it still stands out as a fairly amusing one.

Adding on to the list of oddities, throughout the years, there have been disclosures related to Red Star OS, a North Korean Linux distribution. Apparently, the operating system suffers from default permission issues, client-side code execution issues, and many more. 

Aside from that, somehow, we’re still seeing vendors include default passwords for newly installed devices rather than forcing an administrator to set a unique one upon installation. Worse, we’re still seeing new products released with hardcoded passwords that cannot be changed by the administrator. With so many things moving to the ‘Internet of Things’ (IoT) approach, these include irrigation systems, thermostats, wind turbines, building control systems, and more.

Myths and NAVs

At time of publishing, VulnDB has officially crossed the 300,000 threshold of legitimate vulnerabilities. While we did announce that VulnDB reached 300,000 vulnerability entries, practitioners should be aware that a comprehensive vulnerability intelligence source also collects “illegitimate” disclosures. Including these types of entries is valuable to customers and should not be interpreted as a tactic to inflate numbers. By including “Myth/Fake” or “Not a Vulnerability”, a.k.a. NAV (a valid stability bug, but not a vulnerability) entries, our customers can quickly determine that we have evaluated the issue and clearly marked it as such, with reasons as to why—preventing them from wasting their time.

It’s worth taking a brief look back at these illegitimate disclosures since they are a growing part of our life. The first we have cataloged, a local buffer overflow in the ‘su’ program on Slackware Linux, dates back to August 1998. After the disclosure, the moderator of Bugtraq pointed out that no one had been able to reproduce it, and since the exploit code was derived from something he published, he was considered an authoritative source in two ways. Since then, the problem of invalid disclosures has become tremendous.

Arbitrary Numbers and Information on How We Got Here

Before we end this fun journey through the good, bad, and the bizarre, we’ll share a few arbitrary numbers and other tidbits of information about how we got here. Some may wonder what vulnerability is actually the first to appear in VulnDB. That would be “ColdFusion Application Server exprcalc.cfm OpenFilePath Parameter Arbitrary File Disclosure”. Many will see ColdFusion and have various feelings, including contempt, especially administrators charged with security systems with it installed.

VulnDB’s 300,000 entry ended up being “Linux Kernel SCSI WRITE SAME Command NDOB Bit Handling NULL Pointer Dereference Local DoS”. A little secret about the VulnDB team—we do our best to make sure either weird, fun, or high-profile vulnerabilities end up on big numbers. Originally, we had picked a vulnerability in “Oracle Unbreakable Linux” for our 300,000th entry, but subsequent examination showed it was actually a vulnerability in the Linux kernel instead. Foiled again.

Remediate Vulnerabilities with Flashpoint

VulnDB is the most comprehensive source of vulnerability intelligence available—detailing over 300,000 vulnerabilities affecting all manners of IT, OT, IoT, and third party libraries and dependencies. Using VulnDB, security teams have everything they need to identify known vulnerabilities affecting their deployed assets and remediate or mitigate them. Sign up for a free trial today.

Frequently Asked Questions (FAQs)

What is the journey of a vulnerability and how does Flashpoint Ignite track it?

The journey of a vulnerability is the process from discovery to remediation. Flashpoint Ignite tracks this entire lifecycle by aggregating data from independent researchers, vendor advisories, and illicit marketplaces. This provides a clear view of a flaw’s status, whether it is currently a secret zero-day, a coordinated disclosure, or a public CVE. By following this journey, Flashpoint allows organizations to stay ahead of the “disclosure gap” and patch flaws before they are weaponized.

Vulnerability Stage	Description	Flashpoint Ignite Strategic Benefit
Discovery	The initial finding of a flaw by a researcher or actor.	Identifies new threats mentioned in technical and illicit circles.
Reserved Status	A CVE ID is assigned but details are hidden from the public.	Provides independent technical analysis when NVD data is missing.
Public Disclosure	Full details and patches are released by the vendor.	Delivers immediate remediation advice and severity scoring.

How does Flashpoint help organizations identify “zero-day” vulnerabilities?

Flashpoint helps identify zero-day vulnerabilities by monitoring illicit forums and private markets where these exploits are traded. Because zero-days are not yet known to vendors or public databases, traditional scanners cannot find them. Flashpoint provides a “window” into the underground economy, alerting organizations when threat actors discuss new ways to bypass popular software. This allows security teams to implement defensive measures or compensating controls even before an official patch is available.

• Early Warning: Notifies you of trending exploits discussed in the Russian and Chinese underground.
• TTP Mapping: Explains the specific methods actors use to trigger unpatched flaws.
• Risk Context: Confirms if a zero-day is actively being used by APT groups or ransomware gangs.

Why is Flashpoint’s “source-to-signal” intelligence vital for security teams?

Flashpoint’s source-to-signal intelligence is vital because it turns raw data from thousands of global sources into a clear signal for defense. While public feeds like the NVD only provide a small piece of the puzzle, Flashpoint enriches every vulnerability with metadata on exploitability and solution status. This ensures that security teams do not waste time on “noise” and can focus their limited resources on the specific flaws that represent a confirmed path for an attacker to enter their network.

Intelligence Factor	Public Database Limitation	Flashpoint Strategic Advantage
Technical Depth	Often provides only a brief, generic description.	Includes deep research notes and vendor-specific workarounds.
Remediation Speed	Can take weeks to update after a patch is released.	Delivers verified solution links an average of 14 days faster.
Non-CVE Coverage	Ignores flaws in niche or third-party libraries.	Tracks over 100,000 vulnerabilities missing from public lists.