CVE Numbering Authority VulDB Falsely Claimed That 800,000+ Install WordPress Plugin Contained Vulnerability
Yesterday, a topic was created on the WordPress Support Forum about a claimed vulnerability in the WordPress plugin The Events Calendar with the message:
VulDB published an advisory concerning a vulnerability in The Events Calendar plugin, at https://vuldb.com/?id.212632.
Do you have a statement about this vulnerability?
That topic was then deleted by one of the moderators of the forum with this curious explanation:
Moderator note: As that link contains a link to the exploit itself, it’s been removed. You can ask the devs about the CVE, with a link to that, but please check the links to make sure it’s not linking to an exploit.
The deletion of that topic runs against WordPress’ new stated policy for the handling of discussing vulnerabilities. But is in line with the mess that is their moderation of that forum, where you can’t follow their rules, since they put forward for policies and then don’t follow them.
It also doesn’t follow that the topic needed to be deleted because of a link. The link could have simply been removed by the moderator or replaced.
“Exploit”
Among the issues with the explanation given for the deletion, the CVE entry they were referring to contained the “exploit” link as well. So they are saying not link to something because it links to an “exploit”, but also it is okay to link to something that also links to the “exploit”. It appears the only difference is that what was linked to contained the word “exploit”. Things get even more confusing, as the CVE entry also linked to the page that they deleted the topic over linking to.
Here is the “exploit”:
All that shows is JavaScript code being entered in to the title of a WordPress custom post. It is hard to understand what the risk is from linking to something that links to that is supposed to be.
What that image does show is that there isn’t a vulnerability in the plugin. What can be entered in to the title of a WordPress custom post is controlled by WordPress. Higher-level WordPress users are explicitly allowed to enter JavaScript code into the title like that. Lower-level users wouldn’t be able to do that.
Based on the menu items show on the left-hand side of the screenshot, the screenshot was taken by someone logged in as an Administrator, so what was being done is allowed.
CVE Entry
The CVE system is described as a system to “identify, define, and catalog publicly disclosed cybersecurity vulnerabilities” and it is “sponsored by the U.S. Department of Homeland Security (DHS) Cybersecurity and Infrastructure Security Agency (CISA)“. They allow what they refer to as CVE Numbering Authorities (CNAs) to submit CVE entries into their system without doing any vetting of the entries. In this case, the CVE entry, CVE-2022-3796, was submitted by VulDB, which markets itself as the “Number one vulnerability management and threat intelligence platform documenting and explaining vulnerabilities since 1970.”.
VulDB described the claimed vulnerability this way:
A vulnerability was found in Events Calendar Plugin. It has been declared as problematic. This vulnerability affects unknown code of the file post.php of the component Event Handler. The manipulation of the argument title/body leads to cross site scripting. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-212632.
We are not sure what some of that is supposed to mean. For example, are there vulnerabilities that are declared as not problematic? Also, they don’t say who declared it problematic.
The only additional information provided was a link to VulDB’s page, which didn’t provide any additional information, and links to two images. One that we included above and this additional image, which shows the result of saving a page with the JavaScript code shown in the other image.
VulDB’s Lack of Due Diligence
After running across this, we contacted VulDB to let them know this is a false report. The response wasn’t great. They were asking us to confirm things they should have already confirmed and also thought it too much to expect that they would have vetted the claim before falsely claiming that a piece of software with 800,000+ installs contained a vulnerability.
Also, there was no indication in their information that there had been attempt to notify the developer of the claim before they published the claim.
They did mark this as a false positive after and the CVE entry is now listed as being a “reject”.
Where is CVE’s Vetting?
We are not aware of VulDB having expertise when it comes to vulnerabilities in WordPress plugins, which lines up with them not understanding there wasn’t a vulnerability here. And yet, CVE is allowing them to claim there are vulnerabilities in those without vetting the claims first.
This is far from the first CNA we have run across that has issued a false report of a vulnerability in a WordPress plugin and that isn’t the only problem when it comes to them and claimed WordPress plugin vulnerabilities.