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

Primary

Resultant

Implementation

Operation

Integrity
Confidentiality
Modify Application Data
Read Application Data
If a released resource is subsequently reused or reallocated, then an attempt to use the original resource might allow access to sensitive data that is associated with a different user or entity.

Other
Availability
Other
DoS: Crash, Exit, or Restart
When a resource is released it might not be in an expected state, later attempts to access the resource may lead to resultant errors that may lead to a crash.

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.)
High

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

char* ptr = (char*)malloc (SIZE);if (err) {abrt = 1;free(ptr);}...if (abrt) {logError("operation aborted before commit", ptr);}

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:

char* ptr = (char*)malloc (SIZE);...if (abrt) {free(ptr);}...free(ptr);

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

Error conditions and other exceptional circumstances

Confusion over which part of the program is responsible for freeing the memory

Although some double free vulnerabilities are not much more complicated than the previous example, most are spread out across hundreds of lines of code or even different files. Programmers seem particularly susceptible to freeing global variables more than once.

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.

#define FAIL 0#define SUCCESS 1#define ERROR -1#define MAX_MESSAGE_SIZE 32
int processMessage(char **message){
int result = SUCCESS;
int length = getMessageLength(message[0]);char *messageBody;
if ((length > 0) && (length < MAX_MESSAGE_SIZE)) {

messageBody = (char*)malloc(length*sizeof(char));messageBody = &message[1][0];
int success = processMessageBody(messageBody);
if (success == ERROR) {result = ERROR;free(messageBody);}
}else {printf("Unable to process message; invalid message length");result = FAIL;}
if (result == ERROR) {logError("Error processing message", messageBody);}
return result;
}

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.

...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);}...

CVE-2009-3547
Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
https://www.cve.org/CVERecord?id=CVE-2009-3547

SFP15
Faulty Resource Use

FIO46-C
Do not access a closed file
CWE More Abstract

MEM30-C
Do not access freed memory
CWE More Abstract

ASCSM-CWE-672

Allowed-with-Review
This CWE entry is a Class and might have Base-level children that would be more appropriate
Examine children of this entry to see if there is a better fit

CWE Content Team
MITRE
2008-04-11
Draft 9
2008-04-11

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships

CWE Content Team
MITRE
2010-02-16
updated Demonstrative_Examples, Description, Name, Relationships

CWE Content Team
MITRE
2010-09-27
updated Observed_Examples, Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, Demonstrative_Examples, Relationships

CWE Content Team
MITRE
2013-02-21
updated Relationships

CWE Content Team
MITRE
2014-02-18
updated Applicable_Platforms

CWE Content Team
MITRE
2014-07-30
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-11-08
updated Demonstrative_Examples, Taxonomy_Mappings

CWE Content Team
MITRE
2019-01-03
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2019-06-20
updated Relationships, Type

CWE Content Team
MITRE
2020-02-24
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2020-12-10
updated Relationships

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2023-01-31
updated Description

CWE Content Team
MITRE
2023-04-27
updated Relationships, Time_of_Introduction

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2023-10-26
updated Observed_Examples

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Detection_Factors, Weakness_Ordinalities

Use of a Resource after Expiration or Release