CWE-834: Excessive Iteration

Extended Description

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.

Code Examples & CVEs

Demonstrative Examples

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.

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.

BadC

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

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.

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.

GoodC

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.

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.

BadJava

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;                }

GoodJava

public boolean isReorderNeeded(String bookISBN, int rateSold) {                ...                                // validate rateSold variable                if (rateSold < 1) {return isReorder;}                ...                }

Observed CVE Examples (2)

CVE-2011-1027

Chain: off-by-one error (CWE-193) leads to infinite loop (CWE-835) using invalid hex-encoded characters.

View Details

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]"

View Details

Source-backed guidance

Additional facts reviewed against primary or authoritative security sources.

Detect Excessive Iteration with Dynamic Analysis with Manual Results Interpretation

Documented detection approaches include Dynamic Analysis with Manual Results Interpretation, Manual Static Analysis - Source Code, Automated Static Analysis - Source Code, and Architecture or Design Review; recorded impacts include DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Amplification, and DoS: Crash, Exit, or Restart; observed examples include CVE-2011-1027, and CVE-2006-6499. Use these source-defined anchors to turn CWE-834 into implementation, review, and verification checks for the affected component.

CWE-834: Excessive Iteration — MITRE CWE

Prevent CWE-834 through an SSDF control plan

Use NIST SSDF practices to make prevention of CWE-834, Excessive Iteration, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.

NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and Technology

Triage CWE-834 against known exploitation evidence

Use CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-834, Excessive Iteration, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.

Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security Agency

Apply precise root-cause mapping to CWE-834

Apply MITRE's full root-cause mapping guidance when using CWE-834, Excessive Iteration. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.

CVE to CWE Root Cause Mapping Guidance — MITRE CWE

Validate CWE-834 with root-cause mapping checks

Apply MITRE's root-cause mapping quick tips to CWE-834, Excessive Iteration. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.

CVE to CWE Root Cause Mapping Quick Tips — MITRE CWE

Frequently Asked Questions

What is CWE-834: Excessive Iteration?+

CWE-834: Excessive Iteration is a Common Weakness Enumeration (CWE) entry maintained by MITRE. 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.

What are the security consequences of Excessive Iteration?+

If exploited, CWE-834 (Excessive Iteration) it can compromise Availability, leading to outcomes such as DoS: Resource Consumption (CPU), DoS: Resource Consumption (Memory), DoS: Amplification and DoS: Crash, Exit, or Restart.

How is Excessive Iteration detected?+

CWE-834 can be detected using Dynamic Analysis with Manual Results Interpretation, Manual Static Analysis - Source Code, Automated Static Analysis - Source Code and Architecture or Design Review. Combining automated tooling with manual review typically yields the best coverage.

Which programming languages are affected by Excessive Iteration?+

CWE-834 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.

What are real-world examples of Excessive Iteration?+

MITRE documents real CVEs mapped to CWE-834, including CVE-2011-1027 and CVE-2006-6499. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.

What is the difference between a CWE and a CVE?+

A CWE (Common Weakness Enumeration) like CWE-834 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.

CWE-834: Excessive Iteration

Extended Description

Technical Details

Applicable To

Security Consequences

Scope

Impact

Mitigation Strategies

Detection Methods

Method

Description

Method

Description

Method

Description

Effectiveness

Method

Description

Effectiveness

Code Examples & CVEs

Demonstrative Examples

Observed CVE Examples (2)

CWE Relationships

Parent Weaknesses

Source-backed guidance

Detect Excessive Iteration with Dynamic Analysis with Manual Results Interpretation

Prevent CWE-834 through an SSDF control plan

Triage CWE-834 against known exploitation evidence

Apply precise root-cause mapping to CWE-834

Validate CWE-834 with root-cause mapping checks

Frequently Asked Questions

Learn More