Skip to content

CWE-1284: Improper Validation of Specified Quantity in Input

Base

The product receives input that is expected to specify a quantity (such as size or length), but it does not validate or incorrectly validates that the quantity has the required properties.

Specified quantities include size, length, frequency, price, rate, number of operations, time, and others. Code may rely on specified quantities to allocate resources, perform calculations, control iteration, etc.

Consequences

  • Other, Integrity, Availability: Varies by Context, DoS: Resource Consumption (CPU), Modify Memory, Read Memory

How to prevent it

  • 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.

Recent advisories

  • GHSA-5cwg-6vw7-rj6p — Forge: AES-GCM authentication bypass via unvalidated tagLength option
  • GHSA-jc66-7q78-782g — Forge: PKCS#12 MAC forgery and constant-key PBE via zero iteration count
  • GHSA-8hxf-qr8p-62x4 — zip: AES Entry HMAC Authentication Bypass on Premature EOF
  • GHSA-ph72-cqr5-qpp7 — vLLM: Scale-out disaggregated multimodal transport trusts caller-supplied features
  • EEF-CVE-2026-89420 — Session voucher adding no new funds is accepted without a charge in mpp, serving paid resources for free
  • GHSA-68fv-2mgg-jv7q — source-map-js allows event-loop denial of service through indexed source-map section offsets
  • EEF-CVE-2026-82750 — Unbounded EIP-7702 authorization list in mpp Tempo fee-payer sponsorship inflates gas cost and sponsors account delegation
  • EEF-CVE-2026-82751 — Unbounded key authorization in mpp Tempo fee-payer sponsorship inflates gas cost and sponsors access-key provisioning
  • EEF-CVE-2026-82752 — Ash string length constraints count graphemes, so a combining-mark string of any size passes max_length
  • EEF-CVE-2026-82734 — Non-finite Infinity/NaN decimal values bypass bounds constraints in Ash.Type.Decimal
  • GHSA-hxcr-hm88-mpq6 — Nuxt: Unauthenticated out-of-memory crash via unbounded v-for expansion in island rendering
  • EEF-CVE-2026-59252 — Missing gas_limit validation in mpp Tempo fee-payer enables wallet drain
  • EEF-CVE-2026-59694 — Unbounded access list in mpp Tempo fee-payer inflates gas cost per payment
  • EEF-CVE-2026-59695 — Unbounded max_fee_per_gas in mpp Tempo fee-payer enables single-request wallet drain
  • GHSA-8wr5-jm2h-8r4f — vLLM has Remote DoS via Invalid Recovered Token Reinjection

All advisories for CWE-1284

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor