F5 is a technology vendor that sells a variety of networking technology including security products. With a considerable security portfolio and long tenure in the industry they are well positioned to observe known exploited vulnerabilities (KEV). Their staff frequently write blogs about threat actor activity, exploit campaigns, and associated topics. Unfortunately, while they have great insight into this activity, their ability to convey that information in a clear manner is seriously lacking. In this blog I will highlight some examples with the hope that F5 takes it to heart to improve as it helps their customers and the broader industry.
Rabbit holes of vulnerability archaeology ahead. You’ve been warned!
Vague KEV for Years
For the first example, I noticed that in many of F5’s reports they include a long list of CVE IDs that are KEV they have observed. Looking at “Sensor Intel Series: Top CVEs in March 2023” there are over 50 lines with CVE IDs. There are also lines without a CVE ID and instead a vague description like “2018 JAWS Web Server Vuln”, “NETGEAR-MOZI”, and “Citrix XML Buffer Overflow”. The first gives a rough time frame which seems helpful on the surface. But we don’t know if that is the year it was disclosed or first detected. We also don’t know if that is the correct disclosure year if that is what is intended. Looking at VulnDB there are no Jaws vulnerabilities disclosed in 2017, 2018, or 2019 though.
The second, NETGEAR-MOZI is likely a tag or nickname for a vulnerability as originally exploited by the Mozi botnet. But there is no other information to go on and it is curious why F5 has never asked for a CVE assignment. They have the information on the vulnerable endpoint and impact so matching it to a public disclosure should be relatively easy. Finally, the “Citrix XML Buffer Overflow” is the most frustrating. This is high-profile, high-deployment, internet-facing technology that likely impacts many organizations. Based on a Google search for F5.com and that string you can see they have listed it as KEV for over two years no less.
Digging into this a lot further, as best I can tell it most likely corresponds with Fortinet IPS signature 29220. But that is a best guess based on my experience doing vulnerability work for a long time, including tracking KEV for a decade. With that signature we see another problem; Fortinet doesn’t provide citation for the vulnerability and does not include a CVE. It’s actually the lack of CVE that points to this being the likely culprit. That signature I believe is for Exploit-DB 17582 which also doesn’t have a CVE ID. That in turn gets more convoluted as that one Exploit-DB post actually covers two distinct vulnerabilities, with their respective VulnDB IDs:
| 74157 | Citrix XenApp and XenDesktop wpnbr.dll <Password> Element Field Parsing Overflow |
| 74158 | Citrix XenApp and XenDesktop XML Service ctxxmls.exe URL Request Parsing Memory Corruption |
At this point of going down the rabbit hole there is a little hope! Those apparently correspond with a Citrix advisory designated CTX129430. But that advisory has been 404 for a while. Fortunately the Wayback Machine captured it and we can see there is no CVE assignment for it. Citrix became a CVE Numbering Authority (CNA) in April, 2022, yet did not go back and retroactively assign CVE IDs to older issues. The associated Citrix Hotfix (CTX129394) does not have a CVE ID attached either.
So we’re left wondering why Citrix removed that advisory, why there was no CVE ID assigned by Citrix, why F5 does not include any citations, why Fortinet does not include citations, why F5 did not seek to assign a CVE ID (a CNA since November, 2016 themselves), and why Fortinet did not seek to assign a CVE ID (a CNA since 2016 as well). This represents so many layers of failure as far as post-disclosure vulnerability coordination.
Jaws 2018
Remember above, the “2018 JAWS Web Server Vuln” listed in the report? Let’s go down a new rabbit hole and learn why this kind of designation is bad. Looking at the February 2023 report, rather than March, F5 refers to it as “the CVE-less 2018 JAWS digital video recorder vulnerability” and gives a footnote! They link to PentestPartner’s blog titled “Pwning CCTV cameras” which describes vulnerabilities in the MVPower 8 Channel Security DVR. We don’t know if the JAWS web server is exclusive to that brand or embedded software used by more devices. However, since 2016 the VulnDB team has not found reference to any other product being impacted.
That vulnerability was assigned CVE-2016-20016 on 2022-10-19, four months before the F5 report that cited it without a CVE ID. They also refer to the vulnerability by a web server header line rather than the product or vendor. Worse, F5 continues to refer to it as a 2018 Jaws vulnerability in a January 2024 report. Oh, this vulnerability was disclosed in 2016 and F5 knows this because they actually provided a citation, yet still refer to it as the “2018 Jaws” vulnerability. Again, this represents layers of failure in properly communicating vulnerability intelligence.
F5’s Persistent Problem
The two examples above are not outliers either. Instead they are representative of a systemic problem within F5 when communicating information. Using vague wording and informal nicknames for vulnerabilities doesn’t facilitate coordination in any manner. Diving in further and looking at a blog titled “Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in May 2019“, notice bullet two, sub-bullet three: “ECShop Remote Code Execution: The threat actor tries to upload a webshell on a vulnerable server.“
Since that is an executive summary at the top no problem, we can just search further into the analysis to find more information. Right? Right?! No, we cannot, as “ECShop” does not appear again anywhere. So we’re left with a KEV in ECShop with no additional information. There are at least five distinct remote code execution vulnerabilities in that software, disclosed between 2020 and 2023. This report is from May, 2019 meaning it is not any of those. I’m sure this is a valid vulnerability that has been disclosed somewhere, but outside the CVE ecosystem and outside the extensive sources that VulnDB tracks. Again, why doesn’t F5 provide citations here?
Just a month later, in “Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in June 2019” we find yet another example:
The final two campaigns, which are not discussed in detail here, are a SeaCMS search Remote Code Execution campaign -die MD5, and phpMyAdmin (PMA) configuration code injection.
Why aren’t they discussed? There are almost 50 SeaCMS remote code execution vulnerabilities and none of them are KEV at the time of this blog. That means for over six years F5 has been sitting on that information and not providing more details. The second they mention, phpMyAdmin “configuration code injection” is likely CVE-2010-3055 or CVE-2009-1285 based on the extremely limited information. Neither of those are currently known to be KEV though which means we can’t positively link them as there is no second source for corroboration.
Next we have “Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in April 2019” which has another vague reference:
Joomla Component JBcatalog—Arbitrary File Upload: The threat actor tried to create a back door by piecing together a PHP shellcode on the vulnerable server.
Based on this I am fairly sure this is VulnDB 184252, titled “JBcatalog Component for Joomla! com_jbcatalog/libraries/jsupload/server/php/ files[] Array Remote File Upload” which is known to be KEV as of 2019-05-14. If so, that means F5 detected exploitation at least a month earlier. However, when I originally processed this F5 article we had the KEV date set in 2025 and only updated it to 2019 after subsequent KEV digging. That still represents a scenario where F5 had it listed as KEV six years before others did.
The pattern continues in “Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in March 2019” where they talk about “two campaigns targeting WordPress installations with the vulnerable SiteGround SG Optimizer plugin“. No references are provided but that is CVE-2019-25217. Going back a bit further, in the “Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in February 2019” blog F5 refers to “the ThinkPHP Remote Code Execution vulnerability CVE-2018-10225“. Yay! They actually provide a CVE ID. We just have to ignore the fact it is an SQL injection (SQLi) flaw not remote code execution. I’m aware that some SQLi flaws can be leveraged for command or code execution. But the original disclosure did not mention it.
I’d show you that detail but it is 404 and none of the archive sites seemed to get a copy. That is why it is important to provide citations and to capture as much relevant detail as possible when aggregating and citing vulnerabilities. This also underscores the importance of using accurate language to describe vulnerabilities when a tracking ID (CVE or vendor) is not present.
Leave a Reply