VEXing False Positives for Fun and Profit

Time for another false-positive CVE deep dive, and an explanation on why OpenVEX is necessary. Today's culprit, CVE-2018-25076 - a five-year old CVE in a PHP library that recently started appearing in Node.js.

This CVE has a 2018 identifier, meaning it was initially disclosed in that year. But CVEs can be issued retroactively, and this one was actually only granted a month ago, in January of 2023!

The only real description present indicates this CVE is present in some PHP source code:

"A vulnerability classified as critical was found in Events Extension. Affected by this vulnerability is the function getRandomFeaturedEventByDate/getUpcomingFeaturedEventsInCategoriesWithSubcategories/recacheEvent/searchResults of the file classes/events.php."

The link to a patch takes us to this GitHub repo which has 1 star and no recent activity or indication of usage. The fix was filed without an issue and the software doesn't even have releases published. Why then, would a CVE in this code start showing up in Node.js this week?

I'm guessing someone filed this retroactively due to bad incentives. This happens quite often, and the CVEs typically are of low quality with inflated CVSS scores. This one fits the bill. It has a CVSS score of 9.8/Critical, and the originating CNA is vuldb which manages contests to sell exploits for things like this. Bad incentives are filling the vulnerability management industry with noise and resulting in poor quality vulnerability data. This needs to stop.

For the second part of the question, why is a CVE in a tiny PHP app showing up in Node.js itself? You can see it by running Grype on any container image that contains node.js. The code here surely isn't present - it's the wrong programming language! The answer here is again poor quality data in the NVD. The way scanners match vulnerabilities to software today is by using the CPE system.

The matching CPE for this vulnerability is: "cpe:2.3:a:events_project:events:*:*:*:*:*:bigtree_cms:*:*", which contains quite a few wildcards and is completely useless for matching. The official CPE scheme is supposed to be:

Here, they've used "events_project" as the vendor (I have no idea where this came from), "events" as the product, a bunch of wildcards for versions, then bigtree_cms as the target software.

Node.js contains an NPM package called "events". For open source software like this, the vendor field is tough to correctly guess so many scanners wildcard this field when querying. The language portion is rarely used, so scanners have no way to know that this "events" has nothing to do with the version of "events" in Node.js.

The overall result is that we now have a bad CVE that shouldn't have been issued and was only done for Internet Points. The data in it is poor because of a mixture of low quality reporting and the low-fidelity of the CPE schema and will waste hundreds of hours for security teams.

This is why I'm excited about OpenVEX.

The only real mechanism today to help quiet scanners like this is for the scanners to maintain large lists of false-positive CVE matches. Many do this, but it's hard and not scalable. With OpenVEX, the creator of a container image or product containing Node.js would be able to issue a VEX document explaining that this specific CVE is a false-positive because the affected code is not present in the image. Scanners would be able to remain over-eager in matching to help prevent false-negatives, and then automatically filter out the VEX'ed false-positives.