The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.

What CVEs are caused by CWE-682?

59 recorded CVEs are attributed to CWE-682, including CVE-2023-2163, CVE-2024-36736, CVE-2022-30600.

Is CWE-682 actively exploited?

59 recorded CVEs are caused by CWE-682; none are currently in CISA's KEV catalog of actively exploited flaws.

CWE-682: Incorrect Calculation

Overview

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.

Real-world CVEs

59 recorded CVEs are caused by CWE-682 (Incorrect Calculation). The highest-severity and most recent are shown first. 12 new CWE-682 CVEs have been recorded so far in 2026 (8 in 2025).

Showing 12 of 59 recorded CWE-682 CVEs. Track new ones as they are published and get AI-written analysis and fixes.

Monitor CWE-682 vulnerabilities

Common consequences

What can happen when CWE-682 is exploited.

DoS: Crash, Exit, or Restart

Affects: Availability

If the incorrect calculation causes the program to move into an unexpected state, it may lead to a crash or impairment of service.

DoS: Crash, Exit, or Restart, DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands

Affects: Integrity, Confidentiality, Availability

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

Gain Privileges or Assume Identity

Affects: Access Control

In the context of privilege or permissions assignment, an incorrect calculation can provide an attacker with access to sensitive resources.

Bypass Protection Mechanism

Affects: Access Control

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.

How it happens

When it is introduced

Typically introduced during these phases of the software lifecycle.

Implementation

How to prevent it

Practical mitigations for CWE-682, grouped by where in the lifecycle they apply.

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.

How to detect it

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.

Effectiveness: High

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

Fuzzing

Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.

Effectiveness: High

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

The following image processing code allocates a table for images.

Vulnerable example

c

img_t table_ptr; /*struct containing img data, 10kB each*/

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.

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.

Vulnerable example

c

int *p = x;

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.

Illustrative examples

Real CVEs that MITRE cites as examples of this weakness.

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)
CVE-2010-1378 — Chain: incorrect calculation (CWE-682) allows attackers to bypass certificate checks (CWE-295)
CVE-2004-1363 — substitution overflow: buffer overflow using environment variables that are expanded after the length check is performed

How this weakness relates to others in the CWE hierarchy.

Child

Can precede

CWE-170: Improper Null Termination

Terminology & mappings

Mapped taxonomies

CERT C Secure Coding: Prevent or detect domain and range errors in math functions (FLP32-C) — CWE More Abstract fit
CERT C Secure Coding: Use only explicitly signed or unsigned char type for numeric values (INT07-C)
CERT C Secure Coding: Use bitwise operators only on unsigned operands (INT13-C)
CERT C Secure Coding: Ensure that division and remainder operations do not result in divide-by-zero errors (INT33-C) — CWE More Abstract fit
CERT C Secure Coding: 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 (INT34-C) — CWE More Abstract fit

Attack patterns

CAPEC attack patterns that exploit this weakness.

Frequently asked questions

Common questions about CWE-682.

What is CWE-682?: The product performs a calculation that generates incorrect or unintended results that are later used in security-critical decisions or resource management.
What CVEs are caused by CWE-682?: 59 recorded CVEs are attributed to CWE-682, including CVE-2023-2163, CVE-2024-36736, CVE-2022-30600.
How do you prevent CWE-682?: 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.
How is CWE-682 detected?: 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.
What are the consequences of CWE-682?: Exploiting CWE-682 can lead to: DoS: Crash, Exit, or Restart, DoS: Resource Consumption (Other), Execute Unauthorized Code or Commands, Gain Privileges or Assume Identity, Bypass Protection Mechanism.
Is CWE-682 actively exploited?: 59 recorded CVEs are caused by CWE-682; none are currently in CISA's KEV catalog of actively exploited flaws.

References

Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

How to prevent it

How to detect it

Manual Analysis

Automated Static Analysis

Fuzzing

Code examples

Illustrative examples

Related weaknesses

Child

Can precede

Related

Terminology & mappings

Mapped taxonomies

Attack patterns

Frequently asked questions

References

Stay ahead of CWE-682