Buffer Overflow: Stack vs Heap, Examples and Prevention

A buffer overflow happens when a program writes more data into a fixed-size block of memory than the block can hold, so the extra bytes overwrite whatever sits next to it. In C and C++ that can crash the program, corrupt data or, in the worst case, let an attacker redirect execution. The bug class is more than 35 years old and still appears in actively exploited VPN, browser and kernel flaws in 2026. This guide explains how they work, how stack, heap and integer-related overflows differ, which CWE IDs apply, and how to prevent and find them.

What Is a Buffer Overflow?

A buffer overflow (also called a buffer overrun) is a memory-safety bug in which code writes past the end, or before the beginning, of a buffer it was allocated. MITRE tracks the result as CWE-787: Out-of-bounds Write. It occurs mostly in languages such as C and C++ that do not check array bounds automatically.

A buffer is just a run of memory reserved for data: a 16-byte array for a username, a 4 KB block for a network packet, a heap allocation for a decoded image. The program is responsible for making sure every write stays inside that space. When a length check is missing or wrong, the write continues into neighboring memory that belongs to something else.

What sits next to the buffer decides how bad the bug is. It might be another variable, a pointer, bookkeeping the memory allocator needs, or the address a function will return to. Overwrite the wrong one and the program behaves in ways its authors never intended.

The bug has a long record. The 1988 Morris worm, one of the first internet worms, spread partly through a buffer overflow in the Unix fingerd service. Nearly four decades later, CISA and the FBI still describe buffer overflows as "unforgivable defects" because the fixes are well known.

The CWE family for buffer overflows

Several CWE entries describe buffer overflows from different angles. They overlap on purpose: one describes the class, others describe the location, the coding pattern or the cause. Knowing which is which makes advisories and scanner output easier to read.

MITRE's CWE-120 entry lists "Classic Buffer Overflow" as its alternate name. Vendor advisories often tag one bug with two IDs, for example CWE-121 for the location and CWE-787 for the effect.

Buffer overflow vs stack overflow

The two terms are often confused. A stack overflow, in the narrow sense, is stack exhaustion: a program uses more stack space than the operating system reserved, usually through runaway recursion, and crashes. A stack-based buffer overflow is different. The stack has plenty of room, but one buffer on it receives more data than it was sized for and overwrites its neighbors. The first is mainly a reliability bug; the second is a classic security vulnerability.

Overflow vs over-read

Writing past a buffer and reading past it are related but not the same. Heartbleed (CVE-2014-0160) is often called a buffer overflow, but NVD maps it to CWE-125, an out-of-bounds read: OpenSSL returned up to 64 KB of process memory it should never have sent. Over-reads leak secrets such as keys and session data. Overflows corrupt memory and can change what the program does. Both are memory-safety bugs, and the same prevention methods cover both.

How a Buffer Overflow Works

Every running program divides memory into regions. Two matter most here:

• The stack holds each function's local variables plus the bookkeeping needed to return to the caller, including the saved frame pointer and the return address. It grows and shrinks as functions are called and return.
• The heap holds memory requested at run time with malloc in C or new in C++. Its size is decided while the program runs, often from a value in the input.

An overflow follows the same pattern in both regions. The program reserves a buffer of some size, receives input whose length it does not check correctly, and copies that input into the buffer. The bytes that do not fit spill into adjacent memory.

On the stack, the adjacent memory includes the function's control data. If a function copies 40 bytes of input into a 16-byte local array, the extra 24 bytes can overwrite other local variables, the stack canary if the compiler added one, the saved frame pointer and the return address. When the function returns, the CPU reads a return address the input may have changed. The outcomes range from a crash, often the first visible symptom, through silent data corruption, to control-flow hijacking and code execution at the far end.

On the heap, there is no return address next to the buffer. Instead, the overflow can overwrite neighboring objects, function pointers or C++ virtual-table pointers stored in them, or the metadata the allocator uses to track free blocks. The effect often appears later, when the program uses the corrupted object, which makes heap bugs harder to trace.

The important point for defenders is that an overflow is first a crash or corruption bug. Turning it into reliable code execution takes extra work, and modern mitigations exist to make that work harder. That is also why a crash found during testing is evidence of a vulnerability, not proof that it can be exploited remotely.

Unsafe vs Safe Copy: A Harmless C Example

The classic cause is a string copy that trusts the input length. The example below is illustrative and safe to compile: it uses a fixed string, and main only calls the checked version. It shows three ways to copy a name into a 16-byte buffer.

#include <stdio.h>
#include <string.h>

#define NAME_LEN 16

/* UNSAFE: strcpy copies until it finds '\0', whatever the size of dst.
   A source longer than 15 characters writes past the end (CWE-120). */
void set_name_unsafe(char dst[NAME_LEN], const char *src) {
    strcpy(dst, src);
}

/* BETTER: strncpy limits the copy, but if src is too long it does NOT
   add the terminating '\0'. You must terminate the string yourself. */
void set_name_strncpy(char dst[NAME_LEN], const char *src) {
    strncpy(dst, src, NAME_LEN - 1);
    dst[NAME_LEN - 1] = '\0';
}

/* PREFERRED: snprintf always terminates and returns the length it
   wanted to write, so the caller can detect and reject truncation. */
int set_name_checked(char *dst, size_t dst_len, const char *src) {
    int n = snprintf(dst, dst_len, "%s", src);
    if (n < 0 || (size_t)n >= dst_len) {
        return -1;   /* did not fit: reject instead of truncating silently */
    }
    return 0;
}

int main(void) {
    char name[NAME_LEN];
    const char *input = "a-display-name-longer-than-16";

    if (set_name_checked(name, sizeof name, input) != 0) {
        puts("name too long, rejected");
    }
    return 0;
}

Three lessons sit in those few lines:

1. strcpy, strcat, sprintf and gets have no idea how big the destination is. gets was removed from the C standard in C11 for exactly this reason. Treat the others as findings in code review unless the size is proven safe.
2. strncpy is not a safe drop-in for strcpy. It stops at the limit but leaves the string unterminated when the source is too long, and the next function that reads it can run off the end. It also pads short strings with zeros, which wastes time on large buffers.
3. Bounded is not the same as correct. snprintf prevents the overflow, but silently cutting a name, path or certificate field can create a logic bug of its own. Check the return value and decide what truncation should mean.

In C++, prefer std::string, std::vector and std::span with checked access, and build with a hardened standard library mode so out-of-range indexing is caught at run time. The best fix, where it is practical, is a language in which this code cannot be written at all.

Types of Buffer Overflow: Stack, Heap and Integer-Related

Most buffer overflows fall into three groups, defined by where the buffer lives and how the size goes wrong. In every case the final effect is an out-of-bounds write.

Stack-based buffer overflows (CWE-121)

Stack overflows are the textbook case because the overwritten data includes the return address. They usually come from a fixed-size local array filled by an unbounded copy, a read or recv with the wrong length, or a parser loop that trusts a length field. Compilers now place a random canary value between local buffers and control data and check it before the function returns, which turns many stack overflows into a controlled abort. Ivanti Connect Secure's CVE-2025-0282 and CVE-2025-22457 are recent stack-based overflows that NVD records as allowing remote unauthenticated code execution, and both are in CISA's Known Exploited Vulnerabilities (KEV) catalog.

Heap-based buffer overflows (CWE-122)

Heap overflows hit dynamically allocated memory. They are common in parsers for images, fonts, documents and network protocols, where the code allocates space based on one value and later writes based on another. A stack canary does not protect the heap, so these bugs rely on hardened allocators, sanitizers in testing and, above all, correct size tracking. The libwebp flaw CVE-2023-4863, a heap buffer overflow triggered by a crafted image, affected Chrome and every other product that bundled the library.

Integer-related overflows (CWE-190 and CWE-680)

Some of the hardest overflows to spot start with arithmetic, not a copy. If code computes count * sizeof(record) and the result exceeds the largest value the type can hold, it wraps around to a small number. The program allocates a small buffer and then writes count records into it. Each line looks reasonable on its own; the bug lives in the gap between them. Microsoft's Windows Fast FAT driver flaw CVE-2025-24985 is tagged by NVD as both an integer overflow (CWE-190) and a heap-based buffer overflow (CWE-122).

The defense is to check the arithmetic before you trust it:

#include <stdint.h>
#include <stdlib.h>

#define RECORD_SIZE 64
struct record { char data[RECORD_SIZE]; };

/* Check the multiplication before it can wrap around. */
struct record *alloc_records(size_t count) {
    if (count == 0 || count > SIZE_MAX / sizeof(struct record)) {
        return NULL;   /* would overflow: reject the request */
    }
    return malloc(count * sizeof(struct record));
}

C23 adds checked-arithmetic helpers such as ckd_mul in <stdckdint.h>, and calloc takes the count and size separately so the library can check the product. Whatever the method, the rule is the same: validate sizes taken from input, and validate every calculation derived from them.

Other memory-safety bugs you will see next to overflows

Advisories often group buffer overflows with out-of-bounds reads (CWE-125), use-after-free (CWE-416) and format string bugs (CWE-134). They have different causes but the same root: the language lets code touch memory it should not. Use-after-free ranks above every buffer overflow ID except CWE-787 in the 2025 CWE Top 25. Kernel bugs such as the Linux AF_ALG flaw in our CVE-2026-31431 (Copy Fail) analysis show the same boundary problem without any string copy at all.

Why Buffer Overflows Still Matter in 2026

It is tempting to treat buffer overflows as a solved 1990s problem. The data says otherwise.

In MITRE's 2025 CWE Top 25 Most Dangerous Software Weaknesses, out-of-bounds write (CWE-787) ranks fifth. The classic buffer copy (CWE-120) ranks 11th, stack-based overflow (CWE-121) 14th and heap-based overflow (CWE-122) 16th. Four separate buffer-overflow IDs in one top-25 list is a strong signal for a single bug family. The same page counts 12 KEV-listed CVEs mapped to CWE-787, six to CWE-122 and four to CWE-121 in the list's data. Web weaknesses such as cross-site scripting and SQL injection rank higher, as our guide to the most common web vulnerabilities covers, but memory corruption dominates in products written in C and C++.

Buffer overflows in CISA's KEV catalog

The KEV catalog lists vulnerabilities with evidence of exploitation in the wild. The examples below are a selection, not a complete list. Each row comes from its NVD record, checked on November 5, 2026.

NVD records: CVE-2024-21762, CVE-2025-7775, CVE-2024-37079, CVE-2025-25249 and CVE-2026-3909. The others are linked in the sections above.

Three patterns stand out:

• Edge devices are a favorite target. VPN gateways and firewalls from Ivanti, Fortinet and Citrix appear repeatedly. They face the internet, run C code that parses untrusted traffic, and often sit in front of everything else.
• Many entries reach KEV on day zero or day one. Several CVEs above were added to KEV on or within a day of publication, which means exploitation was already happening when the advisory appeared. Patch windows measured in weeks do not fit that pattern; see our zero-day exploit guide for how teams plan around it.
• Old overflows keep coming back. The vCenter heap overflow was published in June 2024 and added to KEV in January 2026, about 19 months later. Unpatched internal systems remain exposed long after the news cycle moves on.

Local overflows matter too. A driver or kernel overflow such as the Fast FAT bug lets code already running as a normal user gain more control, which is why it often appears as the second step in an attack chain; our guide to privilege escalation explains that stage.

What US agencies now expect from software makers

Since 2022, US agencies and their partners have moved from advising developers to asking executives for a plan:

• November 10, 2022: the NSA published its "Software Memory Safety" information sheet. Its press release notes that Microsoft and Google have each said memory safety issues are behind around 70% of their vulnerabilities.
• December 6, 2023: CISA, NSA, FBI and the cyber agencies of Australia, Canada, the UK and New Zealand published The Case for Memory Safe Roadmaps. It states that two-thirds of reported vulnerabilities in memory-unsafe languages still relate to memory issues and asks manufacturers to publish roadmaps for moving to memory-safe languages.
• May 8, 2024: CISA announced the Secure by Design pledge with 68 initial signers. One of its seven goals is "reducing entire classes of vulnerability", and the pledge text gives a memory-safe roadmap as an example approach. The pledge is voluntary and not legally binding.
• CISA and FBI's Product Security Bad Practices guidance calls new product lines for critical infrastructure in memory-unsafe languages dangerous when memory-safe alternatives are available, and asks manufacturers to publish a memory-safety roadmap for existing products by the end of 2025.
• February 12, 2025: CISA and the FBI issued the Secure by Design Alert: Eliminating Buffer Overflow Vulnerabilities. It names buffer overflows "unforgivable defects", lists CVE-2025-0282 among its examples, and recommends memory-safe languages, compiler protections, sanitizer-instrumented tests, fuzzing, static analysis and root-cause analysis.
• June 24, 2025: CISA and NSA published Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development, which covers the practical obstacles to adoption and how to work through them.

The approach can work. Google reported in September 2024 that memory-safety bugs fell from 76% to 24% of Android's vulnerabilities over six years, as new development shifted to memory-safe languages while older code stayed mostly in place.

For buyers, the practical takeaway is simple: ask suppliers of network-facing and on-premises software whether they have a memory-safety roadmap, which build hardening they use, and how they test for overflows before release.

How to Prevent Buffer Overflows

No single control stops every overflow. The strongest programs remove the bug where they can, harden what remains, and test for what slips through. The CISA and FBI alert above follows the same order.

1. Use memory-safe languages where you can

The CISA and FBI alert puts this first because it removes the bug class instead of making it harder to exploit. Rust, Go, Java, C#, Swift and Python all check bounds in ordinary code. Two caveats from the alert matter in practice: many of these languages let developers turn the checks off (Rust's unsafe, for example), and moving one component to a safe language does nothing for the C library it still calls. A phased plan works best: write new code in a memory-safe language, then rewrite the most exposed parsers and network handlers first.

2. Write bounded C and C++ for the code you keep

For existing code, ban unbounded functions in code review and linters, carry the buffer size alongside every pointer, check arithmetic on sizes taken from input, and prefer standard containers in C++. Enable hardened library modes (_GLIBCXX_ASSERTIONS for libstdc++, the libc++ hardening mode) so out-of-range indexing becomes a clean abort rather than silent corruption. Bake these rules into your secure SDLC so every new component inherits them.

3. Turn on compiler and linker hardening

The OpenSSF Compiler Options Hardening Guide for C and C++ maintains a recommended set for GCC and Clang. The flags most relevant to buffer overflows are:

-O2 -D_FORTIFY_SOURCE=3 -D_GLIBCXX_ASSERTIONS
-fstack-protector-strong -fstack-clash-protection
-fPIE -pie
-Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now
-fcf-protection=full            # x86-64: CET shadow stack and branch tracking
-mbranch-protection=standard    # AArch64: pointer authentication and BTI

Test the build with these flags before shipping; a few options cost performance or need code changes. On Windows, the MSVC equivalents include /GS for stack buffer checks, /guard:cf for Control Flow Guard and the /DYNAMICBASE and /NXCOMPAT linker options for ASLR and DEP.

4. Understand what runtime mitigations do and do not do

Stack canaries, DEP/NX, ASLR and control-flow integrity are standard on modern operating systems, and they have made exploitation far more expensive. They do not remove the bug. An overflow that still crashes a VPN gateway is a denial of service; one that corrupts an authorization flag needs no code execution at all; and an information leak that reveals an address can undercut ASLR. Treat mitigations as a safety net that buys time, not as the reason to leave an overflow unfixed.

5. Test for overflows before attackers do

Run unit tests and fuzzers against builds instrumented with AddressSanitizer, which reports the exact out-of-bounds write instead of a vague crash. Pair that with static analysis and focused manual review of parsers. The next section shows how testers apply these methods.

How Testers Find Buffer Overflows

Finding an overflow does not require writing an exploit. Professional testing aims to show that the bug exists, that attacker-controlled input can reach it, and how severe the realistic impact is. Everything below belongs in an authorized engagement or a lab you control.

Code review: follow the length

With source access, reviewers start where untrusted data enters: network handlers, file parsers, IPC endpoints, command-line arguments and environment variables. They then trace each length from input to the copy, read or allocation that uses it. Typical red flags include:

• unbounded copy and format functions (strcpy, strcat, sprintf, gets, scanf("%s"))
• memcpy or read lengths taken from a header field without comparison to the destination size
• size calculations that multiply or add input values before allocating
• loops that use <= against a buffer length, or signed lengths compared with unsigned sizes
• manual string handling in protocol parsers

Static analysis tools flag many of these patterns automatically, but they produce false positives and miss bugs that span files. Our comparison of manual and automated code review explains how the two fit together, and our guide to SAST, DAST, IAST and RASP covers where each testing type fits in a pipeline.

Fuzzing with sanitizers: let the input do the searching

Fuzzing feeds a program huge volumes of generated input and watches for crashes. Coverage-guided fuzzers such as libFuzzer, AFL++ and Honggfuzz learn which inputs reach new code and mutate them further. Paired with AddressSanitizer, every out-of-bounds write is caught at the moment it happens, with a stack trace, even when it would not crash a normal build. Google's OSS-Fuzz project reports that, as of May 2025, it had helped identify and fix more than 13,000 vulnerabilities and 50,000 bugs across 1,000 open-source projects.

A useful fuzzing setup for your own code has four parts: a small harness that passes fuzzer bytes to one parser function, a seed corpus of valid sample files or messages, a sanitizer build, and a CI job that runs it on every change. The results are crashes with reproducible inputs, which become regression tests once fixed.

Binary analysis for code you cannot read

Thick clients, embedded firmware and third-party libraries often arrive without source. Testers then check how the binaries were built: whether ASLR, DEP, stack protection and control-flow protection are enabled, and whether risky imported functions appear. They map where the application parses files, network messages or IPC data, and they fuzz those inputs in an isolated lab copy. Desktop applications are a common place to find native parsers and missing hardening, which is one reason our guide to thick client penetration testing covers process memory and loaded libraries. Mobile apps that ship native libraries raise the same questions, and mobile application penetration testing covers both the app and its server side.

What a good overflow finding contains

A crash alone is not a finding. A useful report gives the developer and the risk owner enough to act:

1. Location and root cause: the function, the buffer, the size check that is missing or wrong, and the CWE.
2. Reachability: which input reaches the bug, from where (remote unauthenticated, authenticated, local), and under what configuration.
3. Evidence: a minimal reproducing input and the sanitizer report or crash state, produced in a test environment.
4. Realistic impact: crash, data corruption or a credible path to code execution, with the mitigations present in the build taken into account. No weaponized exploit is needed to make that case.
5. Fix and retest: the code-level fix, any hardening flags missing from the build, and a regression test or fuzz target that proves the fix holds.

Frequently Asked Questions

What is a buffer overflow in simple terms?

A buffer overflow happens when a program puts more data into a fixed-size area of memory than it can hold, and the extra data overwrites neighboring memory. In languages such as C and C++ that can crash the program, change its data or, in serious cases, let an attacker run code.

Is buffer overflow still a problem in 2026?

Yes. Out-of-bounds write (CWE-787) ranks fifth in MITRE's 2025 CWE Top 25, and CISA's KEV catalog added exploited buffer overflows in 2026, including a VMware vCenter heap overflow in January and a Fortinet heap overflow in September. CISA and the FBI called the class "unforgivable defects" in February 2025.

What is an example of a buffer overflow attack?

Ivanti Connect Secure's CVE-2025-0282 is a stack-based buffer overflow that NVD records as allowing remote unauthenticated code execution. CISA added it to the KEV catalog the day it was published, January 8, 2025, and cited it as an example in its buffer overflow alert.

What is the difference between a stack and a heap buffer overflow?

A stack-based overflow (CWE-121) overwrites a local buffer inside a function and can reach the return address. A heap-based overflow (CWE-122) overwrites memory allocated at run time and corrupts neighboring objects or allocator data. Stack canaries help against the first but not the second.

How do you prevent buffer overflows?

Use memory-safe languages for new code. In C and C++, use bounded functions, track buffer sizes and check size arithmetic. Build with hardening flags such as -D_FORTIFY_SOURCE=3 and -fstack-protector-strong, keep ASLR, DEP and control-flow protection enabled, and fuzz parsers with AddressSanitizer before release.

Can buffer overflows happen in Python, Java or Rust?

Not in ordinary code, because these languages check bounds automatically. They can still happen in native extensions, in libraries written in C that the program calls, in the language runtime itself, or in Rust code marked unsafe.

Does ASLR prevent buffer overflows?

No. ASLR randomizes where code and data load in memory, which makes exploitation harder because the attacker cannot predict addresses. The overflow still happens and can still crash the program or corrupt data. A separate information leak can also reveal addresses and weaken ASLR.

Next Step: Find the Overflows in Your Own Code

Buffer overflows hide in the parts of a product that handle untrusted input: protocol handlers, file parsers, drivers and native libraries inside desktop and mobile apps. The questions to answer are concrete. Which components are still written in C or C++? Are they built with hardening flags? Have their parsers ever been fuzzed with a sanitizer? Is there a memory-safety roadmap for the code you cannot rewrite yet?

DeepStrike's penetration testing services include white-box testing, in which testers are given the application's source code, along with web application testing based on the OWASP Top 10 and CWE Top 25 and mobile testing of both the client and server side. To scope a test of your application, desktop client or exposed service, contact DeepStrike.

About The Author

Mohammed Khalil is a Cybersecurity Architect at DeepStrike, specializing in advanced penetration testing and offensive security operations. With certifications including CISSP, OSCP, and OSWE, he has led numerous red team engagements, focusing on cloud security, application vulnerabilities, and adversary emulation. His work involves dissecting complex attack chains and developing resilient defense strategies for clients in the finance, healthcare, and technology sectors.

Sources and References

MITRE CWE-787: Out-of-bounds Write

MITRE CWE-120: Buffer Copy without Checking Size of Input

MITRE CWE-121: Stack-based Buffer Overflow

MITRE CWE-122: Heap-based Buffer Overflow

MITRE CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer

MITRE CWE-125: Out-of-bounds Read

MITRE CWE-190: Integer Overflow or Wraparound

MITRE CWE-680: Integer Overflow to Buffer Overflow

MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses

CISA and FBI: Secure by Design Alert: Eliminating Buffer Overflow Vulnerabilities (February 12, 2025)

CISA and NSA: Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development (June 24, 2025)

CISA et al.: The Case for Memory Safe Roadmaps (December 6, 2023)

CISA and FBI: Product Security Bad Practices

CISA: Secure by Design Pledge

CISA: Secure by Design commitments announcement (May 8, 2024)

NSA: Guidance on how to protect against software memory safety issues (November 10, 2022)

Google Security Blog: Eliminating Memory Safety Vulnerabilities at the Source (September 25, 2024)

OpenSSF: Compiler Options Hardening Guide for C and C++

Google OSS-Fuzz (GitHub)

AddressSanitizer documentation (GitHub)

Wikipedia: Morris worm

NVD: CVE-2014-0160

NVD: CVE-2023-4863

NVD: CVE-2024-21762

NVD: CVE-2025-0282

NVD: CVE-2025-24985

NVD: CVE-2025-22457

NVD: CVE-2025-7775

NVD: CVE-2024-37079

NVD: CVE-2025-25249

NVD: CVE-2026-3909