Vulnerabilities without CVE

Last Updated on September 15, 2023 by Dave Farquhar

I had a discussion with somebody this week about vulnerabilities that don’t have CVEs. I learned from this conversation that there are a lot of misconceptions about those. So let’s talk about vulnerabilities without CVEs, and what to do about them.

What CVE means

vulnerabilities without CVE
Any vulnerability scanner will find vulnerabilities without a CVE, whether you’re talking Nessus or a competing scanner. That’s part of their job. But overgeneralizing about those findings or ignoring them are not the way to handle them.

CVE stands for common vulnerability enumeration. It is the industry standard tracking number for vulnerabilities. All CVEs are vulnerabilities. But not all vulnerabilities have CVEs.

Sometimes it’s just because they’re too old, and sometimes it’s because whoever discovered them never bothered to submit them. But for whatever reason there are large numbers of vulnerabilities that don’t have CVEs.

I know of one security vendor who claims to have knowledge of tens of thousands, if not hundreds of thousands a vulnerabilities that the vulnerability scanners don’t know about. I’ve never paid them much mind, because I’ve seen how much difficulty organizations have getting a clean Nessus scan. They don’t need 200,000 more low severity vulnerabilities to worry about. The problem isn’t lack of motivation, although that stance seems to be controversial for some reason.

Also, the scanner vendors are motivated to have large numbers of findings. So if they know about something that isn’t a CVE, they produced signatures for them. This was something of an arms race, because when trying to win business, some companies just put all three of them in a lab and scan the same machines. The one that finds the most is the automatic front-runner. It’s not the best way to evaluate, but it sounds credible.

Informational findings

Some non CVE vulnerabilities are informational. One scanner vendor tells you to ignore those, and plays up their lack of informational findings as a strength. As an analyst, I use those informational findings. If nothing else, I need them for troubleshooting occasionally. When a system won’t take patches, frequently there are some clues as to why in those informational findings. My favorite one is the pending reboot finding. While not a vulnerability in itself, when I see that, I know the patching team left money on the table. Rebooting the system is going to clear at least one random vulnerability off that system. But probably more.

So you don’t want to ignore informational findings, at least not all the time.

What to do about non CVE vulnerabilities

The person I was talking to thought that vulnerabilities that don’t have CVEs can’t be patched, and therefore there’s nothing you can do about them. That is over generalizing.

Some of them simply warn you about end of life software. That means that software isn’t getting updates anymore, but that doesn’t mean there isn’t anything you can do about them. You can upgrade to the new version. Yes, it may require some testing, but the perception that you still have to run one version of Microsoft Office forever is one of the things that causes the security issues that keep making headlines today. We have life cycle management for our car fleets and our elevators. We need to do the same for our computer software. And the longer we put it off, the more expensive the problem gets to fix. Letting old software fester isn’t thrifty, it’s shortsighted. Just like outfitting your car fleet with surplus cars you bought from Rent-A-Wreck.

But a large number of them fall into other categories. Almost every windows system has a handful of non CVE vulnerabilities on it. They tend to be fairly minor, so few people pay them much mind, but they require changing some default permissions or a registry setting. They aren’t difficult to fix, but they aren’t a matter of just deploying an update either. The unquoted search path finding is a good example of this.

And some of them are just obsolete crypto. The crypto we used in the mid-nineties isn’t powerful enough to still use today. There’s no specific CVE for it, it’s just we knew what the shelf life was for that crypto when we started using it, and we’re beyond that shelf life. The solution is to reconfigure your system so it’s not using that anymore. Again, it’s usually not a patch. But it’s a configuration change, whether that’s in a text file, or in the registry.

Dealing with vulnerabilities without CVEs

There’s no one-size-fits-all solution to this. People like common sense easy fixes, but frequently in life, solutions to problems don’t fit on a bumper sticker. Sometimes it’s complicated, and this is one of those cases. That’s why people specialize in vulnerability management. That’s what this field is called.

And it is management. That means taking stock of the problems, prioritizing, and ideally, not reinventing the wheel. There are some ways to go about doing this. One trick is to hire an MSSP. The quality of help you get will vary, but at the very least, you have someone who has seen problems from more than one company. It’s a fairly inexpensive way to learn from other companies’ experience.

But the key item is reading beyond that blank CVE field. Most vulnerability scanners include a solution field. And the solution for these vulnerabilities without a CVE usually aren’t blank. If the solution is to upgrade to a supported version, guess what happens when you update to a supported version? The finding goes away. And chances are, a pile of other vulnerabilities also go away.

That’s the other thing about the vulnerabilities without CVEs. Often they have other related vulnerabilities that do have CVEs. Solve the vulnerabilities in the scan results with some of the same keywords in the titles that do have CVEs, and there’s a good chance the ones without CVEs go away too.

If you want an easy button, I know of one, if you’re using a Tenable scanner. Tenable scanners have API-based integrations with Manage Engine and Big Fix remediation tools. If you happen to use one of those solutions in your organization, link them together. You’ll get a new page in the UI where you can click vulnerabilities and remediate them singly or in batches. Fix the easy stuff, then it gets a lot easier to figure out what to do with what’s left.

If you found this post informative or helpful, please share it!