Lessons from CWE-787: Out-of-Bounds Write & Why It’s So Dangerous

Today, I dug deep into CWE-787: Out-of-Bounds Write, and it was a stark reminder of how even the smallest mistakes in coding can lead to devastating security consequences.

What is Out-of-Bounds Write?

At its core, an Out-of-Bounds Write occurs when a program writes data past the end—or before the start—of a memory buffer that was allocated. Imagine you have an array with 10 slots, and you accidentally write into the 11th slot. That small misstep can end up overwriting critical data in adjacent memory locations.

Why Does It Matter?

The consequences of an Out-of-Bounds Write are severe:

1. Memory Corruption – It can overwrite variables, pointers, or other program data, leading to unpredictable behavior.

2. Program Crashes – Many systems will crash when invalid memory access is detected, resulting in denial of service.

3. Arbitrary Code Execution – Skilled attackers can craft malicious input to exploit these writes and run their own code, often taking full control of a system.

This vulnerability has been behind numerous high-profile security breaches and is considered one of the most dangerous coding flaws by organizations like MITRE and OWASP.

Where Does CWE-787 Happen?

You’re most likely to encounter this vulnerability in low-level programming languages like C and C++. Why? Because these languages give developers direct memory access but don’t perform automatic bounds-checking.

Some common scenarios include:

• Iterating past the end of an array.

• Miscalculating buffer sizes during memory allocation.

• Incorrect pointer arithmetic.

• Incomplete validation of user-supplied data.

The Big Takeaway: Secure Coding Practices Are Non-Negotiable

Preventing Out-of-Bounds Write vulnerabilities starts with discipline in how we code:

• Use Safe Libraries: Functions like strcpy and gets are unsafe—opt for safer alternatives (strncpy, fgets, etc.).

• Enable Compiler Protections: Modern compilers provide flags and protections like stack canaries and address sanitizer tools.

• Perform Rigorous Bounds-Checking: Always validate input sizes and ensure array accesses stay within limits.

Adopt Memory-Safe Languages: When possible, languages like Rust, Go, or even managed environments like .NET/Java eliminate entire classes of memory bugs.

The below is the image from the official site of SansTop25 representing Out of Bound Write vulnerability.

The Question We Should All Ask

As we continue to build more complex systems, are memory-safe languages the future? Will languages like Rust become mainstream and make issues like Out-of-Bounds Writes obsolete? Or will we always need to fight these vulnerabilities at the hardware and compiler level because of legacy codebases?

I’d love to hear your thoughts.