CWE-839: Numeric Range Comparison Without Minimum Check
Also known as: Signed comparison
The product checks a value to ensure that it is less than or equal to a maximum, but it does not also verify that the value is greater than or equal to the minimum.
Last updated
Overview
Some products use signed integers or floats even when their values are only expected to be positive or 0. An input validation check might assume that the value is positive, and only check for the maximum value. If the value is negative, but the code assumes that the value is positive, this can produce an error. The error may have security consequences if the negative value is used for memory allocation, array access, buffer access, etc. Ultimately, the error could lead to a buffer overflow or other type of memory corruption. The use of a negative number in a positive-only context could have security implications for other types of resources. For example, a shopping cart might check that the user is not requesting more than 10 items, but a request for -3 items could cause the application to calculate a negative price and credit the attacker's account.
Real-world CVEs
6 recorded CVEs are caused by CWE-839 (Numeric Range Comparison Without Minimum Check). The highest-severity and most recent are shown first. 3 new CWE-839 CVEs have been recorded so far in 2026.
- CVE-2026-53176
IB/isert: Reject login PDUs shorter than ISER_HEADERS_LEN
Critical · CVSS 9.8 · EPSS 51th2026-06-25 - CVE-2023-22854Critical · CVSS 9.1 · EPSS 45th2023-02-13
- CVE-2023-0425High · CVSS 8.6 · EPSS 32th2023-08-07
- CVE-2019-20925High · CVSS 7.5 · EPSS 74th2020-11-24
- CVE-2026-56968Medium · CVSS 5.3 · EPSS 15th2026-06-23
- CVE-2026-48840Medium · CVSS 5.3 · EPSS 18th2026-05-30
Common consequences
What can happen when CWE-839 is exploited.
Modify Application Data, Execute Unauthorized Code or Commands
Affects: Integrity, Confidentiality, Availability
An attacker could modify the structure of the message or data being sent to the downstream component, possibly injecting commands.
DoS: Resource Consumption (Other)
Affects: Availability
in some contexts, a negative value could lead to resource consumption.
Modify Memory, Read Memory
Affects: Confidentiality, Integrity
If a negative value is used to access memory, buffers, or other indexable structures, it could access memory outside the bounds of the buffer.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-839, grouped by where in the lifecycle they apply.
If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t.
If the number to be used could have a negative value based on the specification (thus requiring a signed value), but the number should only be positive to preserve code correctness, then include a check to ensure that the value is positive.
How to detect it
Automated Static Analysis
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.)
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following code is intended to read an incoming packet from a socket and extract one or more headers.
Vulnerable example
DataPacket *packet;The code performs a check to make sure that the packet does not contain too many headers. However, numHeaders is defined as a signed int, so it could be negative. If the incoming packet specifies a value such as -3, then the malloc calculation will generate a negative number (say, -300 if each header can be a maximum of 100 bytes). When this result is provided to malloc(), it is first converted to a size_t type. This conversion then produces a large value such as 4294966996, which may cause malloc() to fail or to allocate an extremely large amount of memory (CWE-195). With the appropriate negative numbers, an attacker could trick malloc() into using a very small positive number, which then allocates a buffer that is much smaller than expected, potentially leading to a buffer overflow.
The following code reads a maximum size and performs a sanity check on that size. It then performs a strncpy, assuming it will not exceed the boundaries of the array. While the use of "short s" is forced in this particular example, short int's are frequently used within real-world code, such as code that processes structured data.
Vulnerable example
int GetUntrustedInt () {This code first exhibits an example of CWE-839, allowing "s" to be a negative number. When the negative short "s" is converted to an unsigned integer, it becomes an extremely large positive integer. When this converted integer is used by strncpy() it will lead to a buffer overflow (CWE-119).
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
Vulnerable example
int getValueFromArray(int *array, int len, int index) {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.
The following code shows a simple BankAccount class with deposit and withdraw methods.
Vulnerable example
public class BankAccount {Safe example
public class BankAccount {Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2010-1866 — Chain: integer overflow (CWE-190) causes a negative signed value, which later bypasses a maximum-only check (CWE-839), leading to heap-based buffer overflow (CWE-122).
- CVE-2009-1099 — Chain: 16-bit counter can be interpreted as a negative value, compared to a 32-bit maximum value, leading to buffer under-write.
- CVE-2011-0521 — Chain: kernel's lack of a check for a negative value leads to memory corruption.
- CVE-2010-3704 — Chain: parser uses atoi() but does not check for a negative value, which can happen on some platforms, leading to buffer under-write.
- CVE-2010-2530 — Chain: Negative value stored in an int bypasses a size check and causes allocation of large amounts of memory.
- CVE-2009-3080 — Chain: negative offset value to IOCTL bypasses check for maximum index, then used as an array index for buffer under-read.
- CVE-2008-6393 — chain: file transfer client performs signed comparison, leading to integer overflow and heap-based buffer overflow.
- CVE-2008-4558 — chain: negative ID in media player bypasses check for maximum index, then used as an array index for buffer under-read.
Terminology & mappings
Alternate terms
- Signed comparison
- The "signed comparison" term is often used to describe when the product uses a signed variable and checks it to ensure that it is less than a maximum value (typically a maximum buffer size), but does not verify that it is greater than 0.
Frequently asked questions
Common questions about CWE-839.
- What is CWE-839?
- The product checks a value to ensure that it is less than or equal to a maximum, but it does not also verify that the value is greater than or equal to the minimum.
- What CVEs are caused by CWE-839?
- 6 recorded CVEs are attributed to CWE-839, including CVE-2026-53176, CVE-2023-22854, CVE-2023-0425.
- How do you prevent CWE-839?
- If the number to be used is always expected to be positive, change the variable type from signed to unsigned or size_t.
- How is CWE-839 detected?
- Automated Static Analysis: 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.)
- What are the consequences of CWE-839?
- Exploiting CWE-839 can lead to: Modify Application Data, Execute Unauthorized Code or Commands, DoS: Resource Consumption (Other), Modify Memory, Read Memory.
- Is CWE-839 actively exploited?
- 6 recorded CVEs are caused by CWE-839; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-839) (opens in a new tab)
- CWE-839 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-839
Get alerted the moment a new CWE-839 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.