CWE-190: Integer Overflow or Wraparound

Integer overflow is often associated with memory corruption, but the same mechanism applies whenever software relies on invalid assumptions about integer arithmetic. A wrapped value can corrupt allocation sizes or offsets, alter validation conditions, break loop termination, or produce invalid dates and timestamps. When used in allocation, copying, or concatenation, the result may create a buffer smaller than required and lead to memory-safety failures; when used in quotas, expiration checks, or other security decisions, it can produce an incorrect protection outcome.

The weakness occurs when an integer calculation exceeds its representation range or when an increment wraps to a very small or negative value. It can affect sizes, offsets, counts, loop indices, time values, dates, physical dimensions, and financial calculations, not only memory operations. Risk is especially significant when the result controls allocation, copying, concatenation, loop behavior, security checks, quotas, or time-based decisions.

Possible consequences include crashes, restarts, instability, excessive or insufficient resource allocation, memory corruption, and incorrect results. A wrapped loop index can terminate a loop too early, too late, or not at all, causing altered execution logic, excessive CPU or resource consumption, or denial of service. If the value controls a security decision, such as a quota, allocation limit, expiration time, or date range, the weakness can bypass protection mechanisms; in some cases it can contribute to buffer overflows, unauthorized code or command execution, or self-denial of service.

Requirements and design: Define protocols strictly so that out-of-bounds behavior is identifiable, and require strict conformance. Prefer vetted libraries or frameworks that provide safe numeric handling, such as SafeInt or IntegerLib. Duplicate security checks performed on the client at the server, because client-side values and checks can be modified or removed.

Language and implementation: Where feasible, use a language or compiler with automatic bounds checking or constructs that prevent this weakness. Validate every numeric input against both minimum and maximum expected values; use unsigned integers where appropriate, and include minimum-value checks when signed integers are required. Understand the language representation and numeric behavior, including byte sizes, precision, signedness, truncation, conversions, casts, not-a-number calculations, limits, and 32-bit versus 64-bit differences. Closely review compiler warnings, including signed/unsigned mismatches in memory operations, and eliminate security-relevant issues.

Automated static analysis can often identify this weakness using data-flow or constraint-based techniques, with high effectiveness. Manual analysis, including penetration testing, threat modeling, interactive testing, and especially manual review of allocation calculations, can be highly effective for design and business-rule issues. Black-box dynamic testing with fuzzing, robustness testing, and fault injection provides moderate evidence, but without code visibility it may not distinguish this weakness from others and can require follow-up analysis.

The record also identifies high-cost-effectiveness approaches for source-code, bytecode, and binary weakness analysis; formal methods or correct-by-construction review; and inspection. It identifies fuzz testers, framework-based fuzzers, and manual source-code review as cost-effective for partial coverage. Dynamic testing may slow operation, but the product should not become unstable, crash, or produce incorrect results under diverse inputs.

The following are representative examples in the official record, not an exhaustive list:

• CVE-2025-46687: missing length validation in a JavaScript engine led to integer overflow, allocation of a smaller buffer than expected, and a heap-based buffer overflow.
• CVE-2025-55067: Unix time values beyond the 2038 rollover caused authentication failures and other problems in protection mechanisms.
• CVE-2025-27363: improper conversion from a signed short to an unsigned long caused wraparound, an undersized buffer, and an out-of-bounds write.
• CVE-2021-43537: forcing an unsigned 64-bit integer into a 32-bit integer could cause overflow and heap memory corruption.
• CVE-2019-19911: an extremely large number of image bands led to excessive memory consumption or integer overflow.
• CVE-2022-0545: integer overflow in a 3D renderer led to a write-what-where condition when processing a crafted image.
• CVE-2021-30860 and CVE-2021-30663: improper input validation led to integer overflow in a mobile operating system; both were recorded as exploited in the wild.
• CVE-2018-10887: unexpected sign extension led to integer overflow and an out-of-bounds read.
• CVE-2019-1010006: compiler optimization removed or changed overflow-detection code, enabling an out-of-bounds write.
• CVE-2010-1866: a negative signed value resulting from overflow bypassed a maximum-only check and led to a heap-based buffer overflow.
• CVE-2010-2753: integer overflow led to use-after-free.
• CVE-2005-1513: integer overflow in a securely coded mail program led to a buffer overflow.
• CVE-2002-0391: integer overflow through a very large number of arguments; CVE-2002-0639: integer overflow in OpenSSH.
• CVE-2005-1141: an image with large width and height caused overflow in a size calculation.
• CVE-2005-0102 and CVE-2004-2013: a length of -1 caused a zero-byte allocation followed by a heap overflow.
• CVE-2017-1000121: unchecked message-size metadata led to integer overflow and buffer overflow.
• CVE-2013-1591: overflow in an image-size calculation caused an infinite loop that allocated buffers without bounds until the stack was full.