The product uses, accesses, or otherwise operates on a resource after that resource has been expired, released, or revoked.

What CVEs are caused by CWE-672?

42 recorded CVEs are attributed to CWE-672, including CVE-2026-43585, CVE-2013-10075, CVE-2025-39698.

How is CWE-672 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-672?

Exploiting CWE-672 can lead to: Modify Application Data, Read Application Data, Other, DoS: Crash, Exit, or Restart.

Is CWE-672 actively exploited?

42 recorded CVEs are caused by CWE-672; none are currently in CISA's KEV catalog of actively exploited flaws.

CWE-672: Operation on a Resource after Expiration or Release

High · CVSS 8.8 · EPSS 7th

Code examples

Illustrative examples from MITRE showing how the weakness appears in code.

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

Vulnerable example

char* ptr = (char*)malloc (SIZE);

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

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

Vulnerable example

char* ptr = (char*)malloc (SIZE);

In the following C/C++ example the method processMessage is used to process a message received in the input array of char arrays. The input message array contains two char arrays: the first is the length of the message and the second is the body of the message. The length of the message is retrieved and used to allocate enough memory for a local char array, messageBody, to be created for the message body. The messageBody is processed in the method processMessageBody that will return an error if an error occurs while processing. If an error occurs then the return result variable is set to indicate an error and the messageBody char array memory is released using the method free and an error message is sent to the logError method.

Vulnerable example

#define FAIL 0

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.

CWE-672: Operation on a Resource after Expiration or Release

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

Applies to

How to detect it

Automated Static Analysis

Code examples

Illustrative examples

Terminology & mappings

Mapped taxonomies

Frequently asked questions

What is CWE-672?

What CVEs are caused by CWE-672?

How is CWE-672 detected?

What are the consequences of CWE-672?

Is CWE-672 actively exploited?

References

Stay ahead of CWE-672

Overview

Real-world CVEs

Common consequences

How it happens

When it is introduced

Applies to

How to detect it

Automated Static Analysis

Code examples

Illustrative examples

Related weaknesses

Parent

Child

Related

Terminology & mappings

Mapped taxonomies

Frequently asked questions

What is CWE-672?

What CVEs are caused by CWE-672?

How is CWE-672 detected?

What are the consequences of CWE-672?

Is CWE-672 actively exploited?

References

Stay ahead of CWE-672