CWE-788: Access of Memory Location After End of Buffer

Code Examples & CVEs

Demonstrative Examples

This example takes an IP address from a user, verifies that it is well formed and then looks up the hostname and copies it into a buffer.

This function allocates a buffer of 64 bytes to store the hostname, however there is no guarantee that the hostname will not be larger than 64 bytes. If an attacker specifies an address which resolves to a very large hostname, then the function may overwrite sensitive data or even relinquish control flow to the attacker.

BadC

void host_lookup(char *user_supplied_addr){                         struct hostent *hp;in_addr_t *addr;char hostname[64];in_addr_t inet_addr(const char *cp);                                                        /*routine that ensures user_supplied_addr is in the right format for conversion */                                                        validate_addr_form(user_supplied_addr);addr = inet_addr(user_supplied_addr);hp = gethostbyaddr( addr, sizeof(struct in_addr), AF_INET);strcpy(hostname, hp->h_name);                      }

In the following example, it is possible to request that memcpy move a much larger segment of memory than assumed:

If returnChunkSize() happens to encounter an error it will return -1. Notice that the return value is not checked before the memcpy operation (CWE-252), so -1 can be passed as the size argument to memcpy() (CWE-805). Because memcpy() assumes that the value is unsigned, it will be interpreted as MAXINT-1 (CWE-195), and therefore will copy far more memory than is likely available to the destination buffer (CWE-787, CWE-788).

BadC

int returnChunkSize(void *) {                                                                                 /* if chunk info is valid, return the size of usable memory,                                                                                    * else, return -1 to indicate an error                                                                                    */                            ...                      }int main() {...memcpy(destBuf, srcBuf, (returnChunkSize(destBuf)-1));...}

This example applies an encoding procedure to an input string and stores it into a buffer.

The programmer attempts to encode the ampersand character in the user-controlled string, however the length of the string is validated before the encoding procedure is applied. Furthermore, the programmer assumes encoding expansion will only expand a given character by a factor of 4, while the encoding of the ampersand expands by 5. As a result, when the encoding procedure expands the string it is possible to overflow the destination buffer if the attacker provides a string of many ampersands.

BadC

char * copy_input(char *user_supplied_string){                         int i, dst_index;char *dst_buf = (char*)malloc(4*sizeof(char) * MAX_SIZE);if ( MAX_SIZE <= strlen(user_supplied_string) ){die("user string too long, die evil hacker!");}dst_index = 0;for ( i = 0; i < strlen(user_supplied_string); i++ ){                               if( '&' == user_supplied_string[i] ){dst_buf[dst_index++] = '&';dst_buf[dst_index++] = 'a';dst_buf[dst_index++] = 'm';dst_buf[dst_index++] = 'p';dst_buf[dst_index++] = ';';}else if ('<' == user_supplied_string[i] ){                                                                                                                     /* encode to &lt; */                                                                                                               }else dst_buf[dst_index++] = user_supplied_string[i];                            }return dst_buf;                      }

In the following C/C++ example the method processMessageFromSocket() will get a message from a socket, placed into a buffer, and will parse the contents of the buffer into a structure that contains the message length and the message body. A for loop is used to copy the message body into a local character string which will be passed to another method for processing.

However, the message length variable (msgLength) from the structure is used as the condition for ending the for loop without validating that msgLength accurately reflects the actual length of the message body (CWE-606). If msgLength indicates a length that is longer than the size of a message body (CWE-130), then this can result in a buffer over-read by reading past the end of the buffer (CWE-126).

BadC

int processMessageFromSocket(int socket) {                         int success;                            char buffer[BUFFER_SIZE];char message[MESSAGE_SIZE];                                                        // get message from socket and store into buffer                                                                                    //Ignoring possibliity that buffer > BUFFER_SIZE                            if (getMessage(socket, buffer, BUFFER_SIZE) > 0) {                                                                                                   // place contents of the buffer into message structure                                  ExMessage *msg = recastBuffer(buffer);                                                                    // copy message body into string for processing                                  int index;for (index = 0; index < msg->msgLength; index++) {message[index] = msg->msgBody[index];}message[index] = '\0';                                                                    // process message                                  success = processMessage(message);                            }return success;                      }

Observed CVE Examples (6)

CVE-2009-2550

Classic stack-based buffer overflow in media player using a long entry in a playlist

View Details

CVE-2009-2403

Heap-based buffer overflow in media player using a long entry in a playlist

View Details

CVE-2009-0689

large precision value in a format string triggers overflow

View Details

CVE-2009-0558

attacker-controlled array index leads to code execution

View Details

CVE-2008-4113

OS kernel trusts userland-supplied length value, allowing reading of sensitive information

View Details

CVE-2007-4268

Chain: integer signedness error (CWE-195) passes signed comparison, leading to heap overflow (CWE-122)

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Detect Access of Memory Location After End of Buffer with Fuzzing

Documented detection approaches include Fuzzing, Automated Static Analysis, and Automated Dynamic Analysis; recorded impacts include Read Memory, Modify Memory, DoS: Crash, Exit, or Restart, and Execute Unauthorized Code or Commands; observed examples include CVE-2009-2550, CVE-2009-2403, and CVE-2009-0689. Use these source-defined anchors to turn CWE-788 into implementation, review, and verification checks for the affected component.

CWE-788: Access of Memory Location After End of Buffer — MITRE CWE

Prevent CWE-788 through an SSDF control plan

Use NIST SSDF practices to make prevention of CWE-788, Access of Memory Location After End of Buffer, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Triage CWE-788 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-788, Access of Memory Location After End of Buffer, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-788

Apply MITRE's full root-cause mapping guidance when using CWE-788, Access of Memory Location After End of Buffer. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-788 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-788, Access of Memory Location After End of Buffer. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-788: Access of Memory Location After End of Buffer?+

CWE-788: Access of Memory Location After End of Buffer is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product reads or writes to a buffer using an index or pointer that references a memory location after the end of the buffer. This typically occurs when a pointer or its index is incremented to a position after the buffer; or when pointer arithmetic results in a position after the buffer.

What are the security consequences of Access of Memory Location After End of Buffer?+

If exploited, CWE-788 (Access of Memory Location After End of Buffer) it can compromise Confidentiality, Integrity and Availability, leading to outcomes such as Read Memory, Modify Memory, DoS: Crash, Exit, or Restart and Execute Unauthorized Code or Commands.

Which programming languages are affected by Access of Memory Location After End of Buffer?+

CWE-788 commonly affects C, C++ and Memory-Unsafe. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Access of Memory Location After End of Buffer?+

MITRE documents real CVEs mapped to CWE-788, including CVE-2009-2550, CVE-2009-2403, CVE-2009-0689, CVE-2009-0558 and CVE-2008-4113. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-788 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-788: Access of Memory Location After End of Buffer

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Scope

Impact

Scope

Impact

Mitigation Strategies

Detection Methods

Code Examples & CVEs

Demonstrative Examples

Observed CVE Examples (6)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Detect Access of Memory Location After End of Buffer with Fuzzing

Prevent CWE-788 through an SSDF control plan

Triage CWE-788 against known exploitation evidence

Apply precise root-cause mapping to CWE-788

Validate CWE-788 with root-cause mapping checks

Frequently Asked Questions

Learn More