Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/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-20330 is a high-severity Access of Memory Location After End of Buffer (CWE-788) vulnerability in Cisco Secure Firewall Threat Defense. Its CVSS base score is 8.6 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked in the top 49% of CVEs by exploit likelihood; 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-18045
Vulnerability Data
A vulnerability in the Snort 2 and Snort 3 TCP and UDP detection engine of Cisco Firepower Threat Defense (FTD) Software for Cisco Firepower 2100 Series Appliances could allow an unauthenticated, remote attacker to cause memory corruption, which could cause…
more
the Snort detection engine to restart unexpectedly. This vulnerability is due to improper memory management when the Snort detection engine processes specific TCP or UDP packets. An attacker could exploit this vulnerability by sending crafted TCP or UDP packets through a device that is inspecting traffic using the Snort detection engine. A successful exploit could allow the attacker to restart the Snort detection engine repeatedly, which could cause a denial of service (DoS) condition. The DoS condition impacts only the traffic through the device that is examined by the Snort detection engine. The device can still be managed over the network. Note: Once a memory block is corrupted, it cannot be cleared until the Cisco Firepower 2100 Series Appliance is manually reloaded. This means that the Snort detection engine could crash repeatedly, causing traffic that is processed by the Snort detection engine to be dropped until the device is manually reloaded.
- 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 can discover buffer-end violations through static analysis, fuzzing, or dynamic bounds checks.
Security engineering principles require bounds checking, safe arithmetic, and language choices that structurally eliminate post-end buffer accesses.
Input validation enforces bounds on lengths and indices before buffer operations, stopping out-of-bounds accesses after the end of the buffer.
Memory protection mechanisms limit the effects of post-end buffer accesses by blocking unauthorized code execution or data corruption.
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.
Secure SDLC practices directly require bounds checking and input validation that prevent out-of-bounds buffer accesses.
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 (secure coding guidelines, security requirements, checkpoints, testing including code scans and penetration tests, developer training) that reach buffer management and can stop many out-of-bounds accesses from reaching production, but leaves a bounded remainder (e.g. defects that slip past imperfect testing, non-software systems, or outsourced development without full assurance).
A.8.26 explicitly lists resilience against buffer overflow (and SQLi) as one of the application security requirements to identify/address during development or acquisition; well-implemented, this reaches a minority slice of CWE-788 instances (those caught in requirements/risk assessment) but leaves most implementation-level buffer errors untouched.
A.8.27 mandates security-by-design principles (defense-in-depth, least privilege, fail securely, distrust external input, hardening, zero-trust verification) plus design reviews against known attack patterns, which can stop buffer overruns from being exploitable in many cases but leaves a bounded remainder (e.g. unsafe legacy code, unsafe third-party libraries, or implementation errors that slip past reviews).
Secure coding standards directly forbid writing or reading past buffer ends.
Security testing in development can detect buffer-overrun defects before release.