May 19: 3 New Vulns | CVE-2004-1464, CVE-2016-6415, CVE-2023-21492

In this CISA KEV Breakdown, three vulnerabilities (only one being disclosed this year) were added to the KEV catalog. Little information exists related to exploitation activity of CVE-2004-1464, but one wouldn’t find it too difficult to guess that a Telnet port vulnerability in Cisco IOS has been exploited in the past 19 years. Along with the two Cisco vulnerabilities comes a zero-day in Samsung Android.




Exploitation Consequence

GreyNoise Traffic

EPSS Score

EPSS Percentile

Due Date




Denial of Service







Information Disclosure






Android 11, 12, 13

Security Bypass




Notable Vulnerability Additions

CVE-2016-6415 | Cisco IOS, IOS XR, IOS XE Information Disclosure

A vulnerability exists in Multiple Cisco IOS products versions 4.3.x, 5.0.x, 5.1.x, and 5.2.x due to improper handling of IKEv1 packets processed by Cisco IOS. Cisco IOS XR Software releases 5.3.x and newer are not affected by this vulnerability. Upon exploitation, an attacker can remotely retrieve memory that can be parsed to extract sensitive data such as an RSA private key. Exploit code for the vulnerability has existed for quite some time, and Cisco has offered IPS signatures that can detect exploitation attempts, 7699-0, and Snort SIDs 40220(1), 40221(1), and 40222(1). The vulnerability can be considered difficult to exploit due to the fact that exploitation must occur only through IKEv1 traffic to a device configured for IKEv1.

This vulnerability exploit, dubbed BENIGNCERTAIN, was disclosed to Cisco publicly through a group of hackers known as the Shadow Brokers. This group managed to exfiltrate around 300Mb of exploits, malware kits, backdoors, and other hacking tools from Equation Group, which has been spoken about in the past by Kaspersky Labs as NSA-affiliated. When this leak occurred, Cisco was not the only major vendor scrambling to understand from these leaked exploits if their technology was part of any of the malicious code.

Security Advisory:

CVE-2023-21492 | Samsung Android 11, 12, 13 ASLR Bypass

A vulnerability in Samsung Android 11, 12, and 13 allows for an attacker to achieve an Address Space Layout Randomization (ASLR) bypass due to the fact that sensitive kernel pointers are stored to a log file on the device. These kernel pointers can allow the attacker to deduce the layout of system memory to locate critical kernel functions and target them with fine-tuned exploits. Bypassing ASLR happens due to the fact that the kernel pointers printed directly to the log file give the attacker far more information about the memory layout of the system than they should be able to ascertain due to the implementation of ASLR.

The vulnerability appears to have been disclosed as a zero-day privately to the vendor by Google’s Threat Analysis Group (TAG). Users can keep track of newly disclosed zero-days through the use of TAG’s 0-day spreadsheet tracker. Read more about TAG’s mission and the purpose for the spreadsheet here.

Security Advisory:

← May 12, 2023 CISA Kev Breakdown

Click here to expand our CISA KEV Breakdown Frequently Asked Questions
  • What makes for a notable addition?
    • A notable addition can arise from many different characteristics. If a particular vulnerability is notable to the security community or a subset of the security community or if the EPSS score reveals notable information about the vulnerability, this can constitute further analysis. It may also be the case that a particular vulnerability shines a light on everyday users and we will highlight important information and key takeaways to ensure users and readers have easy access to actionable information.
  • When is the Breakdown released?
    • We aim to have our analysis of each KEV update posted within 24 hours of the time in which the Catalog is updated. See CISA’s full catalog here
  • I am not bound by BOD 22-01 or federal regulations, why should the KEV concern me?
    • CISA encourages all organizations to utilize the Catalog as an attribute in your vulnerability prioritization framework. Organizations looking to lessen the scope on known dangerous vulnerabilities and make a goal to remediate them can understand where they currently stand against what CISA has confirmed as exploited vulnerabilities in the wild. See CISA’s section on “How should organizations use the KEV catalog?” here.
  • What is EPSS?
    • EPSS is the Exploit Prediction Scoring System. It is an open, data-driven effort for estimating the likelihood (probability) that a software vulnerability will be exploited in the wild. See the EPSS home page on FIRST for more information here.
  • What is the difference between EPSS probability and EPSS percent?
    • EPSS probability is the risk calculated by the model when determining the perceived threat of the vulnerability itself. Percentage is a relative comparison of the rest of the CVEs within the given sample. While the probability only changes upon refreshing the results from the model, the percentage can change purely based on the CVE sample given. In the case of the Breakdown, we use the percentage given by the pool of all CVEs with given EPSS data. Scores may vary post-release of the post given new information about the vulnerabilities and their perceived threat. For more information on applying and understanding EPSS data, see this article on the FIRST website, as well as their FAQ page.
  • What is GreyNoise?
    • GreyNoise is a platform that collects, analyzes, and labels data on IPs that scan the internet and saturate security tools with noise. Through their sensor network, GreyNoise observes vulnerability exploitation attempts for vulnerabilities that are exploited in the wild over the Internet. These are arguably vulnerabilities that should be at the very top of your priority list to remediate.
  • Why are GreyNoise exploitation attempts only observed on ~20% of KEV vulnerabilities?
    • Exploitation of many vulnerabilities in the CISA KEV will not be observed for many reasons that GreyNoise does a good job of explaining in this post. For example:
      • The vulnerability may not be remotely exploitable
      • Vulnerability exploitation may require authentication (and result in privilege escalation)
      • The impacted software may not be exposed to the internet
      • Mass scanning/exploitation is not occurring yet