Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
CWE-125 Base Draft
Out-of-bounds Read
An out-of-bounds read occurs when software accesses memory outside the boundaries of a buffer, array, or similar data structure, reading data it wasn't intended to see.
Definition
What is CWE-125?
An out-of-bounds read occurs when software accesses memory outside the boundaries of a buffer, array, or similar data structure, reading data it wasn't intended to see.
This vulnerability happens when a program uses an incorrect index, offset, or pointer that references a memory location before the start or after the end of a valid buffer. For example, using `buffer[size]` or `buffer[-1]` triggers this issue. The result is that the application reads data from adjacent memory locations, which could be uninitialized, contain sensitive information from other parts of the program, or even cause a crash.
While this flaw doesn't directly allow data modification like its 'write' counterpart, it remains a serious security risk. Attackers can exploit it to leak sensitive information, bypass security controls, or gather data to enable further attacks. It's a common root cause for information disclosure and is often the first step in more complex exploit chains.
Real-world impact
Real-world CVEs caused by CWE-125
-
The reference implementation code for a Trusted Platform Module does not implement length checks on data, allowing for an attacker to read 2 bytes past the end of a buffer.
-
Out-of-bounds read in IP stack used in embedded systems, as exploited in the wild per CISA KEV.
-
Chain: "Heartbleed" bug receives an inconsistent length parameter (CWE-130) enabling an out-of-bounds read (CWE-126), returning memory that could include private cryptographic keys and other sensitive data.
-
HTML conversion package has a buffer under-read, allowing a crash
-
Chain: unexpected sign extension (CWE-194) leads to integer overflow (CWE-190), causing an out-of-bounds read (CWE-125)
-
Chain: product does not handle when an input string is not NULL terminated (CWE-170), leading to buffer over-read (CWE-125) or heap-based buffer overflow (CWE-122).
-
Chain: series of floating-point precision errors (CWE-1339) in a web browser rendering engine causes out-of-bounds read (CWE-125), giving access to cross-origin data
-
out-of-bounds read due to improper length check
How attackers exploit it
Step-by-step attacker path
- 1
In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method
- 2
However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.
- 3
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.
- 4
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).
Vulnerable code example
Vulnerable C
In the following code, the method retrieves a value from an array at a specific array index location that is given as an input parameter to the method
int getValueFromArray(int *array, int len, int index) {
int value;
```
// check that the array index is less than the maximum*
*// length of the array*
if (index < len) {
```
```
// get the value at the specified index of the array*
value = array[index];}
*// if array index is invalid then output error message*
*// and return value indicating error*
else {
```
printf("Value is: %d\n", array[index]);
value = -1;
}
return value;
} Secure code example
Secure C
However, this method only verifies that the given array index is less than the maximum length of the array but does not check for the minimum value (CWE-839). This will allow a negative value to be accepted as the input array index, which will result in reading data before the beginning of the buffer (CWE-127) and may allow access to sensitive memory. The input array index should be checked to verify that is within the maximum and minimum range required for the array (CWE-129). In this example the if statement should be modified to include a minimum range check, as shown below.
...
```
// check that the array index is within the correct*
*// range of values for the array*
if (index >= 0 && index < len) {
... What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-125
- Implementation Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. To reduce the likelihood of introducing an out-of-bounds read, ensure that you validate and ensure correct calculations for any length argument, buffer size calculation, or offset. Be especially careful of relying on a sentinel (i.e. special character such as NUL) in untrusted inputs.
- Architecture and Design Use a language that provides appropriate memory abstractions.
Detection signals
How to detect CWE-125
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Plexicus auto-detects CWE-125 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-125?
How serious is CWE-125?
What languages or platforms are affected by CWE-125?
How can I prevent CWE-125?
How does Plexicus detect and fix CWE-125?
Where can I learn more about CWE-125?
Frequently asked questions
What is CWE-125?
An out-of-bounds read occurs when software accesses memory outside the boundaries of a buffer, array, or similar data structure, reading data it wasn't intended to see.
How serious is CWE-125?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-125?
MITRE lists the following affected platforms: C, C++, ICS/OT.
How can I prevent CWE-125?
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and…
How does Plexicus detect and fix CWE-125?
Plexicus's SAST engine matches the data-flow signature for CWE-125 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-125?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/125.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-125
CWE-119 Parent
Improper Restriction of Operations within the Bounds of a Memory Buffer
This vulnerability occurs when software accesses a memory buffer but reads from or writes to a location outside its allocated boundary.…
CWE-120 Sibling
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
This vulnerability occurs when a program copies data from one memory location to another without first verifying that the source data will…
CWE-123 Sibling
Write-what-where Condition
A write-what-where condition occurs when an attacker can control both the data written and the exact memory location where it's written,…
CWE-130 Sibling
Improper Handling of Length Parameter Inconsistency
This vulnerability occurs when a program reads a structured data packet or message but fails to properly validate that the declared length…
CWE-466 Sibling
Return of Pointer Value Outside of Expected Range
This vulnerability occurs when a function returns a memory pointer that points outside the expected buffer range, potentially exposing…
CWE-786 Sibling
Access of Memory Location Before Start of Buffer
This vulnerability occurs when software attempts to read from or write to a memory location positioned before the official start of a…
CWE-787 Sibling
Out-of-bounds Write
This vulnerability occurs when software incorrectly writes data outside the boundaries of its allocated memory buffer, either beyond the…
CWE-788 Sibling
Access of Memory Location After End of Buffer
This vulnerability occurs when software attempts to read from or write to a memory buffer using an index or pointer that points past the…
CWE-805 Sibling
Buffer Access with Incorrect Length Value
This vulnerability occurs when software reads from or writes to a buffer using a loop or sequential operation, but mistakenly calculates…
Resources
Further reading
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.