The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
When product performs a security-critical calculation incorrectly, it might lead to incorrect resource allocations, incorrect privilege assignments, or failed comparisons among other things. Many of the direct results of an incorrect calculation can lead to even larger problems such as failed protection mechanisms or even arbitrary code execution.

Primary

Implementation

High

Availability
DoS: Crash, Exit, or Restart
If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.

Integrity
Confidentiality
Availability
DoS: Crash, Exit, or Restart
DoS: Resource Consumption (Other)
Execute Unauthorized Code or Commands
If the incorrect calculation is used in the context of resource allocation, it could lead to an out-of-bounds operation (CWE-119) leading to a crash or even arbitrary code execution. Alternatively, it may result in an integer overflow (CWE-190) and / or a resource consumption problem (CWE-400).

Access Control
Gain Privileges or Assume Identity
In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.

Access Control
Bypass Protection Mechanism
If the incorrect calculation leads to an insufficient comparison (CWE-697), it may compromise a protection mechanism such as a validation routine and allow an attacker to bypass the security-critical code.

Manual Analysis

This weakness can be detected using tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session.
Specifically, manual static analysis is useful for evaluating the correctness of allocation calculations. This can be useful for detecting overflow conditions (CWE-190) or similar weaknesses that might have serious security impacts on the program.

High
These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Implementation
Understand your programming language's underlying representation and how it interacts with numeric calculation. Pay close attention to byte size discrepancies, precision, signed/unsigned distinctions, truncation, conversion and casting between types, "not-a-number" calculations, and how your language handles numbers that are too large or too small for its underlying representation.

Implementation
Input Validation
Perform input validation on any numeric input by ensuring that it is within the expected range. Enforce that the input meets both the minimum and maximum requirements for the expected range.

Implementation
Use the appropriate type for the desired action. For example, in C/C++, only use unsigned types for values that could never be negative, such as height, width, or other numbers related to quantity.

Architecture and Design
Language Selection

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Architecture and Design
Libraries or Frameworks

Use languages, libraries, or frameworks that make it easier to handle numbers without unexpected consequences.
Examples include safe integer handling packages such as SafeInt (C++) or IntegerLib (C or C++).

Implementation
Compilation or Build Hardening
Examine compiler warnings closely and eliminate problems with potential security implications, such as signed / unsigned mismatch in memory operations, or use of uninitialized variables. Even if the weakness is rarely exploitable, a single failure may lead to the compromise of the entire system.

Testing
Use automated static analysis tools that target this type of weakness. Many modern techniques use data flow analysis to minimize the number of false positives. This is not a perfect solution, since 100% accuracy and coverage are not feasible.

Testing
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

The following image processing code allocates a table for images.

img_t table_ptr; /*struct containing img data, 10kB each*/int num_imgs;...num_imgs = get_num_imgs();table_ptr = (img_t*)malloc(sizeof(img_t)*num_imgs);...

This code intends to allocate a table of size num_imgs, however as num_imgs grows large, the calculation determining the size of the list will eventually overflow (CWE-190). This will result in a very small list to be allocated instead. If the subsequent code operates on the list as if it were num_imgs long, it may result in many types of out-of-bounds problems (CWE-119).

This code attempts to calculate a football team's average number of yards gained per touchdown.

...int touchdowns = team.getTouchdowns();int yardsGained = team.getTotalYardage();System.out.println(team.getName() + " averages " + yardsGained / touchdowns + "yards gained for every touchdown scored");...

The code does not consider the event that the team they are querying has not scored a touchdown, but has gained yardage. In that case, we should expect an ArithmeticException to be thrown by the JVM. This could lead to a loss of availability if our error handling code is not set up correctly.

This example attempts to calculate the position of the second byte of a pointer.

int *p = x;char * second_char = (char *)(p + 1);

In this example, second_char is intended to point to the second byte of p. But, adding 1 to p actually adds sizeof(int) to p, giving a result that is incorrect (3 bytes off on 32-bit platforms). If the resulting memory address is read, this could potentially be an information leak. If it is a write, it could be a security-critical write to unauthorized memory-- whether or not it is a buffer overflow. Note that the above code may also be wrong in other ways, particularly in a little endian environment.

CVE-2020-0022
chain: mobile phone Bluetooth implementation does not include offset when calculating packet length (CWE-682), leading to out-of-bounds write (CWE-787)
https://www.cve.org/CVERecord?id=CVE-2020-0022

CVE-2004-1363
substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed
https://www.cve.org/CVERecord?id=CVE-2004-1363

FLP32-C
Prevent or detect domain and range errors in math functions
CWE More Abstract

INT07-C
Use only explicitly signed or unsigned char type for numeric values

INT13-C
Use bitwise operators only on unsigned operands

INT33-C
Ensure that division and remainder operations do not result in divide-by-zero errors
CWE More Abstract

INT34-C
Do not shift an expression by a negative number of bits or by greater than or equal to the number of bits that exist in the operand
CWE More Abstract

Discouraged
This CWE entry is extremely high-level, a Pillar. In many cases, lower-level children or descendants are more appropriate. However, sometimes this weakness is forced to be used due to the lack of in-depth weakness research. See Research Gaps.
Where feasible, consider children or descendants of this entry instead.

Weaknesses related to this Pillar appear to be under-studied, especially with respect to classification schemes. Input from academic and other communities could help identify and resolve gaps or organizational difficulties within CWE.

CWE Content Team
MITRE
2008-04-11
Draft 9
2008-04-11

Eric Dalci
Cigital
2008-07-01
updated Potential_Mitigations, Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships

CWE Content Team
MITRE
2008-10-14
updated Type

CWE Content Team
MITRE
2008-11-24
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-01-12
updated Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Likelihood_of_Exploit, Potential_Mitigations, Relationships

CWE Content Team
MITRE
2009-03-10
updated Potential_Mitigations

CWE Content Team
MITRE
2009-05-27
updated Demonstrative_Examples

CWE Content Team
MITRE
2009-07-27
updated Demonstrative_Examples, Related_Attack_Patterns

CWE Content Team
MITRE
2009-10-29
updated Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2010-02-16
updated Potential_Mitigations

CWE Content Team
MITRE
2010-04-05
updated Detection_Factors, Potential_Mitigations, References

CWE Content Team
MITRE
2010-06-21
updated Potential_Mitigations

CWE Content Team
MITRE
2010-09-27
updated Potential_Mitigations

CWE Content Team
MITRE
2011-03-29
updated Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2011-09-13
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Demonstrative_Examples, References, Relationships

CWE Content Team
MITRE
2014-02-18
updated Relationships

CWE Content Team
MITRE
2014-07-30
updated Relationships

CWE Content Team
MITRE
2015-12-07
updated Relationships

CWE Content Team
MITRE
2017-01-19
updated Applicable_Platforms

CWE Content Team
MITRE
2017-11-08
updated Taxonomy_Mappings

CWE Content Team
MITRE
2019-01-03
updated Relationships

CWE Content Team
MITRE
2019-06-20
updated Related_Attack_Patterns, Relationships

CWE Content Team
MITRE
2020-02-24
updated Applicable_Platforms, Observed_Examples, Relationships, Type

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description, Potential_Mitigations

CWE Content Team
MITRE
2023-04-27
updated Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Research_Gaps

CWE Content Team
MITRE
2025-09-09
4.18
2025-09-09
updated References

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Weakness_Ordinalities