Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-772 Base Draft
Missing Release of Resource after Effective Lifetime
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation…
Definition
What is CWE-772?
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation of unused resources, known as a resource leak.
Resource leaks happen when developers allocate resources but forget to include the cleanup logic, or when errors and exceptions prevent cleanup code from running. Common culprits include not closing database connections, leaving files open after reading, or not freeing memory in languages without automatic garbage collection. Over time, these leaks degrade performance and can cause the application to crash when it exhausts a critical resource like available file handles or memory.
To prevent this, developers should adopt patterns that guarantee cleanup, such as using try-finally blocks or modern language constructs like 'using' statements (C#) or 'try-with-resources' (Java). It's also crucial to audit code for all resource allocation points, ensure every 'open' or 'allocate' has a corresponding 'close' or 'free' in all execution paths, and leverage static analysis tools to detect potential leaks during development.
Real-world impact
Real-world CVEs caused by CWE-772
-
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.
-
Sockets not properly closed when attacker repeatedly connects and disconnects from server.
-
Does not shut down named pipe connections if malformed data is sent.
-
Chain: memory leak (CWE-404) leads to resource exhaustion.
-
Product allows exhaustion of file descriptors when processing a large number of TCP packets.
-
Port scan triggers CPU consumption with processes that attempt to read data from closed sockets.
-
Product allows resource exhaustion via a large number of calls that do not complete a 3-way handshake.
-
Chain: Return values of file/socket operations are not checked (CWE-252), allowing resultant consumption of file descriptors (CWE-772).
How attackers exploit it
Step-by-step attacker path
- 1
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.
- 2
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.
- 3
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.
- 4
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.
- 5
This code attempts to open a connection to a database and catches any exceptions that may occur.
Vulnerable code example
Vulnerable Java
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.
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
} Secure code example
Secure Java
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.
private void processFile(string fName)
{
BufferReader fil = new BufferReader(new FileReader(fName));
String line;
while ((line = fil.ReadLine()) != null)
{
processLine(line);
}
fil.Close();
} What changed: the unsafe sink is replaced (or the input is validated/escaped) so the same payload no longer triggers the weakness.
Prevention checklist
How to prevent CWE-772
- Requirements 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.
- Implementation 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.
- Operation / Architecture and Design 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).
Detection signals
How to detect CWE-772
Run dynamic application security testing against the live endpoint.
Watch runtime logs for unusual exception traces, malformed input, or authorization bypass attempts.
Code review: flag any new code that handles input from this surface without using the validated framework helpers.
Plexicus auto-detects CWE-772 and opens a fix PR in under 60 seconds.
Codex Remedium scans every commit, identifies this exact weakness, and ships a reviewer-ready pull request with the patch. No tickets. No hand-offs.
Frequently asked questions What is CWE-772?
How serious is CWE-772?
What languages or platforms are affected by CWE-772?
How can I prevent CWE-772?
How does Plexicus detect and fix CWE-772?
Where can I learn more about CWE-772?
Frequently asked questions
What is CWE-772?
This vulnerability occurs when a program fails to properly release a system resource—like memory, file handles, or network sockets—after it is no longer needed. This leads to a gradual accumulation of unused resources, known as a resource leak.
How serious is CWE-772?
MITRE rates the likelihood of exploit as High — this weakness is actively exploited in the wild and should be prioritized for remediation.
What languages or platforms are affected by CWE-772?
MITRE lists the following affected platforms: Mobile.
How can I prevent CWE-772?
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…
How does Plexicus detect and fix CWE-772?
Plexicus's SAST engine matches the data-flow signature for CWE-772 on every commit. When a match is found, our Codex Remedium agent opens a fix PR with the corrected code, tests, and a one-line summary for the reviewer.
Where can I learn more about CWE-772?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/772.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-772
CWE-404 Parent
Improper Resource Shutdown or Release
This vulnerability occurs when a program fails to properly close or release a system resource—like a file handle, database connection, or…
CWE-1266 Sibling
Improper Scrubbing of Sensitive Data from Decommissioned Device
This vulnerability occurs when a system lacks a reliable method for administrators to permanently erase sensitive information before…
CWE-299 Sibling
Improper Check for Certificate Revocation
This vulnerability occurs when an application fails to properly verify whether a security certificate has been revoked, potentially…
CWE-401 Sibling
Missing Release of Memory after Effective Lifetime
This vulnerability occurs when a program allocates memory but fails to properly release it after it's no longer needed, causing a gradual…
CWE-459 Sibling
Incomplete Cleanup
This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they…
CWE-761 Sibling
Free of Pointer not at Start of Buffer
This vulnerability occurs when a program incorrectly frees a memory pointer that no longer points to the beginning of the allocated heap…
CWE-762 Sibling
Mismatched Memory Management Routines
This vulnerability occurs when a program uses incompatible functions to allocate and free memory. For example, freeing memory with a…
CWE-763 Sibling
Release of Invalid Pointer or Reference
This vulnerability occurs when a program tries to free a memory resource back to the system but uses an incorrect deallocation method or…
CWE-775 Sibling
Missing Release of File Descriptor or Handle after Effective Lifetime
This vulnerability occurs when a program fails to properly close file descriptors or handles after they are no longer needed, leaving…
Ready when you are
Don't Let Security
Weigh You Down.
Stop choosing between AI velocity and security debt. Plexicus is the only platform that runs Vibe Coding Security and ASPM in parallel — one workflow, every codebase.