CWE-122: Heap-based Buffer Overflow

The weakness arises when the program fails to ensure that data fits within a heap-allocated buffer. The out-of-bounds write can corrupt adjacent heap data or memory-resident control information, including function pointers and other runtime structures. Depending on the corrupted data and the execution environment, the condition may cause a crash, resource exhaustion, unauthorized code execution, or circumvention of security controls.

This is a simple, variant-level weakness typically introduced during implementation and is often associated with memory-unsafe languages, especially C and C++. Its defining characteristic is that the affected buffer resides in heap memory rather than on the stack. The condition can result from inadequate input bounds checks, integer calculation errors, missing termination handling, or unsafe APIs.

The immediate impact may be a crash, process termination or restart, excessive CPU consumption, memory exhaustion, or another denial of service. Corruption of heap data or function pointers may enable unauthorized code or command execution, memory modification, or bypass of protection mechanisms, affecting confidentiality, integrity, availability, and access control. Arbitrary code execution can in turn undermine other security services.

Prevent unsafe writes: Use a language or compiler with automatic bounds checking, perform bounds checks on input during implementation, and avoid dangerous functions such as gets in favor of boundary-checking equivalents. Use abstraction libraries to hide risky APIs, while recognizing that this is not a complete solution. Apply OS-level preventive functionality as an additional defense-in-depth measure.

Harden builds and runtime environments: Enable compiler or compiler-extension buffer-overflow detection, including mechanisms such as the Microsoft Visual Studio /GS flag, Fedora/Red Hat FORTIFY_SOURCE, StackGuard, and ProPolice. These controls detect only certain overflows and commonly respond by terminating the application, so they may still result in denial of service. Use address randomization and related memory-layout protections, including ASLR and PIE; these reduce the reliability of control-flow exploitation but are not complete protections because address disclosure and side-channel attacks may bypass ASLR.

Fuzzing: Generate large numbers of diverse inputs, invoke the code dynamically, and look for repeatable crashes, memory corruption, or resource consumption. Fuzzing is highly effective for exposing unexpected behavior, but it depends on inputs reaching the faulty code.

Automated dynamic analysis: Integrate runtime memory-safety checks during compilation, such as AddressSanitizer (ASan) for C/C++. Crafted inputs are needed to reach the error, and these tools can reduce performance; they report the error condition rather than the original programming mistake that caused it.

The official record lists these representative examples, not an exhaustive set:

• CVE-2025-46687: Missing length checking led through an integer overflow and an undersized allocation to a heap-based buffer overflow in a JavaScript engine.
• CVE-2021-43537: A forced conversion from an unsigned 64-bit integer to a 32-bit integer could contribute to integer overflow and heap memory corruption in a web browser.
• CVE-2007-4268: An integer signedness error allowed a comparison to succeed and led to a heap overflow.
• CVE-2009-2523: Failure to handle a non-null-terminated input string led to either a buffer over-read or a heap-based buffer overflow.
• CVE-2021-29529: Integer-oriented bounds calculated with ceiling and floor on floating-point values could trigger a heap-based buffer overflow in a machine-learning product.
• CVE-2010-1866: Integer overflow produced a negative signed value that bypassed a maximum-only check and led to a heap-based buffer overflow.