A buffer overflow is a memory-safety vulnerability in which a program writes more data into a fixed-size buffer than it can hold, so the surplus bytes spill into adjacent memory and overwrite whatever lives there — other variables, function pointers, saved return addresses, or heap bookkeeping. When an attacker controls the overflowing data, they can steer program execution, most severely into remote code execution. Out-of-bounds writes are catalogued as CWE-787, which has repeatedly ranked in the top tier of MITRE's CWE Top 25 Most Dangerous Software Weaknesses.
Buffer overflows are a defining hazard of memory-unsafe languages, chiefly C and C++, which still power operating-system kernels, browsers, image and network libraries, and embedded firmware. The stakes are visible in modern incidents: CVE-2023-4863, a heap buffer overflow in the libwebp image library, was a zero-click flaw exploited in the wild that rippled through every browser and application bundling the library. Because so much foundational software remains in C/C++, industry guidance from CISA and the NSA in 2023–2024 explicitly urged adopting memory-safe languages, noting that memory-safety defects have historically accounted for roughly 70% of severe vulnerabilities at major vendors like Microsoft and in Google Chrome.
How Buffer Overflows Work
Memory for a running function is laid out in predictable regions. Local buffers on the stack sit near control data — including the saved return address the CPU jumps to when the function finishes. A heap buffer sits among other allocations and the allocator's own metadata. An overflow in either region overwrites its neighbors.
The classic stack overflow: a function copies attacker-controlled input into a small local array without checking length. The write runs past the array and clobbers the saved return address. When the function returns, execution jumps to an address the attacker chose — historically into shellcode placed on the stack, and in modern exploits into a chain of existing code fragments (return-oriented programming) that sidesteps non-executable-memory defenses. Heap overflows corrupt adjacent objects or allocator metadata, which an attacker grooms into a controllable write primitive.
Overflows frequently begin as a different bug. An integer overflow in a size calculation can produce a buffer that is allocated too small, after which a "valid-looking" copy overruns it. A related class, out-of-bounds reads (CWE-125) like Heartbleed (CVE-2014-0160), leak memory rather than corrupt it, but stem from the same missing bounds discipline. Network-facing parsers are prime targets: CVE-2020-0796 ("SMBGhost") was a buffer overflow in Windows SMBv3 compression that allowed unauthenticated, wormable remote code execution.
Vulnerable vs. Fixed
The archetypal defect is an unbounded copy into a fixed buffer.
/* VULNERABLE: strcpy copies until NUL, ignoring the size of dest */
void handle(const char *input) {
char name[64];
strcpy(name, input); /* input > 63 bytes overruns the stack buffer */
printf("Hello %s\n", name);
}
/* FIXED: bound the copy to the destination size and always terminate */
void handle(const char *input) {
char name[64];
snprintf(name, sizeof name, "%s", input); /* never writes past name */
printf("Hello %s\n", name);
}
The fixed version ties the write to sizeof name, so no input length can overrun the buffer. That is the minimum bar in C. The stronger, strategic answer is to remove the hazard class entirely by writing new components in a memory-safe language such as Rust or Go, where bounds are checked and this defect cannot occur without explicit unsafe code.
Prevention Checklist
- Use memory-safe languages (Rust, Go, and similar) for new code, especially parsers and network-facing services.
- In C/C++, bound every copy with the destination size (
snprintf,memcpywith a checked length) and validate lengths before allocation to prevent integer-overflow-driven undersizing. - Enable compiler and OS mitigations: stack canaries, ASLR, non-executable memory (DEP/NX), and control-flow integrity.
- Compile with hardening and warnings (
-D_FORTIFY_SOURCE=2,-Wall -Wextra, sanitizers like ASan in testing). - Fuzz parsers and decoders to surface overruns before attackers do.
- Patch third-party native libraries fast, since bundled components like
libwebppropagate a single overflow into thousands of products. - Track your native dependencies with an SBOM so you can find every product affected by a new memory-safety CVE.
How Safeguard Detects Buffer Overflow Risk
Most organizations do not write the vulnerable C themselves — they ship it inside dependencies, container base images, and system packages. Safeguard's software composition analysis builds a complete inventory of your native and OS-level components and flags those affected by known buffer-overflow CVEs like the libwebp and SMBv3 flaws, using reachability context to separate exploitable exposure from noise. That is decisive during fire drills such as the libwebp event, when the hard question is simply "where is this library, transitively, across everything we ship?"
When a match appears, automated remediation proposes the patched version and opens a pull request, and you can enforce a policy gate with the Safeguard CLI so a build carrying a known-exploited memory-safety CVE fails before release. Griffin AI explains severity and blast radius in plain language for triage. If you are comparing dependency-scanning accuracy and reachability, our Snyk comparison covers the differences directly.
Frequently Asked Questions
What is the difference between a stack and a heap buffer overflow? A stack overflow overruns a buffer allocated on the call stack, often overwriting the saved return address to hijack control flow directly. A heap overflow overruns a dynamically allocated buffer, corrupting adjacent heap objects or allocator metadata; exploitation is usually more involved but equally capable of leading to code execution.
Do stack canaries and ASLR make buffer overflows unexploitable? No — they raise the cost, not eliminate the bug. Techniques like return-oriented programming, information leaks that defeat ASLR, and heap grooming routinely bypass individual mitigations. Defenses are valuable in depth, but the durable fix is preventing the out-of-bounds write, ideally by using a memory-safe language.
Are buffer overflows still relevant if I write in Python or JavaScript? Your application code is largely safe from this class, but your runtime, native extensions, and dependencies are written in C/C++. A buffer overflow in an image library, TLS stack, or interpreter still affects you — which is why tracking and patching native dependencies matters even for memory-safe application languages.
Want to find every place a memory-safety CVE like libwebp reaches across your stack? Create a free account or read the dependency-scanning guide in the Safeguard docs.