CWE-763: Release of Invalid Pointer or Reference
The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
Last updated
Overview
This weakness can take several forms, such as: The memory was allocated, explicitly or implicitly, via one memory management method and deallocated using a different, non-compatible function (CWE-762). The function calls or memory management routines chosen are appropriate, however they are used incorrectly, such as in CWE-761.
Real-world CVEs
38 recorded CVEs are caused by CWE-763 (Release of Invalid Pointer or Reference). The highest-severity and most recent are shown first. 12 new CWE-763 CVEs have been recorded so far in 2026 (6 in 2025).
- CVE-2026-52993
tipc: fix double-free in tipc_buf_append()
Critical · CVSS 9.8 · EPSS 28th2026-06-24 - CVE-2026-22770
ImageMagick vulnerable to Release of Invalid Pointer in BilateralBlur when memory allocation fails
Critical · CVSS 9.8 · EPSS 26th2026-01-20 - CVE-2024-44852Critical · CVSS 9.8 · EPSS 44th2024-12-06
- CVE-2021-24028Critical · CVSS 9.8 · EPSS 75th2021-04-13
- CVE-2019-11930Critical · CVSS 9.8 · EPSS 87th2019-12-04
- CVE-2025-14233Critical · CVSS 9.3 · EPSS 51th2026-01-15
- CVE-2025-25215
Dell ControlVault3/ControlVault3 Plus cv_close arbitrary free vulnerability
High · CVSS 8.8 · EPSS 76th2025-06-13 - CVE-2024-6607
Leaving pointerlock by pressing the escape key could be prevented
High · CVSS 8.8 · EPSS 43th2024-07-09 - CVE-2025-13824
Micro820®, Micro850®, Micro870® – Specialized Fuzzing Vulnerabilities
High · CVSS 8.7 · EPSS 22th2025-12-15 - CVE-2025-11838
WatchGuard Firebox iked Memory Corruption Vulnerability
High · CVSS 8.7 · EPSS 35th2025-12-04 - CVE-2021-3682High · CVSS 8.5 · EPSS 85th2021-08-05
- CVE-2026-57248
Foxit PDF Editor/Reader Annotation Improper Release Vulnerability
High · CVSS 7.8 · EPSS 2th2026-07-08
Showing 12 of 38 recorded CWE-763 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-763 vulnerabilitiesCommon consequences
What can happen when CWE-763 is exploited.
Modify Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands
Affects: Integrity, Availability, Confidentiality
This weakness may result in the corruption of memory, and perhaps instructions, possibly leading to a crash. If the corrupted memory can be effectively controlled, it may be possible to execute arbitrary code.
How it happens
When it is introduced
Typically introduced during these phases of the software lifecycle.
Applies to
Languages
How to prevent it
Practical mitigations for CWE-763, grouped by where in the lifecycle they apply.
Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().
When programming in C++, consider using smart pointers provided by the boost library to help correctly and consistently manage memory.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, glibc in Linux provides protection against free of invalid pointers.
Use a language that provides abstractions for memory allocation and deallocation.
How to detect it
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.
Effectiveness: High
Automated Dynamic Analysis
Use tools that are integrated during compilation to insert runtime error-checking mechanisms related to memory safety errors, such as AddressSanitizer (ASan) for C/C++ [REF-1518] or valgrind [REF-480].
Effectiveness: Moderate
Code examples
Illustrative examples from MITRE showing how the weakness appears in code.
This code attempts to tokenize a string and place it into an array using the strsep function, which inserts a \0 byte in place of whitespace or a tab character. After finishing the loop, each string in the AP array points to a location within the input string.
Vulnerable example
char **ap, *argv[10], *inputstring;Since strsep is not allocating any new memory, freeing an element in the middle of the array is equivalent to free a pointer in the middle of inputstring.
This example allocates a BarObj object using the new operator in C++, however, the programmer then deallocates the object using free(), which may lead to unexpected behavior.
Vulnerable example
void foo(){Safe example
void foo(){Instead, the programmer should have either created the object with one of the malloc family functions, or else deleted the object with the delete operator.
In this example, the programmer dynamically allocates a buffer to hold a string and then searches for a specific character. After completing the search, the programmer attempts to release the allocated memory and return SUCCESS or FAILURE to the caller. Note: for simplification, this example uses a hard-coded "Search Me!" string and a constant string length of 20.
Vulnerable example
#define SUCCESS (1)Safe example
#define SUCCESS (1)Consider the following code in the context of a parsing application to extract commands out of user data. The intent is to parse each command and add it to a queue of commands to be executed, discarding each malformed entry.
Illustrative examples
Real CVEs that MITRE cites as examples of this weakness.
- CVE-2019-11930 — function "internally calls 'calloc' and returns a pointer at an index... inside the allocated buffer. This led to freeing invalid memory."
Terminology & mappings
Mapped taxonomies
- Software Fault Patterns: Faulty Memory Release (SFP12)
Frequently asked questions
Common questions about CWE-763.
- What is CWE-763?
- The product attempts to return a memory resource to the system, but it calls the wrong release function or calls the appropriate release function incorrectly.
- What CVEs are caused by CWE-763?
- 38 recorded CVEs are attributed to CWE-763, including CVE-2026-52993, CVE-2026-22770, CVE-2024-44852.
- How do you prevent CWE-763?
- Only call matching memory management functions. Do not mix and match routines. For example, when you allocate a buffer with malloc(), dispose of the original pointer with free().
- How is CWE-763 detected?
- 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.
- What are the consequences of CWE-763?
- Exploiting CWE-763 can lead to: Modify Memory, DoS: Crash, Exit, or Restart, Execute Unauthorized Code or Commands.
- Is CWE-763 actively exploited?
- 38 recorded CVEs are caused by CWE-763; none are currently in CISA's KEV catalog of actively exploited flaws.
References
- MITRE CWE definition (CWE-763) (opens in a new tab)
- CWE-763 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-763
Get alerted the moment a new CWE-763 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.