The product performs an iteration or loop without sufficiently limiting the number of times that the loop is executed.
If the iteration can be influenced by an attacker, this weakness could allow attackers to consume excessive resources such as CPU or memory. In many cases, a loop does not need to be infinite in order to cause enough resource consumption to adversely affect the product or its host system; it depends on the amount of resources consumed per iteration.

Primary

Resultant

Implementation

Availability
DoS: Resource Consumption (CPU)
DoS: Resource Consumption (Memory)
DoS: Amplification
DoS: Crash, Exit, or Restart
Excessive looping will cause unexpected consumption of resources, such as CPU cycles or memory. The product's operation may slow down, or cause a long time to respond. If limited resources such as memory are consumed for each iteration, the loop may eventually cause a crash or program exit due to exhaustion of resources, such as an out-of-memory error.

Dynamic Analysis with Manual Results Interpretation

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Fuzz Tester
Framework-based Fuzzer
Forced Path Execution

SOAR Partial

Manual Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Cost effective for partial coverage:

Focused Manual Spotcheck - Focused manual analysis of source
Manual Source Code Review (not inspections)

SOAR Partial

Automated Static Analysis - Source Code

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Context-configured Source Code Weakness Analyzer

High

Architecture or Design Review

According to SOAR [REF-1479], the following detection techniques may be useful:

Highly cost effective:

Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)

High

In this example a mistake exists in the code where the exit condition contained in flg is never called. This results in the function calling itself over and over again until the stack is exhausted.

void do_something_recursive (int flg)
{

... // Do some real work here, but the value of flg is unmodified
if (flg) { do_something_recursive (flg); } // flg is never modified so it is always TRUE - this call will continue until the stack explodes

}
int flag = 1; // Set to TRUE
do_something_recursive (flag);

Note that the only difference between the Good and Bad examples is that the recursion flag will change value and cause the recursive call to return.

void do_something_recursive (int flg)
{

... // Do some real work here
// Modify value of flg on done condition
if (flg) { do_something_recursive (flg); } // returns when flg changes to 0

}
int flag = 1; // Set to TRUE
do_something_recursive (flag);

For this example, the method isReorderNeeded is part of a bookstore application that determines if a particular book needs to be reordered based on the current inventory count and the rate at which the book is being sold.

public boolean isReorderNeeded(String bookISBN, int rateSold) {

boolean isReorder = false;
int minimumCount = 10;int days = 0;

// get inventory count for book
int inventoryCount = inventory.getIventoryCount(bookISBN);

// find number of days until inventory count reaches minimum
while (inventoryCount > minimumCount) {

inventoryCount = inventoryCount - rateSold;days++;

}

// if number of days within reorder timeframe

// set reorder return boolean to true
if (days > 0 && days < 5) {isReorder = true;}
return isReorder;
}

However, the while loop will become an infinite loop if the rateSold input parameter has a value of zero since the inventoryCount will never fall below the minimumCount. In this case the input parameter should be validated to ensure that a value of zero does not cause an infinite loop, as in the following code.

public boolean isReorderNeeded(String bookISBN, int rateSold) {
...

// validate rateSold variable
if (rateSold < 1) {return isReorder;}
...
}

CVE-2011-1027
Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.
https://www.cve.org/CVERecord?id=CVE-2011-1027

CVE-2006-6499
Chain: web browser crashes due to infinite loop - "bad
looping logic [that relies on] floating point math [CWE-1339] to exit
the loop [CWE-835]"
https://www.cve.org/CVERecord?id=CVE-2006-6499

Discouraged
This CWE entry is a level-1 Class (i.e., a child of a Pillar). It might have lower-level children that would be more appropriate
Examine children of this entry to see if there is a better fit

CWE Content Team
MITRE
2011-03-22
1.12
2011-03-30

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Relationships, Taxonomy_Mappings

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

CWE Content Team
MITRE
2014-07-30
updated Detection_Factors

CWE Content Team
MITRE
2017-11-08
updated Relationships

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

CWE Content Team
MITRE
2020-02-24
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-07-20
updated Observed_Examples, Relationships

CWE Content Team
MITRE
2023-01-31
updated Common_Consequences, Description, Relationships

CWE Content Team
MITRE
2023-04-27
updated Relationships

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Observed_Examples

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Demonstrative_Examples, Mapping_Notes

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

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms, Time_of_Introduction, Weakness_Ordinalities