The product does not properly control the amount of recursion that takes place, consuming excessive resources, such as allocated memory or the program stack.

Primary

Resultant

Stack Exhaustion

Implementation
The uncontrolled recursion is often due to an improper or missing conditional

Availability
DoS: Resource Consumption (CPU)
DoS: Resource Consumption (Memory)
Resources including CPU, memory, and stack memory could be rapidly consumed or exhausted, eventually leading to an exit or crash.

Confidentiality
Read Application Data
In some cases, an application's interpreter might kill a process or thread that appears to be consuming too much resources, such as with PHP's memory_limit setting. When the interpreter kills the process/thread, it might report an error containing detailed information such as the application's installation path.

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

Implementation
Ensure an end condition will be reached under all logic conditions. The end condition may include testing against the depth of recursion and exiting with an error if the recursion goes too deep. The complexity of the end condition contributes to the effectiveness of this action.
Moderate

Implementation
Increase the stack size.
Limited
Increasing the stack size might only be a temporary measure, since the stack typically is still not very large, and it might remain easy for attackers to cause an out-of-stack fault.

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

CVE-2007-1285
Deeply nested arrays trigger stack exhaustion.
https://www.cve.org/CVERecord?id=CVE-2007-1285

CVE-2007-3409
Self-referencing pointers create infinite loop and resultant stack exhaustion.
https://www.cve.org/CVERecord?id=CVE-2007-3409

CVE-2016-10707
Javascript application accidentally changes input in a way that prevents a recursive call from detecting an exit condition.
https://www.cve.org/CVERecord?id=CVE-2016-10707

CVE-2016-3627
An attempt to recover a corrupted XML file infinite recursion protection counter was not always incremented missing the exit condition.
https://www.cve.org/CVERecord?id=CVE-2016-3627

CVE-2019-15118
USB-audio driver's descriptor code parsing allows unlimited recursion leading to stack exhaustion.
https://www.cve.org/CVERecord?id=CVE-2019-15118

CPU

A9
Denial of Service
CWE More Specific

SFP13
Unrestricted Consumption

ASCRM-CWE-674

Allowed-with-Review
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit

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 Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-03-10
updated Related_Attack_Patterns

CWE Content Team
MITRE
2011-03-29
updated Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Relationships

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2013-02-21
updated Relationships

CWE Content Team
MITRE
2014-02-18
updated Related_Attack_Patterns

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2019-01-03
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings

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

CWE Content Team
MITRE
2020-02-24
updated Related_Attack_Patterns, Relationships

CWE Content Team
MITRE
2020-12-10
updated Demonstrative_Examples, Description, Modes_of_Introduction, Observed_Examples, Potential_Mitigations, Time_of_Introduction

CWE Content Team
MITRE
2021-03-15
updated Potential_Mitigations

CWE Content Team
MITRE
2022-10-13
updated Demonstrative_Examples

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

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

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

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