CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Last updated
Overview
CWE-772 (Missing Release of Resource after Effective Lifetime) is a base-level software weakness catalogued by MITRE in the Common Weakness Enumeration (CWE). It describes a recurring type of mistake that can lead to exploitable security vulnerabilities.
Real-world CVEs
71 recorded CVEs are caused by CWE-772 (Missing Release of Resource after Effective Lifetime), including 1 in CISA's KEV (Known Exploited Vulnerabilities) catalog. KEVs are shown first. 19 new CWE-772 CVEs have been recorded so far in 2026 (12 in 2025).
- CVE-2024-20481CISA KEVMedium · CVSS 5.8 · EPSS 97th2024-10-23
- CVE-2026-39830
Invoking client can cause server deadlock on unexpected responses in golang.org/x/crypto/ssh
Critical · CVSS 9.1 · EPSS 41th2026-05-22 - CVE-2020-14339High · CVSS 8.8 · EPSS 34th2020-12-03
- CVE-2026-39455
BIG-IP Configuration utility vulnerability
High · CVSS 8.7 · EPSS 22th2026-05-13 - CVE-2026-2359
Multer vulnerable to Denial of Service via resource exhaustion
High · CVSS 8.7 · EPSS 48th2026-02-27 - CVE-2025-22891
BIG-IP PEM Vulnerability
High · CVSS 8.7 · EPSS 32th2025-02-05 - CVE-2024-52303High · CVSS 8.7 · EPSS 43th2024-11-18
- CVE-2024-39562High · CVSS 8.7 · EPSS 35th2024-07-10
- CVE-2026-20082High · CVSS 8.6 · EPSS 33th2026-03-04
- CVE-2025-30256High · CVSS 8.6 · EPSS 29th2025-08-20
- CVE-2023-20095High · CVSS 8.6 · EPSS 47th2023-11-01
- CVE-2021-1523High · CVSS 8.6 · EPSS 68th2021-08-25
Showing 12 of 71 recorded CWE-772 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-772 vulnerabilitiesCommon consequences
What can happen when CWE-772 is exploited.
DoS: Resource Consumption (Other), DoS: Resource Consumption (Memory), DoS: Resource Consumption (CPU)
Affects: Availability
An attacker that can influence the allocation of resources that are not properly released could deplete the available resource pool and prevent all other processes from accessing the same type of resource. Frequently-affected resources include memory, CPU, disk space, power or battery, etc.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Technologies
How to prevent it
Practical mitigations for CWE-772, grouped by where in the lifecycle they apply.
Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems.
When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users.
Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
How to detect it
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.)
Effectiveness: High
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following method never closes the new file handle. Given enough time, the Finalize() method for BufferReader should eventually call Close(), but there is no guarantee as to how long this action will take. In fact, there is no guarantee that Finalize() will ever be invoked. In a busy environment, the Operating System could use up all of the available file handles before the Close() function is called.
Vulnerable example
private void processFile(string fName)Safe example
private void processFile(string fName)The good code example simply adds an explicit call to the Close() function when the system is done using the file. Within a simple example such as this the problem is easy to see and fix. In a real system, the problem may be considerably more obscure.
The following code attempts to open a new connection to a database, process the results returned by the database, and close the allocated SqlConnection object.
Vulnerable example
SqlConnection conn = new SqlConnection(connString);The problem with the above code is that if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.
This code attempts to open a connection to a database and catches any exceptions that may occur.
Vulnerable example
try {If an exception occurs after establishing the database connection and before the same connection closes, the pool of database connections may become exhausted. If the number of available connections is exceeded, other users cannot access this resource, effectively denying access to the application.
Under normal conditions the following C# code executes a database query, processes the results returned by the database, and closes the allocated SqlConnection object. But if an exception occurs while executing the SQL or processing the results, the SqlConnection object is not closed. If this happens often enough, the database will run out of available cursors and not be able to execute any more SQL queries.
The following C function does not close the file handle it opens if an error occurs. If the process is long-lived, the process can run out of file handles.
Vulnerable example
int decodeFile(char* fName) {Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2007-0897 — Chain: anti-virus product encounters a malformed file but returns from a function without closing a file descriptor (CWE-775) leading to file descriptor consumption (CWE-400) and failed scans.
- CVE-2001-0830 — Sockets not properly closed when attacker repeatedly connects and disconnects from server.
- CVE-1999-1127 — Does not shut down named pipe connections if malformed data is sent.
- CVE-2009-2858 — Chain: memory leak (CWE-404) leads to resource exhaustion.
- CVE-2009-2054 — Product allows exhaustion of file descriptors when processing a large number of TCP packets.
- CVE-2008-2122 — Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
- CVE-2007-4103 — Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
- CVE-2002-1372 — Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
Terminology & mappings
Mapped taxonomies
- CERT C Secure Coding: Close files when they are no longer needed (FIO42-C) — CWE More Abstract fit
- CERT C Secure Coding: Free dynamically allocated memory when no longer needed (MEM31-C) — CWE More Abstract fit
- OMG ASCSM (ASCSM-CWE-772)
- OMG ASCRM (ASCRM-CWE-772)
- Software Fault Patterns: Failure to Release Resource (SFP14)
Attack patterns
CAPEC attack patterns that exploit this weakness.
Frequently asked questions
Common questions about CWE-772.
- What is CWE-772?
- The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
- What CVEs are caused by CWE-772?
- 71 recorded CVEs are attributed to CWE-772, including CVE-2024-20481, CVE-2026-39830, CVE-2020-14339. 1 are listed in CISA's Known Exploited Vulnerabilities (KEV) catalog.
- How do you prevent CWE-772?
- Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- How is CWE-772 detected?
- 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.)
- What are the consequences of CWE-772?
- Exploiting CWE-772 can lead to: DoS: Resource Consumption (Other), DoS: Resource Consumption (Memory), DoS: Resource Consumption (CPU).
- Is CWE-772 actively exploited?
- Yes. 1 CWE-772 vulnerabilities are in CISA's KEV catalog of actively exploited flaws, out of 71 recorded CVEs.
References
- MITRE CWE definition (CWE-772) (opens in a new tab)
- CWE-772 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-772
Get alerted the moment a new CWE-772 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.