CWE-1284 covers a product that receives input meant to specify a quantity, such as a size or length, but does not validate it or validates it incorrectly. It can hit any language and any kind of application, from payment code to image parsers.
How it happens
MITRE's list of quantities is wide: size, length, frequency, price, rate, number of operations, time and others. Code relies on these values to allocate resources, perform calculations and control iteration. If an attacker supplies a quantity the code did not expect, such as a negative number, zero, or a very large value, the code does the wrong thing with it.
The recorded CVEs show four faces of the problem.
- CVE-2025-4037: an ATM simulator does not check for negative values with deposits or withdrawals, so attackers can increase their balance.
- CVE-2025-46687: a chain where JavaScript engine code does not perform a length check (CWE-1284), leading to integer overflow, then to allocation of a smaller buffer than expected, then to a heap-based buffer overflow.
- CVE-2019-19911: a chain where a Python library does not limit the resources used to process images that specify a very large number of bands, leading to excessive memory consumption or an integer overflow.
- CVE-2008-1440: lack of validation of a length field leads to an infinite loop.
Vulnerable and fixed
A withdrawal handler that trusts the amount:
# Vulnerable: a negative amount increases the balance
def withdraw(account, amount):
account.balance -= amount
return account.balance
Validate type, range and business limits before use:
# Safer: reject anything outside the allowed range
MAX_WITHDRAWAL = 5000
def withdraw(account, amount):
if not isinstance(amount, int):
raise ValueError("amount must be an integer")
if amount <= 0 or amount > MAX_WITHDRAWAL:
raise ValueError("amount out of range")
if amount > account.balance:
raise ValueError("insufficient funds")
account.balance -= amount
return account.balance
The same check applies to lengths that size a buffer:
/* Vulnerable: len comes from the packet */
char *buf = malloc(len);
memcpy(buf, data, len);
/* Safer: bound it against a known limit first */
#define MAX_LEN 4096
if (len == 0 || len > MAX_LEN) return -1;
char *buf = malloc(len);
if (!buf) return -1;
memcpy(buf, data, len);
What an attacker gains
MITRE lists several outcomes: excessive resource allocation and CPU consumption, unexpected failures, buffer overflows, and reading or modifying memory. The consequences are tagged as affecting integrity and availability and vary by context. Money moves in the ATM case, crashes and hangs in the loop and memory cases.
How to find it
MITRE notes that automated static analysis (SAST) can find some instances by building a model of data flow. A few other checks are cheap.
- Search for every place a request field becomes an allocation size, a loop bound, a delay, a price or a quantity.
- Test each with zero, negative, maximum integer and absurdly large values.
- Fuzz file and protocol parsers, since length fields in headers are a classic source.
- Add business rule tests, for example a transfer of a negative amount must fail.
How to fix it
The record lists no mitigation text, so these steps come from the definition.
- Define the valid range for every quantity you accept, and write it down.
- Validate on the server side, at the point of entry, before the value is used.
- Check both lower and upper bounds, and watch arithmetic that could overflow.
- Cap resource use per request so a large legitimate looking value cannot exhaust memory or CPU.
- In dependencies, apply vendor patches for known cases. Two of the CVEs above are in widely reused engine and library code. A free in-browser dependency scan can show whether your manifest includes known vulnerable versions, and reachability analysis tells you whether your code actually calls the affected function.
Try it yourself
Static analysis is the right tool for tracing a user supplied number into a risky use. The demo shows a code scan finding this kind of flow.
Click through it at your own pace, or open it full screen.
Quick check
Why is a negative number a quantity problem?
Because code that subtracts or allocates by that value can behave in reverse. A negative withdrawal adds money, which is the recorded ATM simulator case.
Is a length check enough on its own?
It is the start. MITRE's chain example pairs a missing length check with integer overflow and an undersized buffer, so arithmetic on the validated value also needs care.
