CVE-2024-20294
Cisco Nx-Os 10.1\(1\) … 9.3\(9\)
Raw vector
CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:N/I:N/A:HCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2024-20294 is a medium-severity Buffer Access with Incorrect Length Value (CWE-805) vulnerability in Cisco Nx-Os. Its CVSS base score is 6.6 (Medium).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked at the 23th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-8 (Security and Privacy Engineering Principles) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-18009
Vulnerability Data
A vulnerability in the Link Layer Discovery Protocol (LLDP) feature of Cisco FXOS Software and Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to cause a denial of service (DoS) condition on an affected device. This vulnerability is due…
more
to improper handling of specific fields in an LLDP frame. An attacker could exploit this vulnerability by sending a crafted LLDP packet to an interface of an affected device and having an authenticated user retrieve LLDP statistics from the affected device through CLI show commands or Simple Network Management Protocol (SNMP) requests. A successful exploit could allow the attacker to cause the LLDP service to crash and stop running on the affected device. In certain situations, the LLDP crash may result in a reload of the affected device. Note: LLDP is a Layer 2 link protocol. To exploit this vulnerability, an attacker would need to be directly connected to an interface of an affected device, either physically or logically (for example, through a Layer 2 Tunnel configured to transport the LLDP protocol).
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.4.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation (including fuzzing and static analysis) directly finds incorrect length values used in sequential buffer accesses.
Secure engineering principles require explicit bounds checking and correct length calculations when performing buffer operations.
Input validation rejects or corrects malformed length values supplied from external sources before they reach buffer operations.
Memory protection mechanisms limit the blast radius when an incorrect length value causes an out-of-bounds access.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
A.8.25 mandates secure SDLC practices including secure coding guidelines, security requirements, checkpoints, testing (scans/penetration), and developer training that reach buffer-length issues in custom code, but leaves a bounded remainder (e.g. third-party libraries, legacy code, incomplete enforcement of guidelines, or outsourced development without full assurance).
Application security requirements can specify buffer-size validation, but do not prescribe implementation details.
A.8.27 mandates security-by-design, defence-in-depth, least privilege, distrust-external-input, hardening, and design reviews against known attack patterns; these reach a minority slice of CWE-805 (e.g. safe API selection or bounds-aware length computation) but leave most buffer-length errors still introducible and exploitable in the remaining implementation surface.
Secure coding explicitly requires correct buffer-length handling, eliminating CWE-805 when followed.