Another Instance of CVE’s CNA Mess Leading to Multiple CVE Records for One Vulnerability
The About page for the CVE program starts with a claim that the program creates one CVE Record for each vulnerability:
The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog.
In November, we noted an example where one of their CVE Numbering Authority (CNA) partners, Automattic’s WPScan, had created two CVE Records for one vulnerability in part because they fail to verify information about vulnerabilities, despite claiming to do that. That follows another post in March of last year noting another instance where they did the same thing. That is one of many problems with the information being adding to CVE through the CNA partners. Not only is CVE not even trying to address the many problems with that, but they simply refuse to even respond when contact about problems with that. A number of those problems can be seen in another instance of a duplicate CVE Record that we recently just reviewed.
The aforementioned CNA, WPScan, has a listing for a reflected cross-site scripting (SSS) vulnerability in the WordPress plugin Amelia. Considering that WPScan often doesn’t verify the information in their listings or even test their own proof of concepts, you need to independently check any claims they make, unless you want to leave your website open to being hacked. You can’t do checking based on the information included in that listing. The only information they is this general description of that type of vulnerability:
The plugin does not sanitise and escape the code parameter before outputting it back in a page, leading to a Reflected Cross-Site Scripting which could be used against high privilege users such as admin.
They provide three references, two of which are CVE Records:
References
CVE CVE-2023-27918
CVE CVE-2023-29427
Missing CVE Record Details
Both of the CVE Records are missing any information, and claim that the information will be provided when the vulnerability is publicized:
** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided.
The third reference is connected with the CVE-2023-27918 and the linked page from the CNA JPCERT/CC is stated to have been published on April 24. So it has been a 11 days and yet the details haven’t been provided.
Curiously, nowhere in WPScan’s information is there anything to explain why the other CVE Record is linked to. The explanation for that is that WPScan frequently refuses to credit competitor of theirs, which is what happened here. As the CVE Record is claimed to have been issued by a competitors of theirs, Patchstack. WPScan doesn’t link to that, despite referencing the CVE Record, which they could only know is connected with this from the information that had been published on Patchstack’s website. On Patchstack’s page, it is stated to have been published on April 6. So it has been nearly a month and yet the details haven’t been provided.
The rules for CNAs states that it is against those rules if the CNAs are “not populating a CVE Record in a timely manner”. Timely isn’t defined in the rules, but the message we quoted above suggests that timely would be once the vulnerability is publicized. We reached out to CVE about these records being made available in a timely maner in January. We specifically asked what timely means. Instead of getting an answer, we were told that “we’ll discuss your feedback internally regarding timeliness”.
The Same Vulnerability?
As the CVE Records are empty, no one can tell from them if they refer to the same vulnerability. The listing on the two CNA Records doesn’t shed any more light on this, as they both only include general descriptions of a type of vulnerability. So there is no way to check on their claims. The best we can do is to look at the changes made in the version of the plugin they claim fixes this, 1.0.76.
In looking at the changes made in that version, we found only one change that seems like it could match either of the claims of a vulnerability. In the file /view/backend/view-new.php, line 4 was changed. That previously was this:
4 | $code = $_GET['code']; |
That sets the value of the URL parameter “code” to the variable $code.
An escaping function was added to that in the new version
4 | $code = esc_attr($_GET['code']); |
The variable is then output with this code:
The correct escaping function for that situation esc_js() instead of esc_attr().
So it would appear that this is another instance of a duplicate CVE Record.