What’s Your Story CVE-2015-2551?
This CVE-2015-2551 entry seems straight-forward, based on the description provided by CVE or NVD. Looking at the change history on NVD it is a bit more informative:
- CVE Rejected by MITRE 5/11/2017 10:21:04 AM
- CVE Source Update by Microsoft Corporation 11/06/2023 9:25:22 PM
- They updated it to reflect they were the source, or assigning CNA.
- CVE Modified by Microsoft Corporation 11/06/2023 9:25:22 PM
- They updated the description to be nearly identical, providing no real change.
So the ID was created for the 2015 calendar year, apparently not used, rejected seven years later, and confirmed by the assigning CNA (Microsoft). OK, we’re good, no reason to worry about this CVE ID. But wait! In the Securin 2023 Ransomware Report (registration required), where I first caught mention of this, they call out two CVE IDs, including this one, that are REJECTED yet associated with ransomware. It is also important to note that the report in question isn’t specifically the Securin report, rather, it is branded by four different companies. Those include Securin, Cyber SecurityWorks, Ivanti, and Cyware (hereafter referred to as `Securin’).
According to them, that vulnerability is associated with a whopping 17 ransomware gangs while citing no information available in NVD. OK, so what’s the provenance of that information if not from CVE, NVD, or Microsoft? This is a case where by all reasoning, that ID should not be associated with a vulnerability unless a CNA went rogue and assigned an ID from another CNA’s pool. To the best of my knowledge, that has never happened. That’s also the kind of thing that I, or someone on the VulnDB team would very likely notice and raise a warning flag over.
So what happened? On occasion I have been trying to sort this out over the past few years and the tl;dr is, I still have no idea. While Microsoft made me pull teeth to get a basic answer, they essentially confirmed they do not have knowledge of a vulnerability associated with that ID (communication timeline at end of blog). Securin, and several other security companies that make the ransomware claim, did not reply to repeated attempts to clarify. A total skeptic might call ‘bullshit’ at this point. As a mostly++ skeptic, this blog is my final attempt to get them to set the record straight.
As a point of reference, I have been maintaining a vulnerability database in one form or another since 1993. While not in a formal effort like CISA’s KEV, I have been tracking exploitation of vulnerabilities for well over a decade. The amount of sources I have monitored including formal reports, blogs, mail lists, changelogs, commit histories, and a lot more is borderline absurd. I was on the CVE Editorial Board for a decade and know the CVE ecosystem very well. When multiple companies claim that a rejected CVE is being used by more than a dozen ransomware groups and I cannot find provenance for the basic vulnerability information, it sets off red alarms.
Consider this; as of this blog a Google search has literally 13 hits for this CVE with one being a non-vulnerability identifier used in Spain, two being the same potential exploitation provenance blog, one for a second potential exploitation provenance blog, five being CVE/NVD or related ‘rejected’ entries, three being the reports in question, and one being a news article regurgitating the reports. That means today, there are literally two sources that are earlier provenance for exploitation and zero sources for provenance of the vulnerability itself.
CVE-2015-2551 Exploited Timeline
We know the details about the actual CVE assignment in the brief timeline above. Several Securin Ransomware reports as early as 2022 mention this vulnerability as being actively exploited and their 2023 report is where I first caught wind of it. The reports were published when the CVE site would have said REJECTED, but NVD would not have shown that the assigning CNA Microsoft confirmed the status of it. That means that four companies have signed off on this claim of CVE-2015-2551 being used in ransomware attacks by one or more groups. This absolutely should not be a case of a CVE typo since a minimum of four people should have had eyes on this report, if not over a dozen as they go through edit cycles.
Stepping back a bit, as I began to try to find provenance for the actual vulnerability details, I saw that the 2022 Securin report provoked a more severe “what the…” reaction. Labeled the “2022 Index Update Q2-Q3 Ransomware report”, the PDF was created 2022/10/19 and says:
An interesting thing that we noted from this investigation was how ransomware operators wereexploiting the NVD-rejected vulnerabilities. CVE-2019-9081, a vulnerability in the Laravel framework, and CVE-2015-2551 (product details not available) make perfect examples. CVE-2019-9081 is exploited by Satan and Mailto ransomware families, and CVE-2015-2551 by several ransomware families.
How did any of these companies deduce the exploited vulnerability was used to carry out a ransomware attack and associated it with CVE-2015-2551 if they don’t even know the product affected? This certainly doesn’t make a “perfect example” of their point to me. I took to Twitter on February 23, 2023, to ask three of the companies, as I couldn’t find Securin at the time if I recall. Not surprisingly, the companies did not reply so no additional clarity was to be had there.
Instead, Oliver Sild from Patchstack pointed to a McAfee page that said the CVE was associated with Oracle Java. From McAfee’s “Threat Landscape Dashboard” at the time, they had “Remote code execution flaw in Oracle java” and associated it with the Nuclear Exploit and Angler Exploit Kits (EKs). Their page showed a modified date of June 12, 2018, but we don’t know when it was published. Obviously we know that to be incorrect now as the CVE belongs to the Microsoft CNA.
As always, we want to go to the Single Source of Truth (SSoT) of a vulnerability, meaning an original disclosure. Digging farther back I found a November 1, 2017 reference in a blog by “Arman Dathe Pouyan, official representative of Kaspersky products in Iran”, so the provenance here is presumably Kaspersky. In it, Pouyan ties the CVE to the Neutrino exploit kit and a link to NVD which has no information. That means that at least three exploit kits supposedly use it, yet the CVE isn’t published as of that time. Finally, the first reference I could find goes back December 21, 2015, where the CVE is mentioned in the MDNC: Malware Don’t Need Coffee blog. The post, titled “XXX is Angler EK“, doesn’t offer much information as the widget that displayed information doesn’t render currently.
Based on the limited information I can glean, the widget would have included some payload that could have proven useful. This is probably the first public evidence of exploitation and it too attributes the issue to Java. That means this blog likely influenced McAfee, and the original confusion over the affected vendor starts here. The caption reads “Angler EK “indexm” exploiting CVE-2015-2551 and firing Java exploits [Payload here is most probably Lurk]“
In summary, we have a 2015 CVE ID that belongs to Microsoft, once attributed to Oracle Java by two entities, and subsequently mentioned w/o reference to vendor or exploit by four companies. Securin goes back to 2021 where they promote the ‘fact’ that CVE-2015-2551 is being used in ransomware attacks. In 2022, Ireo published a report associating the CVE ID with 17 ransomware groups (TorrentLocker, Crypshed, Reveton, NanoLocker, Locky, Kovter, JuicyLemon, CTB-Locker, Waltrix, Crypwall, Crypfort, CryptoMix, CrypBoss, Cerber, Better_call_saul, Cryptesla, Cryptohasyou). That means that at least six companies claim (Securin, Cyber SecurityWorks, Ivanti, Cyware, Kaspersky, McAfee) to have knowledge of this vulnerability and not one has submitted samples or information to the vendor. This is in the middle of an era of “coordinated” disclosure. Not to mention all of the ransomware groups that apparently share knowledge of this vulnerability, while threat intelligence firms don’t appear to have seen any chatter about it.
For the four companies that put their brand on these ransomware reports, either submit samples to Microsoft so they can analyze, verify, and/or fix the vulnerability as needed, or disclaim in your reports that you are part of the problem. When Microsoft is the assigning CNA and has no knowledge of that ID being used, you are almost certainly wrong. It means your entire report and all the claims of vulnerabilities being exploited are now a bit less trustworthy. It means that when people reference you, that too should come with a disclaimer that your information is not reliable and requires a second source to validate.
What’s Your Story CVE-2019-9081?
As a bonus, there is a second CVE ID that is more confusing that also appears in these reports. CVE-2019-9081 is associated with a vulnerability in the Laravel Framework. Looking at the NVD history for this CVE, we see that NVD analyzed the issue on 2/26/2019 and MITRE subsequently rejected it on 8/19/2022 saying it “was withdrawn by its CNA. Further investigation showed that it was not a security issue.” That rejection happened three years, five months, and 25 days after NVD analysis. So, is it a vulnerability or not? One of the analysts for VulnDB working on ID 199528 dug into this back then observing and concluding:
In a provided demo application, the researcher implements a TaskController class that invokes ‘unserialize()’ with user-supplied input. Generally, untrusted input should never be passed to the ‘unserialize()’ function, as it has obvious code execution potential. A cursory review of the translated advisory suggests that the researcher developed a POP chain / gadget chain using the ‘__destruct()’ method of the ‘PendingCommand’ class that allows code execution. However, the root cause is the insecure usage of the ‘unserialize()’ function in the demo application. As this issue, by itself, is not exploitable without a vulnerable application using the framework, it is not classified as a vulnerability.
This makes it interesting since the Laravel Framework is a third-party library essentially, and if someone were to implement it against recommended usage and opted to pass unsanitized input to the unserialize() function, their app could be vulnerable. This begs the question if developers would do this often enough, in Internet-facing applications, to open up the risk of such ransomware infections and in cases where these companies would detect it. All it takes is one such company and one ransomware incident to be called out like this, so it is fair game. Personally, I am dubious of Securin et al after the prior CVE in this blog. However, I would give them benefit of the doubt if for no other reason than the sake of this hypothetical.
An interesting thing that we noted from this investigation was how ransomware operators were
exploiting the NVD-rejected vulnerabilities. CVE-2019-9081, a vulnerability in the Laravel framework, and CVE-2015-2551 (product details not available) make perfect examples. CVE-2019-9081 is exploited by Satan and Mailto ransomware families, and CVE-2015-2551 by several ransomware Families. — Securin – Ransomware Report Index Update 2022 Q2-Q3
And again:
CVE-2019-9081 is yet another ‘Reject’ vulnerability that is associated with two ransomware gangs, Mailto and Satan. There is no information about severity ratings or products for this vulnerability though we have been able to verify that this CVE was assigned to a Laravel framework product and was later withdrawn because it is not a security issue anymore (as per the message posted in the NVD). As of December 05, 2022, we found this CVE trending in the
deep and dark web, which indicates hackers’ interest in it. It is these kinds of drawbacks that adversaries love to exploit, especially when repositories—like the NVD—have no information to offer. — Securin – 2023 Ransomware Report
So, the hypothetical is straight-forward; Even if the developers document not to use the unserialize() function and someone does, leading to a compromise, should the CVE ID be rejected? It’s clear there would be potential for this to be a real scenario and companies need to be aware of it. Even with a low CVSS score it would at least be searchable and referenced if needed. It would be more prone to show up in static code analyzers and other processes that may help avoid the use of it.
Rather than REJECT, this is a prime example of one that should stay in DISPUTED status. Otherwise, we end up with this scenario where it appears REJECTed and no information is available, while also allegedly being targeted in ransomware attacks. The fact that Securin et al didn’t do some level of analysis on the vulnerability/weakness and outlined it like VulnDB does means we simply do not know, again. That’s twice in one report that these four companies have actually caused more hassle than benefit. Further, to some in the industry, it is unprofessional and leads to questioning their technical ability and integrity. Food for thought.
CVE-2015-2551 Timeline
2017/05/11 – CVE is rejected by MITRE at 10:21:04am
2023/02/14 – The Securin Ransomware report is created
2023/04/02 – mail out to MSRC, ID belongs in their CNA pool, Case 78746 CRM:0305016980
2023/05/01 – “We have completed our investigation and determined that this report is not able to be reproduced by our engineers. We have not been able to reproduce the vulnerability reported in CVE-2015-2551 when tested on a current version of Windows. If you confirmed a bypass of that CVE and exploitation on a current version of Windows, please submit a new report at https://msrc.microsoft.com/create-report, as this case is being closed.” huh?!
2023/05/01 – I reply “Can you confirm *what* CVE-2015-2551 represents? It is currently being reported as used in ransomware attacks, yet it is in REJECT status in CVE. We cannot find any details regarding the nature of the vulnerability, an associated MSKB, etc.“
2023/05/01 – MSRC cites NVD and it not being valid *sigh*
2023/05/01 – I reply
2023/05/31 – pinged MSRC, follow-up “due to the potential severity and active exploitation“
2023/05/31 – “As noted in our previous message we are unable to proceed with investigating your report as submitted. To help us gather the information we need to assess a vulnerability please refer to the information below: …”
2023/05/31 – I reply “but you are the assigning CNA in this case. Presumably you already have all of the details on your side but never issued an advisory. Is that not the case?“
2023/06/02 – MSRC tells me to refer to CVE which says REJECTED
2023/06/02 – I give a mini-lesson on CVE and that status does not mean much when dozens of entries are in that state, yet valid vulns. I go on: “That is why I am emailing the CNA that assigned this to find out -why- it was rejected, versus why half a dozen companies are attributing that CVE to an unspecified Microsoft vulnerability being used in so many ransomware cases. One of you is wrong, and I don’t care which it is =) I just want to find clarity on this vulnerability. Because if all those companies are wrong, they might be using a bad CVE ID, but referring to a legitimate vulnerability in your products that you aren’t aware of. So one way or another it is beneficial for MSRC to clear this up 100%.“
2023/06/05 – MSRC tells me to check with the people claiming it was exploited and encourage them to submit a sample to MSRC
2023/06/05 – I reply: “I will do my best but all of the companies citing it have ignored my attempts to contact them so far.“
2023/11/06 – CVE updated by Microsoft, reflecting they were the source and/or assigning CNA
Additional Information
Google search for CVE-2015-2551, showing only two pages returned.
[4/15/2025 Update: A colleague pointed out this commit from ‘Zeron’ that is interesting. It specifies that while rejected, this was related to the Windows Print Spooler. That would match this being a Microsoft-assigned ID. While MSRC explicitly told me they had no record of this ID being associated with a vulnerability, it makes me wonder if it originally was, then determined not to be a vulnerability. This has happened in the past, where a vendor says “not a vulnerability” (NAV) despite the issue being exploitable in some fashion.]