Exploited Vulnerabilities Can Take Months to Make KEV List

On Oct. 10, the Cybersecurity and Infrastructure Security Agency (CISA) updated the Known Exploited Vulnerabilities (KEV) catalog with five known software flaws. At the top of the list: a use-after-free vulnerability in Adobe's Acrobat and Reader PDF-viewing applications that could allow code execution with the privileges of any user who clicked on a malicious file.

The only problem: Adobe disclosed the vulnerability 10 months before in January, an exploit developer published proof-of-concept (PoC) code on GitHub within a week, and a working exploit was added to a commercial exploit framework in June — again, almost 10 months before CISA added the information to the KEV.

While many security teams would have prioritized the patching of the vulnerability after the publication of the PoC, CISA's rigorous guidelines for inclusion in the KEV catalog often slow down its warning to federal agencies and organizations that have come to rely on the list, says Brian Martin, vulnerability historian at Flashpoint, a threat intelligence firm.

"This is like staring into the light of a train as it's barreling down the tracks toward you," Martin says. "Any sane person would [want to] jump at this point."

The flaw in Adobe's PDF-viewing products is not an isolated case. On Nov. 13, CISA released another update to the KEV catalog, including five issues in Juniper's EX and SRX series network appliances that could be chained together to compromise devices. The vulnerabilities had originally been disclosed publicly in mid-August, and security researchers at Shadowserver stated that they had detected "exploitation attempts from multiple IPs" using the vulnerabilities as early as Aug. 25.

Another long lead-time inclusion is the Veeam Backup & Replication flaw (CVE-2023-27532), disclosed in March and likely exploited later that month, but only added to the KEV list in August.

The timelines highlight that, while the KEV list is a great source of information about vulnerabilities that attackers are actively exploiting, organizations cannot rely on the list solely for their vulnerability management programs, says Caitlin Condon, head of vulnerability research at Rapid7.

"CISA KEV is often going to be a trailing indicator of exploitation in the wild," Condon says. "It's certainly a high-quality source of information, and it's very useful as one component in a risk-based vulnerability prioritization strategy, but we wouldn't recommend using KEV as your only source, or even your primary source, of data to support vulnerability prioritization."

'In the Wild' Is an Uncertain Game

One major problem facing CISA is the determination about whether a vulnerability is being used by attackers in the wild. Scanning for the vulnerability, active research on an exploit, and PoC code do not trigger the "in the wild" criteria, the agency stated on its requirements page.

"Making PoC publicly available can increase the likelihood of an attacker exploiting the vulnerability in the wild," CISA stated. "However, the public availability of a PoC does not automatically indicate the vulnerability has been or will be exploited. Having a publicly available PoC is not a requirement for a vulnerability to be included in the KEV catalog."

To include an attack in the KEV catalog, CISA requires a certain level of proof, says John Simpson, a senior security researcher at Veracode, a software security firm. Often, after someone publishes PoC code, exploit traffic will immediately increase as researchers and attackers attempt to use the code or scan for the vulnerability. The spike in traffic may not indicate any increased degree in risk because the PoC may not actually lead to exploitation, he says.

"You may see things like mass scanning activity that tests responses to the proof-of-concept to check for the existence of the vulnerability, [and] you may see unskilled attackers that don't necessarily understand the limitations of the PoC just trying it against a bunch of targets to see what happens," Simpson says. "It can still be a significant period of time before the remaining parts of the full exploit are actually sorted out by actors wanting to use them."

No Guidance, No KEV

Even if a vulnerability is being used in the wild, CISA may delay adding it to the KEV if there is no clear guidance for remediation, according to CISA's advisory on the KEV catalog.

In part, the requirement is due to how the federal government uses the KEV. Binding Operational Directive 22-01 requires every federal agency to remediate any vulnerability within two weeks, if that vulnerability has been or is being exploited by attackers. For that reason, every KEV entry comes with a due date by which the issue has to be fixed. Yet if there are no remediation steps — or even a solid workaround — CISA may refrain from issuing a KEV update, says Rapid7's Condon.

"One of CISA's explicit criteria for adding a vulnerability to KEV is that there needs to be a 'clear remediation action' available for that vulnerability — [for example,] a vendor-provided fix,'" she says, adding that may have been part of the reason for the delayed update for the vulnerabilities in Juniper devices. "To date, only one of the five CVEs in Juniper Networks' advisory looks to have a dedicated patch ... for the rest of the CVEs, the recommended action is [a] workaround, [which] may not have previously been enough to meet CISA's bar for a vendor-provided remediation."

CISA declined to comment for the article but referred readers to its guidance.

KEV's Place in Patch Priority

Given the delays, companies are advised — even by CISA — to not rely on the KEV catalog as the primary source of information on whether a vulnerability is being exploited. There are pros and cons to any particular patch prioritization technique, says Flashpoint's Martin. The KEV is a good source of exploitation data, but companies should look to other databases, such as FIRST's Exploit Prediction Scoring System, ransomware prediction models, Rapid7's AttackerKB, and Flashpoint's VulnDB exploit classification.

"The KEV is a solid reference point for prioritization, but it is a bit murky how it arrives at its information — hence why we’re here trying to figure out how this happened," he says. "That murkiness is by design because we are supposed to just trust it as an authoritative source, and yet there are errors in the KEV that are hard to rectify."

Even those other databases have their challenges, says Rapid7's Condon. While the company is relatively strict about asking for source material and citations in exploit reports, the sources are often very hard to verify.

"We've seen exploitation in the wild reported by security data vendors before, for example, only to find out later on down the line that the companies were talking about 'malicious scanning activity' rather than, say, confirmed payload delivery or execution that leads directly to follow-on attacker behavior," she says. "These nuances can be difficult for security practitioners to tease out, especially in a generally high-volume threat climate."