Vulnerability disclosure analysts are long familiar with so-called “mega advisories”, ones that typically come from vendors and often for products that ship appliances using hundreds of libraries or products with an entire operating system included. Such advisories can literally represent over 500 vulnerabilities in one shot. I’ll try to make this a bit fun!
Disclaimer: I am going to use one example, from one vendor, but I am not calling them out really. This is just one example that speaks to a bigger problem when dealing with CVEs in large volumes. Again, I am not calling Dell out, this is a single advisory I had to process while covering for someone on the team. Take this as a bit of a tongue-in-cheek critique, nothing else. That said, this is a case where it is very easy to make mistakes as the consumer of this advisory and serves as a warning that, unfortunately, you need to double-check all those CVE numbers carefully.
The advisory I am using for this example is “DSA-2025-116: Security Update for Dell Unity, Dell UnityVSA and Dell Unity XT Security Update for Multiple Vulnerabilities“. If you aren’t familiar with the products, Dell EMC Unity is part of Dell EMC’s “mid-range storage array product lines”. There we go, a storage array! So we have an appliance that is running a LAMP (Linux, Apache, MySQL, Perl/PHP/Python) stack which means it will need constant updates to remain secure. This fully explains a single Dell advisory (DSA-2025-116) covering over 700 vulnerabilities. Of those, only 16 of which are in Dell’s code while the rest are in third-party software used by the appliance.
There are several bad CVEs in this advisory, let’s explore why! The first one to stand out to me was CVE-2023-39709 because that covers a vulnerability in “mayuri_k Free and Open Source Inventory Management System“, not Apache HTTP Server, the section it appears in. That should be a pretty easy one to spot you’d hope! But again, when you are drowning in 700 sets of numbers, it is easy to get a bit brain-fried.
Next, I noticed that CVE-2023-2004 was included despite being listed as REJECTED, as not a vulnerability, in CVE. Despite that, it’s actually a valid denial of service vulnerability in FreeType. A Red Hat bug ticket shows it originated at OSS-Fuzz and was patched by the vendor. Subsequently, that patch landed in a fixed version as well as the Red Hat Build of OpenJDK, versions 11.0.21 (RH Advisory) and 17.0.9 (RH Advisory). Looking at the NVD entry, we see that they say the ID was rejected because it was withdrawn by the CNA as not a security issue. Clearly, some wires got crossed here and right now it is unresolved. Fortunately, REJECTED or not, Dell’s appliances are patched in case this is a legitimate issue.
This is a really minor one, and a very easy mix-up to make, but I noticed the advisory attributed “libxml2” for CVE-2023-2731, which is actually a vulnerability in “libtiff” instead. The appliance got the patch (I assume) so all is well for end users, but this is a little case where consumers of the advisory may run into confusion or question if the patch was applied. Similarly, CVE-2021-3864 is attributed to “logrotate” when it is actually a Linux Kernel vulnerability, the section right above it. Just a slight typesetting issue so-to-speak. You’ll have to trust me on this, or click into references, because “Linux Kernel” doesn’t even appear in the description. That’s an issue with the Linux CNA, a topic that I wrote about due to the numerous issues they are causing.
That’s it! Nothing too serious, the vulnerability world isn’t ending. We’re all drawing in the flood of CVEs lately so a vendor getting a few things wrong in an advisory of that size is actually pretty impressive. The odds of anyone reading that advisory and noticing anything is pretty slim. Just us pedantic vulnerability database nerds tend to do it.
Leave a Reply