Some time ago, perhaps last year or two years ago during VulnCon, I made an offhand comment about Cybersecurity and Infrastructure Security Agency’s (CISA) Known Exploited Vulnerability (KEV) catalog and how there were more than one vulnerability that had appeared in it and were subsequently removed. I received doubt from someone (Tod Beardsley?) that didn’t think it had happened at all. I immediately told them it happened once for sure because I had reported one that was removed.
Before I continue it is important to be clear in how the CISA KEV works. I blogged about this in 2024 after Tod Beardsley gave a talk at VulnCon that year where he explained a lot of the inner workings of their processes. The cliff notes is that the process was described as rigorous and “that 70 or 80 people may see parts or all of the evidence before it reaches the KEV“. Given that the vulnerability listed that I prompted to be removed was simply a typo in a CVE ID, that is evidence that the process described was not accurate, or had broken down within six months.
Since then I have made notes as I ran into cases of a vulnerability being removed from CISA’s KEV to show that it is not a one-off situation with the one I reported. That said, this is not to judge CISA’s staff or criticize their policies. The world of vulnerability aggregation in any context is fraught with errors. Transposing a single number can have big implications if tracking an ID, be it CVE, VulnDB, Exploit-DB, or any other.
The purpose of this blog is just to make people aware that the presence of a CVE on CISA’s KEV does not mean it is 100% definitively being exploited and reminds us all that a dose of skepticism is warranted. Trust, but verify. For example, Greynoise has done an independent evaluation of CISA around flagging vulnerabilities as being used in ransomware attacks, and they too have seen silent updates and changes in that capacity. These too come without explanation or warning.
CVEs Removed from CISA KEV
CVE-2022-28958
This was originally reported as being exploited by threat actors as of 2022-09-05, by CISA via their Known Exploited Vulnerabilities (KEV) catalog. However, a subsequent examination of this disclosure and exploit (CVE-2022-28958) by Jacob Baines has demonstrated this disclosure is entirely incorrect. In addition to the proof-of-concept originally published targeting a different endpoint than the one claimed vulnerable, Baines has evaluated the shareport.php endpoint more thoroughly and cannot find evidence it is vulnerable in the stated way. As such, this entry has been marked Myth/Fake. On 2023-12-01, CISA removed this vulnerability from the KEV. Note that vendors like Avast claim this is being used in attacks by a Mirai botnet variant (MooBot), but given the prior research, it is likely an erroneous conclusion.
CVE-2021-4043
As mentioned in the introduction, I called out the inclusion of CVE-2021-4043 in CISA’s KEV after considering the vulnerability versus impact and likelihood of exploitation. The error stemmed from a report by Aquasec in which they said malware was attempting to “exploit the Polkit vulnerability (CVE-2021-4043) to escalate privileges.” However, that was a simple typo and they meant CVE-2021-4034 instead, which is “polkit pkexec Utility Improper Calling Parameter Count Handling Local Privilege Escalation (PwnKit)“.
While this was a typo that led to inclusion it really begs the question of how rigorous the standards are for inclusion. Beardsley had said as many as 80 people were involved before a vulnerability was added. Did up to 80 people miss this obvious typo, or did staffing and budget cuts force them to compromise their methodology and standards?
CVE-2019-1428
As part of our daily routine at VulnDB, we monitor CISA’s KEV among hundreds of other sources for information on vulnerabilities being exploited. On 2021-11-04 at 10:02a MDT we flagged VulnDB 217489 as KEV based on it appearing in CISA’s KEV. Something prompted us to look again on 2021-11-04 and we observed it was no longer present. Originally, this Reg article said it was being exploited in the wild as well, but archival sites did not capture a copy at the time. My best guess is this was another one-off number transposition as CVE-2019-1429 is known to be exploited in the wild.
CVE-2020-0711
This CVE ID was added to CISA’s KEV on or around 2021-11-04. During a subsequent audit of Flashpoint’s KEV data it was noted that the CVE no longer appears on the CISA KEV. I reached out to CISA on 2024-07-15 asking for clarification. On 2024-07-31 CISA’s ticketing system indicated ticket INC000010518690 had been closed as “SIM resolved ticket” without replying to me. On 2024-08-22 I replied again saying the ticket had been closed without resolution and received no reply, prompting me to reach out yet again on 2025-01-31. No replies from human or ticketing system happened after that.
CVE-2022-31463
On 2023-09-18 CISA posted a blog about the addition of eight vulnerabilities to their KEV, including CVE-2022-31463, which is still live at the time of this blog. However, during a subsequent audit of Flashpoint KEV data, we observed it was no longer on their KEV. No explanation has been offered that we have seen.
CVE-2024-43491
As of 2024-09-13, CISA had added this vulnerability to their KEV but subsequently removed it. Microsoft confirmed to Flashpoint on 2025-02-03 “no exploitation of CVE-2024-43491 itself has been detected. In addition, the Windows product team at Microsoft discovered this issue, and we have seen no evidence that it is publicly known.” After the inclusion in CISA’s KEV, many outlets picked up on it and reported including NHS.uk, SecurityWeek, Tripwire, Dark Reading, Akamai, and more.
So where does this confusion come from? Microsoft’s advisory! Under the Exploitability section it says “Exploitation Detected” for the “Exploitability assessment” heading. However, read further and look at the third question of the FAQ it says (bolding my emphasis):
This CVE documents the rollback of fixes that addressed vulnerabilities which affected some Optional Components for Windows 10 (version 1507). Some of these CVEs were known to be exploited, but no exploitation of CVE-2024-43491 itself has been detected.
And Then It Gets Weirder
Honestly, I don’t even remember what led me down this rabbit hole past the first instance. I had run across an AttackerKB article that flagged a vulnerability as KEV and cited the source as “Government or Industry Alert” with a link to CISA’s KEV. It was flagged on 2022-08-23 yet when I looked on 2025-08-23 it was not present. This happened again on AttackerKB with CVE-2022-37393, CVE-2021-26419, CVE-2020-17008, CVE-2020-25592, CVE-2020-2034, and CVE-2020-8794. There may be more but those are the ones I ran across at the time. In each case those entries were updated by “gwillcox-r7” (Grant Willcox) and each one listed the source of the information the same; CISA’s KEV.
I reached out to Grant to ask him about the discrepancies and he replied on 2025-08-26. Specifically, I asked if there might have been automation at play that misfired or something else that led to simple mistakes. He replies that they were “all checked manually, we don’t have any automation that I’m aware of that is currently hooked up to that site.” That means that like me, Grant witnessed vulnerabilities listed in CISA’s KEV that were subsequently removed without explanation.
Note that CVE-2022-37393 is known to be KEV, but it still is not listed on CISA’s catalog.
CISA Replies
On 2025-09-02 I reached out to CISA because I noticed an odd discrepancy in the CISA KEV total that displays e.g. “Showing 1 – 20 of 1631”. Every week I track that number along with the totals of other KEVs. That week CISA’s total dropped by one rather than increasing by one or more. I also cited three of the examples above from AttackerKB and questioned if it might be “a bug, so to speak, with the code or processes at CISA?” That same day I received a reply the CISA Joint Cyber Defense Collaborative (JCDC):
At this time, we can confirm that no CVEs have been removed from the KEV catalog recently. The last removal was CVE-2025-4664 in early June 2025, and there have been no further removals since then.
Well that’s interesting! Not only did they confirm no vulnerabilities had been removed “recently”, they provided yet another that had been last year. Ironically, that vulnerability has been known to be KEV since 2022-08-26. Regardless, that means something is definitely going on with CISA and their stewardship of their KEV catalog. In an effort to figure this out, eventually, I have filed a Freedom of Information Act (FOIA) request with CISA asking for relevant documentation for nine of these vulnerabilities.
Based on my prior requests and the filing dates along with me still waiting for a response, I am not holding my breath.
What Can We Do
As the end users of CISA’s KEV, there isn’t much we can do in some regards. The InfoSec community can stay diligent and continue to audit our data. That is what surfaced some of the examples above as Flashpoint will do audits of VulnDB from time to time. The biggest thing we can do is the proverbial “if you see something, say something”. Write a blog, LinkedIn post, or other social media post and tag CISA. Ask the question of why it was removed.
CISA is of course in a much better position to change in a way that would help remove this problem completely. If a CVE is added to their KEV and subsequently removed, it needs to remain searchable and carry an explanation as to when it was added, when it was removed, and why it was removed. Its presence there should not influence the overall total of vulnerabilities listed either. This is a fairly easy ask and reasonable for CISA to do.
Leave a Reply