Ejecuta análisis estático (SAST) sobre el código buscando el patrón inseguro en el flujo de datos.
CWE-772 Base Borrador
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…
Definición
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.
Impacto en el mundo real
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).
Cómo lo explotan los atacantes
Ruta del atacante paso a paso
- 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.
Ejemplo de código vulnerable
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);
}
} Ejemplo de código seguro
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.
Lista de prevención
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).
Señales de detección
How to detect CWE-772
Ejecuta pruebas dinámicas de seguridad de aplicaciones (DAST) contra el endpoint en vivo.
Vigila los logs en tiempo de ejecución para detectar trazas de excepción inusuales, entradas malformadas o intentos de bypass de autorización.
Revisión de código: marca cualquier código nuevo que maneje entrada desde esta superficie sin usar los helpers validados del framework.
Plexicus detecta automáticamente CWE-772 y abre un PR de corrección en menos de 60 segundos.
Codex Remedium escanea cada commit, identifica esta debilidad concreta y entrega un pull request listo para revisión con el parche. Sin tickets. Sin traspasos.
Preguntas frecuentes ¿Qué es CWE-772?
¿Qué gravedad tiene CWE-772?
¿Qué lenguajes o plataformas se ven afectados por CWE-772?
¿Cómo puedo prevenir CWE-772?
¿Cómo detecta y corrige Plexicus CWE-772?
¿Dónde puedo aprender más sobre CWE-772?
Frequently asked questions
¿Qué es 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.
¿Qué gravedad tiene CWE-772?
MITRE califica la probabilidad de explotación como Alta — esta debilidad se explota activamente en la práctica y debe priorizarse para su remediación.
¿Qué lenguajes o plataformas se ven afectados por CWE-772?
MITRE lists the following affected platforms: Mobile.
¿Cómo puedo prevenir 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…
¿Cómo detecta y corrige Plexicus CWE-772?
El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-772 en cada commit. Cuando hay coincidencia, nuestro agente Codex Remedium abre un PR de corrección con el código corregido, las pruebas y un resumen de una línea para el revisor.
¿Dónde puedo aprender más sobre CWE-772?
MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/772.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.
Debilidades relacionadas
Weaknesses related to CWE-772
CWE-404 Padre
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 Hermano
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 Hermano
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 Hermano
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 Hermano
Incomplete Cleanup
This vulnerability occurs when an application fails to properly remove temporary files, data structures, or system resources after they…
CWE-761 Hermano
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 Hermano
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 Hermano
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 Hermano
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…
Listo cuando tú lo estés
Deja de pagar por desarrollador.
Empieza a cerrar el bucle.
Plexicus es el ASPM nativo de IA que escanea, filtra, corrige, pentestea y explica — de forma autónoma. Desarrolladores ilimitados, repos ilimitados, acciones de IA de uso justo. Nivel gratuito real, €269/mo anual cuando estés listo.