The product does not sufficiently track and release allocated memory after it has been used, making the memory unavailable for reallocation and reuse.

Resultant

Memory Leak

Implementation

Memory leaks have two common and sometimes overlapping causes:

Error conditions and other exceptional circumstances often triggered by improper handling of malformed data or unexpectedly interrupted sessions.
Confusion over which part of the program is responsible for freeing the memory, since in some languages, developers are responsible for tracking memory allocation and releasing the memory. If there are no more pointers or references to the memory, then it can no longer be tracked and identified for release.

Medium

Availability
DoS: Crash, Exit, or Restart
DoS: Instability
DoS: Resource Consumption (CPU)
DoS: Resource Consumption (Memory)
Most memory leaks result in general product reliability problems, but if an attacker can intentionally trigger a memory leak, the attacker might be able to launch a denial of service attack (by crashing or hanging the program) or take advantage of other unexpected program behavior resulting from a low memory condition.

Other
Reduce Performance

Fuzzing
Fuzz testing (fuzzing) is a powerful technique for generating large numbers of diverse inputs - either randomly or algorithmically - and dynamically invoking the code with those inputs. Even with random inputs, it is often capable of generating unexpected results such as crashes, memory corruption, or resource consumption. Fuzzing effectively produces repeatable test cases that clearly indicate bugs, which helps developers to diagnose the issues.
High

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

Implementation
Libraries or Frameworks

Choose a language or tool that provides automatic memory management, or makes manual memory management less error-prone.
For example, glibc in Linux provides protection against free of invalid pointers.
When using Xcode to target OS X or iOS, enable automatic reference counting (ARC) [REF-391].
To help correctly and consistently manage memory when programming in C++, consider using a smart pointer class such as std::auto_ptr (defined by ISO/IEC ISO/IEC 14882:2003), std::shared_ptr and std::unique_ptr (specified by an upcoming revision of the C++ standard, informally referred to as C++ 1x), or equivalent solutions such as Boost.

Architecture and Design
Use an abstraction library to abstract away risky APIs. Not a complete solution.

Architecture and Design
Build and Compilation
The Boehm-Demers-Weiser Garbage Collector or valgrind can be used to detect leaks in code.
This is not a complete solution as it is not 100% effective.

The following C function leaks a block of allocated memory if the call to read() does not return the expected number of bytes:

char* getBlock(int fd) {
char* buf = (char*) malloc(BLOCK_SIZE);if (!buf) {return NULL;}if (read(fd, buf, BLOCK_SIZE) != BLOCK_SIZE) {

return NULL;
}return buf;
}

CVE-2005-3119
Memory leak because function does not free() an element of a data structure.
https://www.cve.org/CVERecord?id=CVE-2005-3119

CVE-2004-0427
Memory leak when counter variable is not decremented.
https://www.cve.org/CVERecord?id=CVE-2004-0427

CVE-2002-0574
chain: reference count is not decremented, leading to memory leak in OS by sending ICMP packets.
https://www.cve.org/CVERecord?id=CVE-2002-0574

CVE-2005-3181
Kernel uses wrong function to release a data structure, preventing data from being properly tracked by other code.
https://www.cve.org/CVERecord?id=CVE-2005-3181

CVE-2004-0222
Memory leak via unknown manipulations as part of protocol test suite.
https://www.cve.org/CVERecord?id=CVE-2004-0222

CVE-2001-0136
Memory leak via a series of the same command.
https://www.cve.org/CVERecord?id=CVE-2001-0136

Memory Management

Memory

Memory leak

Memory Leak

Failure to deallocate data

A9
Denial of Service
CWE More Specific

MEM31-C
Free dynamically allocated memory when no longer needed
Exact

MSC04-J
Do not leak memory

SFP14
Failure to Release Resource

ASCPEM-PRF-14

Allowed
This CWE entry is at the Variant level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

This is often a resultant weakness due to improper handling of malformed data or early termination of sessions.
"memory leak" has sometimes been used to describe other kinds of issues, e.g. for information leaks in which the contents of memory are inadvertently leaked (CVE-2003-0400 is one such example of this terminology conflict).

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

KDM Analytics
2008-08-01
added/updated white box definitions

Veracode
2008-08-15
Suggested OWASP Top Ten 2004 mapping

CWE Content Team
MITRE
2008-09-08
updated Applicable_Platforms, Common_Consequences, Relationships, Other_Notes, References, Relationship_Notes, Taxonomy_Mappings, Terminology_Notes

CWE Content Team
MITRE
2008-10-14
updated Description

CWE Content Team
MITRE
2009-03-10
updated Other_Notes

CWE Content Team
MITRE
2009-05-27
updated Name

KDM Analytics
2009-07-17
Improved the White_Box_Definition

CWE Content Team
MITRE
2009-07-27
updated White_Box_Definitions

CWE Content Team
MITRE
2009-10-29
updated Modes_of_Introduction, Other_Notes

CWE Content Team
MITRE
2010-02-16
updated Relationships

CWE Content Team
MITRE
2010-06-21
updated Other_Notes, Potential_Mitigations

CWE Content Team
MITRE
2010-12-13
updated Demonstrative_Examples, Name

CWE Content Team
MITRE
2011-03-29
updated Alternate_Terms

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-05-11
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2012-10-30
updated Potential_Mitigations

CWE Content Team
MITRE
2013-02-21
updated Observed_Examples

CWE Content Team
MITRE
2014-02-18
updated Potential_Mitigations, References

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

CWE Content Team
MITRE
2017-11-08
updated References, Relationships, Taxonomy_Mappings, White_Box_Definitions

CWE Content Team
MITRE
2019-01-03
updated Common_Consequences, Demonstrative_Examples, Name, References, Relationships, Taxonomy_Mappings, Type, Weakness_Ordinalities

CWE Content Team
MITRE
2019-06-20
updated Description, Name

CWE Content Team
MITRE
2020-02-24
updated References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2020-08-20
updated Relationships

CWE Content Team
MITRE
2021-03-15
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated Taxonomy_Mappings

CWE Content Team
MITRE
2023-01-31
updated Common_Consequences, Description

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

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Description, Diagram, Modes_of_Introduction

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Applicable_Platforms

Memory Leak
Failure to Release Memory Before Removing Last Reference (aka 'Memory Leak')
Failure to Release Memory Before Removing Last Reference ('Memory Leak')
Improper Release of Memory Before Removing Last Reference ('Memory Leak')
Improper Release of Memory Before Removing Last Reference