CWE-672 Clase Borrador

Operation on a Resource after Expiration or Release

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.

Definición

What is CWE-672?

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.
Think of this as using a hotel key card after you've checked out. The system has marked that resource as available for reuse, but your code still holds a reference to it. When you try to read, write, or execute operations using this 'stale' reference, the results are unpredictable. The program might crash, leak sensitive data from the now-reallocated memory, or allow an attacker to hijack the resource for their own purposes. To prevent this, developers must carefully manage the lifecycle of all resources. This means ensuring that every 'malloc' has a matching 'free', every 'open' has a 'close', and that pointers or handles are set to NULL or another invalid state immediately after release. Using modern language features like smart pointers in C++ or try-with-resources in Java can automate this cleanup and make these dangerous 'use-after-free' and 'use-after-close' errors much less likely.
Impacto en el mundo real

Real-world CVEs caused by CWE-672

  • CVE-2009-3547

    Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)

Cómo lo explotan los atacantes

Ruta del atacante paso a paso

  1. 1

    The following code shows a simple example of a use after free error:

  2. 2

    When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.

  3. 3

    The following code shows a simple example of a double free error:

  4. 4

    Double free vulnerabilities have two common (and sometimes overlapping) causes:

  5. 5

    - Error conditions and other exceptional circumstances - Confusion over which part of the program is responsible for freeing the memory

Ejemplo de código vulnerable

Vulnerable C

The following code shows a simple example of a use after free error:

Vulnerable C 
char* ptr = (char*)malloc (SIZE);
  if (err) {
  	abrt = 1;
  	free(ptr);
  }
  ...
  if (abrt) {
  	logError("operation aborted before commit", ptr);
  }
Ejemplo de código seguro

Secure C

However, the call to the method logError includes the messageBody after the memory for messageBody has been released using the free method. This can cause unexpected results and may lead to system crashes. A variable should never be used after its memory resources have been released.

Seguro C 
...
  messageBody = (char*)malloc(length*sizeof(char));
  messageBody = &message[1][0];
  int success = processMessageBody(messageBody);
  if (success == ERROR) {
  	result = ERROR;
  	logError("Error processing message", messageBody);
  	free(messageBody);
  }
  ...
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-672

  • Architecture Use safe-by-default frameworks and APIs that prevent the unsafe pattern from being expressible.
  • Implementation Validate input at trust boundaries; use allowlists, not denylists.
  • Implementation Apply the principle of least privilege to credentials, file paths, and runtime permissions.
  • Testing Cover this weakness in CI: SAST rules + targeted unit tests for the data flow.
  • Operation Monitor logs for the runtime signals listed in the next section.
Señales de detección

How to detect CWE-672

SAST High

Ejecuta análisis estático (SAST) sobre el código buscando el patrón inseguro en el flujo de datos.

DAST Moderate

Ejecuta pruebas dinámicas de seguridad de aplicaciones (DAST) contra el endpoint en vivo.

Runtime Moderate

Vigila los logs en tiempo de ejecución para detectar trazas de excepción inusuales, entradas malformadas o intentos de bypass de autorización.

Code review Moderate

Revisión de código: marca cualquier código nuevo que maneje entrada desde esta superficie sin usar los helpers validados del framework.

Auto-corrección de Plexicus

Plexicus detecta automáticamente CWE-672 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.

Solicitar demo Probar Plexicus gratis
Preguntas frecuentes

Frequently asked questions

¿Qué es CWE-672?

This vulnerability occurs when a program continues to use a resource—like memory, a file handle, or a network connection—after it has been freed, closed, or is no longer valid.

¿Qué gravedad tiene CWE-672?

MITRE no ha publicado una calificación de probabilidad de explotación para esta debilidad. Trátala como de impacto medio hasta que tu modelo de amenazas demuestre lo contrario.

¿Qué lenguajes o plataformas se ven afectados por CWE-672?

MITRE lists the following affected platforms: Mobile.

¿Cómo puedo prevenir CWE-672?

Use safe-by-default frameworks, validate untrusted input at trust boundaries, and apply the principle of least privilege. Cover the data-flow signature in CI with SAST.

¿Cómo detecta y corrige Plexicus CWE-672?

El motor SAST de Plexicus detecta la firma de flujo de datos para CWE-672 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-672?

MITRE publica la definición canónica en https://cwe.mitre.org/data/definitions/672.html. También puedes consultar la documentación de OWASP y NIST para guías relacionadas.

Debilidades relacionadas

Weaknesses related to CWE-672

CWE-666 Padre

Operation on Resource in Wrong Phase of Lifetime

This vulnerability occurs when software interacts with a resource—like memory, a file, or a network connection—at an incorrect stage of…

CWE-415 Hermano

Double Free

A double free vulnerability occurs when a program mistakenly calls the 'free()' function twice on the same block of memory.

CWE-593 Hermano

Authentication Bypass: OpenSSL CTX Object Modified after SSL Objects are Created

This vulnerability occurs when an application modifies an OpenSSL context object after it has already been used to create active SSL/TLS…

CWE-605 Hermano

Multiple Binds to the Same Port

This vulnerability occurs when a system's socket configuration allows multiple applications to bind to the same network port…

CWE-826 Hermano

Premature Release of Resource During Expected Lifetime

This happens when software incorrectly frees or closes a resource—like memory, a file handle, or a network connection—while that resource…

CWE-298 Hijo

Improper Validation of Certificate Expiration

This vulnerability occurs when an application fails to properly check if a digital certificate has expired, potentially trusting…

CWE-324 Hijo

Use of a Key Past its Expiration Date

This vulnerability occurs when an application continues to use a cryptographic key or password after its designated expiration date. Doing…

CWE-416 Hijo

Use After Free

Use After Free happens when a program continues to use a pointer to a memory location after that memory has been freed. This can lead to…

CWE-613 Hijo

Insufficient Session Expiration

Insufficient session expiration occurs when an application allows old session tokens or IDs to remain valid for too long, letting…

Recursos

Further reading

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.

Comenzar gratis Reservar una demo