Run static analysis (SAST) on the codebase looking for the unsafe pattern in the data flow.
CWE-672 Class Draft
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.
Definition
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.
Real-world impact
Real-world CVEs caused by CWE-672
-
Chain: race condition (CWE-362) might allow resource to be released before operating on it, leading to NULL dereference (CWE-476)
How attackers exploit it
Step-by-step attacker path
- 1
The following code shows a simple example of a use after free error:
- 2
When an error occurs, the pointer is immediately freed. However, this pointer is later incorrectly used in the logError function.
- 3
The following code shows a simple example of a double free error:
- 4
Double free vulnerabilities have two common (and sometimes overlapping) causes:
- 5
- Error conditions and other exceptional circumstances - Confusion over which part of the program is responsible for freeing the memory
Vulnerable code example
Vulnerable C
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);
} Secure code example
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.
...
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.
Prevention checklist
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.
Detection signals
How to detect CWE-672
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-672 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-672?
How serious is CWE-672?
What languages or platforms are affected by CWE-672?
How can I prevent CWE-672?
How does Plexicus detect and fix CWE-672?
Where can I learn more about CWE-672?
Frequently asked questions
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.
How serious is CWE-672?
MITRE has not published a likelihood-of-exploit rating for this weakness. Treat it as medium-impact until your threat model proves otherwise.
What languages or platforms are affected by CWE-672?
MITRE lists the following affected platforms: Mobile.
How can I prevent 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.
How does Plexicus detect and fix CWE-672?
Plexicus's SAST engine matches the data-flow signature for CWE-672 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-672?
MITRE publishes the canonical definition at https://cwe.mitre.org/data/definitions/672.html. You can also reference OWASP and NIST documentation for adjacent guidance.
Related weaknesses
Weaknesses related to CWE-672
CWE-666 Parent
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 Sibling
Double Free
A double free vulnerability occurs when a program mistakenly calls the 'free()' function twice on the same block of memory.
CWE-593 Sibling
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 Sibling
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 Sibling
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 Child
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 Child
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 Child
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 Child
Insufficient Session Expiration
Insufficient session expiration occurs when an application allows old session tokens or IDs to remain valid for too long, letting…
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.