What it is: Operation on a Resource after Expiration or Release (CWE-672) is a vulnerability where an application continues to use resources that have been expired, released, or revoked.
Why it matters: This can lead to unauthorized access and data corruption, compromising the integrity and availability of sensitive information.
How to fix it: Ensure proper lifecycle management of all resources and validate their state before reuse.
TL;DR: Operation on a Resource after Expiration or Release (CWE-672) is a high-severity vulnerability where applications continue using expired or released resources, leading to potential data breaches. Proper resource lifecycle management can prevent this.
| Field | Value |
|---|---|
| CWE ID | CWE-672 |
| OWASP Category | Not directly mapped |
| CAPEC | None known |
| Typical Severity | High |
| Affected Technologies | Java, Python, Node.js, PHP |
| Detection Difficulty | Moderate |
| Last Updated | 2026-07-29 |
What is Operation on a Resource after Expiration or Release?
Operation on a Resource after Expiration or Release (CWE-672) is a type of vulnerability where an application continues to use resources that have been expired, released, or revoked. As defined by the MITRE Corporation under CWE-672, and classified by the OWASP Foundation under A05:2025 - Security Misconfiguration.
Quick Summary
Operation on a Resource after Expiration or Release is high severity because it allows attackers to manipulate resources post-release, leading to potential data breaches and system instability. This vulnerability can be detected through code reviews and automated scanners that check resource management logic.
Jump to: Quick Summary · Operation on a Resource after Expiration or Release Overview · How Operation on a Resource after Expiration or Release Works · Business Impact of Operation on a Resource after Expiration or Release · Operation on a Resource after Expiration or Release Attack Scenario · How to Detect Operation on a Resource after Expiration or Release · How to Fix Operation on a Resource after Expiration or Release · Framework-Specific Fixes for Operation on a Resource after Expiration or Release · How to Ask AI to Check Your Code for Operation on a Resource after Expiration or Release · Operation on a Resource after Expiration or Release Best Practices Checklist · Operation on a Resource after Expiration or Release FAQ · Vulnerabilities Related to Operation on a Resource after Expiration or Release · References · Scan Your Own Site
Operation on a Resource after Expiration or Release Overview
What
Operation on a Resource after Expiration or Release is when an application continues to use resources that have been expired, released, or revoked.
Why it matters
This can lead to unauthorized access and data corruption, compromising the integrity and availability of sensitive information.
Where it occurs
It commonly occurs in applications with poor resource management practices, such as database connections being reused after release.
Who is affected
Developers and organizations using languages like Java, Python, Node.js, and PHP are at risk if they do not properly manage resource lifecycles.
Who is NOT affected
Applications that strictly enforce resource lifecycle rules and validate resource states before reuse are not vulnerable to this issue.
How Operation on a Resource after Expiration or Release Works
Root Cause
The root cause lies in the application’s failure to properly handle resource expiration, leading to continued use of resources post-release.
Attack Flow
- An attacker identifies an expired resource.
- The attacker accesses the resource and manipulates it.
- This leads to unauthorized access or data corruption.
Prerequisites to Exploit
- Resources must be accessible after release.
- No validation checks for resource state before reuse.
Vulnerable Code
def handle_request(request):
connection = get_database_connection()
# Use the connection...
return response
This code does not validate the state of connection before use, leading to potential misuse of expired resources.
Secure Code
def handle_request(request):
connection = get_database_connection()
if is_valid(connection):
# Use the connection...
pass
else:
raise ValueError("Connection has been released")
The secure version checks the validity of connection before use, ensuring it is not expired or revoked.
Business Impact of Operation on a Resource after Expiration or Release
Confidentiality
- Unauthorized access to sensitive data.
- Exposure of confidential information through leaked resources.
Integrity
- Data corruption due to manipulation of expired resources.
- Inconsistent state leading to incorrect application behavior.
Availability
- System instability and crashes from accessing invalid resources.
- Denial of service when critical resources are misused post-release.
Operation on a Resource after Expiration or Release Attack Scenario
- An attacker identifies an expired database connection.
- The attacker accesses the connection and reads sensitive data.
- This leads to unauthorized access and potential data breaches.
- System instability occurs due to misuse of invalid connections.
- Application crashes result from attempting to use expired resources.
How to Detect Operation on a Resource after Expiration or Release
Manual Testing
- Check if resource management logic properly handles expiration.
- Ensure validation checks are in place before resource reuse.
- Verify that released resources are not accessible post-release.
Automated Scanners (SAST / DAST)
Static analysis can detect missing validation checks, while dynamic testing verifies actual behavior during runtime.
PenScan Detection
PenScan’s engines like ZAP and Nuclei help identify potential CWE-672 vulnerabilities by scanning for improper resource handling logic.
False Positive Guidance
False positives occur when the pattern looks risky but is actually safe due to context a scanner cannot determine. Ensure validation checks are in place before marking as false positive.
How to Fix Operation on a Resource after Expiration or Release
- Implement robust lifecycle management of all resources.
- Validate resource states before reuse.
- Enforce proper release and cleanup procedures for expired resources.
- Use secure coding practices to prevent misuse of released resources.
Framework-Specific Fixes for Operation on a Resource after Expiration or Release
Java
public void handleRequest(HttpServletRequest request) {
Connection connection = getDatabaseConnection();
if (connection.isValid(5)) {
// Use the connection...
} else {
throw new IllegalStateException("Connection has been released");
}
}
Python/Django
def handle_request(request):
connection = get_database_connection()
if connection.is_valid():
# Use the connection...
pass
else:
raise ValueError("Connection has been released")
PHP
function handleRequest($request) {
$connection = getDatabaseConnection();
if ($connection->isValid()) {
// Use the connection...
} else {
throw new Exception('Connection has been released');
}
}
How to Ask AI to Check Your Code for Operation on a Resource after Expiration or Release
Review the following [language] code block for potential CWE-672 Operation on a Resource after Expiration or Release vulnerabilities and rewrite it using proper validation checks: [paste code here]
Operation on a Resource after Expiration or Release Best Practices Checklist
✅ Implement robust lifecycle management of all resources. ✅ Validate resource states before reuse. ✅ Enforce proper release and cleanup procedures for expired resources. ✅ Use secure coding practices to prevent misuse of released resources. ✅ Conduct regular code reviews focusing on resource handling logic. ✅ Integrate automated scanners to detect potential CWE-672 vulnerabilities.
Operation on a Resource after Expiration or Release FAQ
How does Operation on a Resource after Expiration or Release occur?
It occurs when an application continues to use a resource that has been expired, released, or revoked. This can lead to unauthorized access and data corruption.
Why is Operation on a Resource after Expiration or Release considered high severity?
High severity because it allows attackers to manipulate resources post-release, leading to potential data breaches and system instability.
How does an attacker exploit this vulnerability?
An attacker can exploit this by accessing resources that should have been released, potentially reading sensitive information or causing a denial of service.
Can you provide real-world examples of Operation on a Resource after Expiration or Release?
Real-world examples include database connections being reused after release or network sockets remaining open and accessible to unauthorized users.
How can I detect Operation on a Resource after Expiration or Release in my code?
Detect it by reviewing resource management logic for improper handling of expired resources, such as checking if a connection is still valid before reuse.
What are the best practices to prevent Operation on a Resource after Expiration or Release?
Ensure proper lifecycle management of all resources and validate their state before reuse. Implement robust checks to ensure resources are not used post-release.
How can I ask AI to check my code for Operation on a Resource after Expiration or Release?
Use an AI coding assistant to review your resource handling logic and verify that expired resources are properly released and not reused.
Vulnerabilities Related to Operation on a Resource after Expiration or Release
| CWE | Name | Relationship |
|---|---|---|
| CWE-666 | Operation on Resource in Wrong Phase of Lifetime | ChildOf |
References
Scan Your Own Site
Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find Operation on a Resource after Expiration or Release and other risks before an attacker does.