The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release.
View on MITREResources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states. Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction."
No mitigation information available for this CWE.
Use Static analysis tools to check for unreleased resources.
This code allocates a socket and forks each time it receives a new connection.
The program does not track how many connections have been made, and it does not limit the number of connections. Because forking is a relatively expensive operation, an attacker would be able to cause the system to run out of CPU, processes, or memory by making a large number of connections. Alternatively, an attacker could consume all available connections, preventing others from accessing the system remotely.
sock=socket(AF_INET, SOCK_STREAM, 0);while (1) {newsock=accept(sock, ...);printf("A connection has been accepted\n");pid = fork();}Cryptography API uses unsafe reflection when deserializing a private key
View DetailsChain: Python library does not limit the resources used to process images that specify a very large number of bands (CWE-1284), leading to excessive memory consumption (CWE-789) or an integer overflow (CWE-190).
View DetailsNo relationship information available for this CWE.
Additional facts reviewed against primary or authoritative security sources.
Documented detection approaches include Automated Static Analysis; recorded impacts include Other; the entry maps to CAPEC-196, CAPEC-21, CAPEC-60, and CAPEC-61. Use these source-defined anchors to turn CWE-664 into implementation, review, and verification checks for the affected component.
CWE-664: Improper Control of a Resource Through its Lifetime — MITRE CWEUse NIST SSDF practices to make prevention of CWE-664, Improper Control of a Resource Through its Lifetime, an explicit development outcome. Translate the CWE definition into security requirements and design constraints, choose safer implementation patterns and toolchain checks, and define acceptance evidence before release. Feed every confirmed occurrence back into the requirements, design review, and coding rules so the same root cause is removed across the product rather than patched in one location.
NIST SP 800-218 Secure Software Development Framework — National Institute of Standards and TechnologyUse CISA's Known Exploited Vulnerabilities catalog to test whether a vulnerability mapped to CWE-664, Improper Control of a Resource Through its Lifetime, has evidence of exploitation in the wild. Confirm the CVE-to-CWE root-cause mapping independently before attaching the example, then capture the affected product, required action, and remediation deadline. A missing KEV match is not evidence that the weakness is unexploited, and a KEV entry must not be generalized to every occurrence of this CWE.
Known Exploited Vulnerabilities Catalog — Cybersecurity and Infrastructure Security AgencyApply MITRE's full root-cause mapping guidance when using CWE-664, Improper Control of a Resource Through its Lifetime. Separate weakness language from attacker prerequisites and technical impact, check the entry's abstraction and vulnerability-mapping notes, and prefer the most specific Base or Variant supported by the evidence. Record the rejected alternatives and require an independent review before the mapping is used for remediation trends or program metrics.
CVE to CWE Root Cause Mapping Guidance — MITRE CWEApply MITRE's root-cause mapping quick tips to CWE-664, Improper Control of a Resource Through its Lifetime. Confirm the finding describes the causal weakness rather than an impact or attack pattern, compare the abstraction and mapping notes with plausible alternatives, and have a second reviewer challenge the selection. Preserve the evidence and reasoning so recurring defects can be measured against one consistent identifier.
CVE to CWE Root Cause Mapping Quick Tips — MITRE CWECWE-664: Improper Control of a Resource Through its Lifetime is a Common Weakness Enumeration (CWE) entry maintained by MITRE. The product does not maintain or incorrectly maintains control over a resource throughout its lifetime of creation, use, and release. Resources often have explicit instructions on how to be created, used and destroyed. When code does not follow these instructions, it can lead to unexpected behaviors and potentially exploitable states. Even without explicit instructions, various principles are expected to be adhered to, such as "Do not use an object until after its creation is complete," or "do not use an object after it has been slated for destruction."
If exploited, CWE-664 (Improper Control of a Resource Through its Lifetime) it can compromise Other, leading to outcomes such as Other.
CWE-664 can be detected using Automated Static Analysis. Combining automated tooling with manual review typically yields the best coverage.
CWE-664 commonly affects Not Language-Specific. Note that weaknesses are often language-agnostic patterns, so secure coding practices apply broadly.
MITRE documents real CVEs mapped to CWE-664, including CVE-2018-1000613 and CVE-2019-19911. You can look up the full details of each CVE, including CVSS scores and remediation guidance, on our CVE Lookup tool.
A CWE (Common Weakness Enumeration) like CWE-664 describes a category of software weakness — the underlying flaw type. A CVE (Common Vulnerabilities and Exposures) identifies a specific, real-world vulnerability in a particular product. In short, a CWE is the kind of mistake, and a CVE is an instance of that mistake being found in software.