Back in September of 2024, I took some notes on a blog I wanted to write about “Shadow” vulnerabilities, based on a corporate blog with a poor concept and misunderstanding of CVE. The title was to be “Shadow Vulnerabilities – Rebuttal” and pretty straight-forward. Vulnerability life is crazy when you help manage a true vulnerability database (VDB) that isn’t a clone of CVE, and operates independently. Jump to today and now I feel compelled to write a rebuttal to another project about “Ghost” vulnerabilities. So I figured it’s better to combine them, because the concept isn’t new and so many people tend to get it wrong. Either in truly understanding the problem or in execution for capturing them. Not to mention, even defining the problem correctly without a new gimmick name. Historically, I just called them “non-CVE” vulnerabilities since the world is overly preoccupied with the CVE ecosystem.
Defining the Problem
It’s difficult for some people to accept, or believe, that there are actually vulnerabilities that exist outside the CVE ecosystem. By that I mean CVE, NVD, and all the excessive efforts that focus exclusively on vulnerabilities cataloged by CVE. Meanwhile, while so many are trying to enrich these vulnerabilities, they aren’t helping address the systemic problem of the hundreds of thousands of vulnerabilities that are publicly disclosed, without being cataloged by CVE. For example, VulnDB currently has over 116,000 vulnerabilities cataloged that do not have CVE assignments. I can assure you that is the tip of the iceberg. The task of trying to catalog “all” of them is more monumental that most can imagine.
It’s pretty wild to see companies just figuring this out in 2024 when the problem was there from the inception of CVE. When launched in September, 1999, CVE had 321 records. By that point in time there were at least 3,700 vulnerabilities. The program was literally launched that far behind, and it has only gotten worse. This is a simple fact that anyone truly operating in the world of vulnerabilities should understand as a basic principle of the CVE ecosystem.
This rebuttal to the ‘Shadow’ and ‘Ghost’ vulnerabilities actually addresses the same general problem but the two entities take a different approach to catalog and highlight. Oligo’s term about ‘Shadow’ vulnerabilities is just the non-CVE issue, so discovering it a couple years ago tells you where they really are in this game. The second, about ‘Ghost’ vulnerabilities is a little different in that he is looking for cases where there is a CVE assignment, but the record is still in RESERVED status. That approach basically scrapes GitHub or other sources looking for a public disclosure that references a CVE but no details are available in CVE/NVD. Amusingly, the result was an underwhelming 400 vulnerabilities. Unfortunately, I don’t have a citation because the blog has been gone a while and it is extremely difficult to search the Internet Archive with that level of precision, but when we occasionally scraped VulnDB to see how many CVEs were still in RESERVED status, it was usually closer to 2,000 at any given time.
That’s it, that’s the entire problem in a nutshell. Yes, there are many, many vulnerabilities disclosed that never see the CVE ecosystem. We don’t need new terms for this 26-year old issue. Sorry to ruin your marketing.
So-called “Shadow” Vulnerabilities”
In late 2024, I found a blog that shows a lack of understanding what CVE is, and how it works, which led the company to invent a new term and attempted to use it extensively, presumably in hopes it catches on. They even went on to say the “industry has rapidly adopted” but I am pretty sure that is marketing fluff at best. But that misunderstanding seems to go beyond the defined problem when they attribute a ‘vulnerability’ to a product that documents opt-in insecure behavior, saying it too should have a CVE. From their blog:
That blog, titled “Vulnerable By Design: Understanding Shadow Vulnerabilities” defines the problem in their minds, and despite that absolute title, quickly and quietly disclaim it as “sometimes” by the fourth paragraph. So they are actually talking about two different issues, not one. Worse, they go on to set the stage saying:
So who decides what gets a CVE and what hides in the shadows? Now we’re entering the realm of responsible disclosure.
This is wrong, and their whole concept and notion of this is bad. If a vendor explicitly documents something as “this is insecure by design, it is up to the integrating party to provide security”, it has absolutely nothing to do with “responsible disclosure”. That term is so fucking wrong and it is irritating that people still use it, not understanding the origins and how political and polluted it is.
I quite literally blogged about this in 2001, explaining the problem, highlighting the origin, and all of the problems that came with it. Then the same vendor kept it up in 2007 and I blogged about it again. And yet again in 2009 when there was a “fresh aspect” to the debate around the polluted term, which flipped it and made it applicable to vendors too. No surprisingly I blogged about it then. I even have an unpublished set of notes from 2013 titled “why ‘responsible’ disclosure is dead” that never made it to a published blog. So please, just STOP using that crappy one-sided, unfair term. Apologies for that brief detour, but it apparently needs to be said on a weekly basis these days.
Oddly enough, Oligo published a blog titled “Oligo ADR in action: PaddlePaddle Shadow Vulnerability” in which they discuss a vulnerability that does not have a CVE. The blog serves as a big advertisement for their services, leaning heavily on the concept of the “Shadow” vulnerability. They define a problem, don’t appear to notify developers, don’t request a CVE, and help contribute to the problem they are warning their customers about… all for their own gain. It gets worse as they go on to say:
“For instance, NumPy version 1.21.6 does not have an assigned CVE, despite allowing Remote Code Execution when used with an insecure argument.”
Yes, and just above that they cite NumPy documentation explicitly warning about insecure arguments, recommending the integrator to “consider passing allow_pickle=False to load data that is known not to contain object arrays for the safer handling of untrusted sources“, so of course there is no CVE assignment. If there was a CVE assignment for every known or documented insecure behavior, it means one for every router with HTTP as a non-default option, any software that offers FTP even if not a default, etc. The amount of noise would make CVE even more worthless than it is.
Forgetting all that, the vulnerability they describe is effectively covered under CVE-2025-9905 anyway. Do you even CVE bro?
So-called “Ghost” Vulnerabilities
This approach is an execution problem I noticed via a post to LinkedIn by Jerry Gamblin. His methodology was to look at GitHub for CVE IDs that were public there, but did not have a corresponding record within CVE itself. His first run came up with 400 CVEs that met the goal. After some of my comments pointing out obvious errors, the second run came up with the anemic 141 results. While this is a fun exercise, all that scraping could have been designed to help catalog the incredible number of vulnerabilities that do not have a CVE ID assignment at all.
That said, let’s look at the first run and why there ended up being an obvious discrepancy of 259. Here are some examples that stood out to me simply by reading the numbers of the CVE ID or patterns in that file, nothing else. That’s how obvious they were; it required no digging, no validation on my side, just common sense.
- CVE-2026-99268, CVE-2026-98237, CVE-2026-82174 – While CVE IDs are not assigned in order, no ID was remotely close to the 99,000 range last year and logically no CNA would have been assigned IDs in a pool that high.
- koreatest12/auto – This appeared 189 times, what are the odds this one repository had cataloged that many? Even with a legitimate looking CVE ID, a simple check of the “Evidence” makes it clear there isn’t a vulnerability associated with it.
- CVE-2025-3292028, CVE-2025-3292029, CVE-2025-666666 – Technically, this is a valid ID as there is no limit on length, but only one “rogue CNA” ever assigned with 7-digit IDs and they haven’t for ages, and those were in the one million range. Obviously invalid ID here. I don’t believe there has ever been a six-digit ID either.
- CVE-2027-11111, CVE-2027-22222, CVE-2027-12345 – Another obvious invalid ID as it is a full year ahead of current. Further, any occurrence of the same digit five times, or five sequential digits screams “dummy CVE”.
- CVE-2025-0000000 – Obvious bad IDs are obvious, since there are no 0000/00000 IDs historically.
- CVE-2025-67890, CVE-2026-67890, CVE-2027-67890 – Statistically, what are the odds of the same five-digit suffix appearing on a list of 400 IDs, each with a different year? Of course, the 2027 ID is the biggest giveaway here.
- CVE-2026-0002 – Technically valid ID but this is where working with the disclosures and data helps, and often sets apart the meta-analysts from the data analysts. Last year that ID range belonged to AMD who hasn’t had any disclosures this year with a 2026 ID yet. While there is no guarantee AMD will get the same pool, it’s still a red flag.
So it’s clear that some very basic logic needs to be applied to such efforts. Ruling out bad CVE ID syntax, ruling out future years, and then dumping patterns like 12345 or 11111 into a queue to check before calling them a “ghost” is a better methodology here. I do want to point out that there is merit to this effort, but it’s the wrong approach. For example, the list contains 41 entries associated with “ZDI Advisories”. These are exactly what Gamblin was looking for; public vulnerabilities with a CVE ID that are still in RESERVED status.
However, scraping GitHub is just not the way to easily find these. At least, for anyone on the VulnDB team anyway. That’s where having a vulnerability database that actually proactively monitors for disclosures, a “go to the source” methodology, is better than MITRE/CVE’s “come to us” methodology. Every one of those 41 ZDI advisories were published on January 9 and have been available for 10 days, yet the CVE IDs sit in RESERVED status. This is a breakdown in the CVE/CNA process where either ZDI broke rule 4.5.1.3, or MITRE received the request to publish and failed to act on it.
Either way, this is CVE failing their stakeholders which impacts entities around the world. That further cascades downhill as just about every security product irrationally uses CVE as their sole source of vulnerability intelligence, or perhaps with a trivial amount from other places. Anyway, looking at GitHub for these so-called “ghost” CVEs makes for a trivial proof-of-concept at best, since the second run yielded better results. What does the difference look like? The first run, according to VulnDB data, had 135 valid CVE IDs with public disclosures versus 239 invalid or questionable. Based on what I outlined above, a majority were invalid. So it is easy to just dismiss them and walk away, as it clearly adds more noise than value.
The second run shows 133 valid CVE IDs with public disclosures, and nine that I would consider “to investigate”. It only takes a few seconds to invalidate every single one as the evidence is a Debian Security Tracker link that doesn’t reference the IDs at all. So fun exercise but this yielded precisely zero new vulnerabilities for ingestion into VulnDB. Except… in a small twist of irony, while the first run did add more noise than value, it still provided value. The irony being is that at least one CVE that appears to be valid with a public disclosure appears on the first list, and not the second. So I am glad Gamblin took my comments to heart, but it seems like he may have overdone it with filtering. Yay! Another vulnerability that will be in VulnDB tomorrow while still RESERVED in CVE, and disclosed almost nine months ago.
This is where I would say that some day MITRE will take vulnerability intelligence seriously, or hire qualified experts in VDB management, but I think we know after the last decade that isn’t likely to happen. Until then, those stumbling along with CVE as their source of vulnerability intelligence… good luck. You’ll need it.
Leave a Reply