CWE-121 is Stack-based Buffer Overflow. The flaw arises when a stack-based buffer overflow occurs when a buffer allocated on the stack, typically a local variable and more rarely a function parameter, is overwritten beyond its bounds. The database currently holds 909 vulnerabilities mapped to CWE-121 and 1 of them are in the CISA Known Exploited Vulnerabilities catalog.
A stack-based buffer overflow condition is a condition where the buffer being overwritten is allocated on the stack (i.e., is a local variable or, rarely, a parameter to a function).
There are generally several security-critical data on an execution stack that can lead to arbitrary code execution. The most prominent is the stored return address, the memory address at which execution should continue once the current function is finished executing. The attacker can overwrite this value with some memory address to which the attacker also has write access, into which they place arbitrary code to be run with the full privileges of the vulnerable program. Alternately, the attacker can supply the address of an important call, for instance the POSIX system() call, leaving arguments to the call on the stack. This is often called a return into libc exploit, since the attacker generally forces the program to jump at return time into an interesting routine in the C standard library (libc). Other important data commonly on the stack include the stack pointer and frame pointer, two values that indicate offsets for computing memory addresses. Modifying those values can often be leveraged into a "write-what-where" condition.
When input exceeds the capacity of a stack-allocated buffer, it can overwrite adjacent data in the current function's stack frame. This may include the stored return address, causing execution to continue at an attacker-influenced location, or the stack and frame pointers, which can distort address calculations and memory operations. Consequently, the condition can cause crashes or data corruption and, in some circumstances, enable unauthorized code execution or bypass of the program's security policy.
The weakness affects a buffer located on the execution stack, usually a local variable and more rarely a function parameter. Security-sensitive stack data can be overwritten, including the stored return address, stack pointer, and frame pointer; altering these values can redirect execution, modify memory, or support writes to attacker-influenced locations. It commonly occurs in memory-unsafe languages, especially C and C++.
The most direct consequence is reduced availability through crashes, process termination or restart, excessive CPU or memory consumption, or other denial-of-service conditions such as an infinite loop. Depending on what stack data is overwritten, the weakness may allow memory modification, unauthorized code or command execution, and bypass of protection mechanisms across integrity, confidentiality, availability, and access control. Arbitrary code execution can in turn undermine other security services.
| Impact | Scope | Explanation |
|---|---|---|
| Modify Memory, DoS: Crash, Exit, or Restart, DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory) | Availability | Buffer overflows generally lead to crashes. Other attacks leading to lack of availability are possible, including putting the program into an infinite loop. |
| Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism | Integrity, Confidentiality, Availability, Access Control | Buffer overflows often can be used to execute arbitrary code, which is usually outside the scope of a program's implicit security policy. |
| Modify Memory, Execute Unauthorized Code or Commands, Bypass Protection Mechanism, Other | Integrity, Confidentiality, Availability, Access Control, Other | When the consequence is arbitrary code execution, this can often be used to subvert any other security service. |
Use bounds checking on input and avoid dangerous functions such as gets; choose safer equivalent functions that check boundary errors. Use abstraction libraries to hide risky APIs, while recognizing that this is not a complete solution.
As defense in depth, enable compiler or compiler-extension protections such as Microsoft Visual Studio /GS, Fedora/Red Hat FORTIFY_SOURCE, StackGuard, or ProPolice. These canaries and range or index checks detect some overflows, but they do not cover every type and the usual response can still be application termination and denial of service.
As additional defense in depth, use Address Space Layout Randomization (ASLR), Position-Independent Executables (PIE), and, where applicable, module rebasing or prelinking to make executable and library addresses less predictable. These measures do not provide a complete solution because address disclosures and side-channel attacks may bypass ASLR, and ASLR for libraries cannot be used together with prelinking.
Fuzzing: Generate large numbers of random or algorithmically varied inputs and invoke the code dynamically to expose crashes, memory corruption, or resource consumption. This approach can produce repeatable test cases and is rated highly effective.
Automated static analysis: Use source-level or binary-level analysis to model data and control flow, then search for potentially vulnerable paths from input sources to sinks. This can find some instances without executing the program and is rated highly effective.
Automated dynamic analysis: Integrate runtime memory-safety checks during compilation, such as AddressSanitizer for C/C++. This approach has moderate effectiveness because inputs must reach the defective code, it may reduce performance, and it reports the error condition rather than the original programming mistake.
| Method | Approach | Effectiveness |
|---|---|---|
| Fuzzing | Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues. | High |
| Automated Static Analysis | Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.) | High |
| Automated Dynamic Analysis | Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518].Crafted inputs are necessary to reach the code containing the error, such as generated by fuzzers. Also, these tools may reduce performance, and they only report the error condition - not the original mistake that led to the error. | Moderate |
A representative example is CVE-2021-35395, involving stack-based buffer overflows in SFK for a Wi-Fi chipset used in IoT and embedded devices; it was identified by CISA KEV as exploited in the wild. This is a representative example, not an exhaustive list of vulnerabilities in this weakness class.
Below are representative vulnerabilities related to this CWE, prioritized by severity.
CWE™ Program, operated by The MITRE Corporation. Copyright © 2006–2026, The MITRE Corporation. The MITRE Corporation hereby grants you a non-exclusive, royalty-free license to use CWE for research, development, and commercial purposes. CWE Terms of Use.
CyStack VulnScan continuously discovers assets, validates vulnerabilities, and helps security teams prioritize remediation across the organization.
Review CyStack's security rating and practical recommendations for websites and edge assets.
Explore cybersecurity research from our team of security specialists.
Browse practical cybersecurity knowledge across CyStack's articles and guides.
en
