CWE-666: Operation on Resource in Wrong Phase of Lifetime
The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
Last updated
Overview
A resource's lifecycle includes several phases: initialization, use, and release. For each phase, it is important to follow the specifications outlined for how to operate on the resource and to ensure that the resource is in the expected phase. Otherwise, if a resource is in one phase but the operation is not valid for that phase (i.e., an incorrect phase of the resource's lifetime), then this can produce resultant weaknesses. For example, using a resource before it has been fully initialized could cause corruption or incorrect data to be used.
Common consequences
What can happen when CWE-666 is exploited.
Other
Affects: Other
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
How to prevent it
Practical mitigations for CWE-666, grouped by where in the lifecycle they apply.
Follow the resource's lifecycle from creation to release.
How to detect it
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.)
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
The following code shows a simple example of a double free vulnerability.
Vulnerable example
char* ptr = (char*)malloc (SIZE);Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2006-5051 — Chain: Signal handler contains too much functionality (CWE-828), introducing a race condition (CWE-362) that leads to a double free (CWE-415).
Terminology & mappings
Mapped taxonomies
- CERT C Secure Coding: Do not access a closed file (FIO46-C) — CWE More Abstract fit
- CERT C Secure Coding: Do not access freed memory (MEM30-C) — CWE More Abstract fit
Frequently asked questions
Common questions about CWE-666.
- What is CWE-666?
- The product performs an operation on a resource at the wrong phase of the resource's lifecycle, which can lead to unexpected behaviors.
- How do you prevent CWE-666?
- Follow the resource's lifecycle from creation to release.
- How is CWE-666 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-666?
- Exploiting CWE-666 can lead to: Other.
References
- MITRE CWE definition (CWE-666) (opens in a new tab)
- CWE-666 vulnerabilities on NVD (opens in a new tab)
- Learn: What is a CWE?
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Stay ahead of CWE-666
Get alerted the moment a new CWE-666 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.