CWE-787 is an out-of-bounds write weakness. It occurs when software writes past the end of an allocated buffer or array, which can corrupt memory, crash a process, or create an opportunity for code execution depending on the runtime and protections in place.
What CWE-787 Means in Practice
CWE-787 is an out-of-bounds write weakness, which means a program stores data past the end of a buffer or array. That sounds simple, but the consequences can range from process crashes to memory corruption and, in some environments, code execution.
The key security issue is not just that the write is “incorrect”, but that it breaks memory safety. Once adjacent memory is overwritten, the program may alter control data, object state, length fields, pointers, or other values that the runtime depends on to behave safely.
For many readers, the most useful way to think about CWE-787 is as a root cause class rather than a single bug. It can appear in C and C++ code, low-level system components, parsers, image decoders, network services, embedded software, and any routine that calculates offsets, lengths, or array indexes incorrectly.
How Out-of-Bounds Writes Become Security Failures
An out-of-bounds write becomes dangerous when the overwritten memory is still reachable by the process and the platform does not fully stop the corruption. Depending on layout and mitigations, the result may be a clean crash, silent data corruption, or a path to code execution.
The severity often depends on what sits next to the target buffer in memory. Overwriting a neighbouring object can change application behaviour; overwriting control information can influence execution flow; overwriting metadata can create instability that is hard to reproduce and harder to triage.
This is why memory corruption weaknesses are often discussed alongside related classes such as buffer overflow, heap corruption, stack corruption, and integer errors that lead to incorrect length calculations. The weakness category is broader than one coding mistake, but the operational risk is similar: memory writes happen outside the programmer’s intended boundary.
Defensive hardening can reduce exploitability, but it does not make the weakness harmless. Modern mitigations can raise the bar, yet the safest assumption is still that any confirmed out-of-bounds write is a genuine security defect until proven otherwise.
Common Causes and Where to Look for It
Practitioners usually find CWE-787 in code paths that trust a length, index, or pointer offset too much. Typical triggers include bad bounds checks, off-by-one errors, incorrect pointer arithmetic, mismatched source and destination sizes, and assumptions that input or state can never exceed a particular range.
It is especially common in code that handles untrusted input, performs manual memory management, or mixes signed and unsigned arithmetic. A calculation error early in a function can become a write past the end of a buffer much later, which makes root-cause analysis more difficult than the final crash suggests.
Static analysis, fuzzing, code review, and runtime sanitizers all help find these defects, but each has blind spots. A review may catch an obvious bad loop bound; fuzzing may reveal a crash without explaining the true write site; sanitizers may only observe the problem when the vulnerable path is exercised with the right inputs.
For a broader taxonomy of memory-safety weaknesses and how they are grouped, see the Memory Corruption Vulnerabilities Guide. For the relationship between weaknesses, vulnerabilities, and platform records, the CVE, CWE and CPE Guide is the most direct companion.
Why CWE-787 Matters for Remediation and Defense
Fixing CWE-787 usually means correcting the logic that allows the write to escape its boundary, not just suppressing the symptom. That can involve tightening validation, reworking length handling, removing unsafe constructs, or replacing brittle memory-manipulation code with safer abstractions.
Where a full rewrite is not immediately practical, defensive controls can still reduce exposure. Memory-safe languages, compiler hardening, exploit mitigations, and runtime protections are all relevant, but they should be treated as layered risk reduction rather than a substitute for removing the defect.
Because this weakness can be exploited in many different contexts, remediation should be tied to the exact code path and deployment exposure rather than handled as a generic “memory bug”. Internet-facing services, privileged components, and parsers for untrusted data deserve the fastest attention because the attack surface is larger and the impact is often higher.
Reviewing the wider weakness family also helps teams avoid repeat incidents. The CWE Top 25 Guide places out-of-bounds write in the context of other high-impact software weaknesses, which is useful when prioritising secure coding work and refactoring plans.
Risk and Threat Considerations
CWE-787 matters because memory corruption is frequently exploitable, not just unstable. Attackers often look for this weakness class when they want denial of service, information disclosure, or arbitrary code execution, especially in software that processes attacker-controlled input.
Failure mechanism: A write past the end of a buffer can overwrite adjacent state, corrupt control data, or poison object metadata in a way that changes execution flow or program logic.
Impact: The outcome can be a crash, corrupted output, privilege abuse, or full compromise of the affected process, depending on the target, memory layout, and mitigations in place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | CWE-787 often results from invalid lengths, indexes, or offsets entering unsafe code paths. |
| SA-11 — Developer Testing and Evaluation | Memory-safety defects are best found through secure testing before release. | |
| SI-16 — Memory Protection | Memory protection controls reduce exploitability of out-of-bounds writes. | |
| Recommendation — Validate all externally influenced sizes, indexes, and offsets before they reach memory writes. Use secure testing, fuzzing, and code review to uncover out-of-bounds writes before deployment. Apply memory protection mechanisms to limit the impact of corrupted writes at runtime. | ||
| ISO/IEC 27001:2022 | A.8.28 — Secure coding | CWE-787 is a secure coding failure that should be prevented in software design and implementation. |
| Recommendation — Build secure coding practices that prevent unsafe buffer and array writes. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application software security controls address defects like out-of-bounds writes in developed code. |
| Recommendation — Embed secure development and verification controls into the software delivery lifecycle. | ||
Practitioner Guidance
Why practitioners should care: Treat every confirmed out-of-bounds write as a release-blocking defect unless you can prove it is unreachable in deployed conditions. The practical question is not whether the bug exists, but whether an attacker or malformed input can drive execution into the vulnerable write.
What to watch for: Pay close attention to manual index arithmetic, length conversions, copy loops, and code that assumes an input size cannot exceed an expected maximum. Those are the places where small logic errors turn into memory corruption.
Practitioner takeaway: The best response is usually to remove the unsafe memory write path entirely, then validate that the fix holds under fuzzing, sanitizers, and regression tests.
Related resources from NHI Mgmt Group
- What do teams get wrong when they rely on top CWE rankings alone?
- Why do repeat CWE classes keep causing breaches even when teams know about them?
- How should security teams use the CWE Top 25 and OWASP Top 10 together without duplicating work?
- Why do CWE-level findings provide stronger audit evidence than OWASP category labels?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on November 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org