What Is a Use-After-Free Vulnerability? CWE-416 Explained

A use-after-free vulnerability is a memory bug where a program frees a block of memory but keeps using a pointer to it. If an attacker can place their own data in that freed memory first, the program acts on it, which can crash it, leak data or run attacker code. It is tracked as CWE-416 and is one of the most exploited bug classes in CISA's KEV catalog.

This guide explains how use-after-free (UAF) bugs work, why browsers, operating systems and PDF readers keep shipping them, what the CISA Known Exploited Vulnerabilities (KEV) data says about real-world exploitation, and how engineering teams prevent and prioritize them. It is written for developers and security leads who see "use after free" in a patch note, like this week's Chrome zero-day CVE-2026-125350, and want to know what it means and how worried to be.

What is a use-after-free vulnerability, in simple terms?

Programs written in C and C++ manage memory by hand. They ask the allocator for a block of memory, use it, and give it back with free() or delete. A pointer is just an address. Freeing the memory does not erase the pointers that still hold that address, so if any part of the program keeps one and uses it later, it is reading or writing memory that now belongs to something else. MITRE defines this as CWE-416: Use After Free.

A minimal example in C:

struct session *s = malloc(sizeof *s);
handle_request(s);
free(s);            /* memory returned to the allocator */
/* ... later, on an error path ... */
log_user(s->user);  /* s still points to the freed block */

struct session *s = malloc(sizeof *s);
handle_request(s);
free(s);            /* memory returned to the allocator */
/* ... later, on an error path ... */
log_user(s->user);  /* s still points to the freed block */

struct session *s = malloc(sizeof *s);
handle_request(s);
free(s);            /* memory returned to the allocator */
/* ... later, on an error path ... */
log_user(s->user);  /* s still points to the freed block */

On its own, that last line usually reads garbage or crashes. It becomes a security bug when an attacker can control what gets allocated into the freed slot between the free and the reuse.

How do attackers exploit a use-after-free bug?

Exploitation usually follows three steps. First, the attacker triggers the free, for example by making a web page remove a DOM node while a script still holds a reference to it. Second, they "groom" the heap: they quickly allocate objects of the same size with contents they control, so one of them lands in the freed slot. Third, they trigger the stale pointer. If the program now calls a function through what it thinks is its old object, it calls an address the attacker chose.

That is why UAF bugs are prized in browsers. JavaScript gives an attacker fine control over when objects are created and destroyed, which makes heap grooming reliable. The Chromium project says around 70% of its high-severity security bugs are memory safety problems and half of those are use-after-free bugs, according to its memory safety page. In practice, a browser UAF is often the first link in a chain: code execution inside the renderer sandbox, followed by a second bug to escape it.

How common are exploited use-after-free bugs? What KEV data shows

We counted CWE tags in CISA's KEV catalog as released on November 9, 2026. Of 1,773 vulnerabilities confirmed as exploited in the wild, 95 are tagged CWE-416, or 5.4%. That makes use-after-free the fourth most common weakness in the catalog, behind improper input validation (CWE-20, 119), OS command injection (CWE-78, 114) and out-of-bounds write (CWE-787, 106).

Ten of the 95 are marked by CISA as known to be used in ransomware campaigns. Additions per year have fallen from 24 in 2021 and 25 in 2022 to 9 so far in 2026, which fits the memory safety investments vendors have made, but a steady trickle still reaches KEV every year. Not every KEV entry has a CWE tag, so treat these counts as a floor.

Why do use-after-free bugs keep happening?

They are hard to spot in review. Google's security team describes the typical cause in its post on MiraclePtr: one programmer makes a reasonable assumption about how long an object lives, and a later change elsewhere quietly breaks it. The free and the stale use are often in different files, written months apart, and only collide on a rare error path or under an unusual sequence of events. Large C++ codebases with callbacks, event loops and asynchronous work, such as browsers, kernels, PDF engines and media parsers, produce exactly these conditions.

Static review and unit tests rarely catch them. They tend to be found by fuzzing, by sanitizers in testing, or by attackers.

How do you prevent use-after-free vulnerabilities?

The strongest fix is structural: write new code in memory-safe languages such as Rust, Go, Java, C# or Swift, where the compiler or runtime prevents dangling pointers. CISA and partner agencies make this case in The Case for Memory Safe Roadmaps, which asks vendors to publish plans for moving toward memory-safe code.

For existing C and C++ code, layer defenses:

1. Own lifetimes explicitly. Use smart pointers (std::unique_ptr, std::shared_ptr) and clear ownership rules instead of raw pointers passed between components.

2. Null pointers after free. It does not fix copies of the pointer, but it turns some reuse into a clean crash instead of an exploitable one.

3. Run sanitizers in CI. AddressSanitizer flags heap use-after-free at runtime during tests and fuzzing; it is also available in MSVC.

4. Fuzz the parsers. XML, image, font and media parsers are where UAF bugs cluster; continuous fuzzing finds them before attackers do.

5. Use hardened allocators. Techniques like Chromium's MiraclePtr quarantine freed memory while references still exist, so a dangling pointer cannot be steered onto attacker data.

How should security teams prioritize use-after-free CVEs?

A "use after free" label tells you the bug class, not the risk. Three questions matter more. Is it reachable from untrusted input, such as a web page, an email attachment or a network packet? Is it confirmed exploited, through a vendor statement or a KEV listing? And does the affected software sit on many endpoints, like a browser or OS?

New zero-days often arrive before any score does. CVE-2026-125350 had no CVSS score, no EPSS probability and no KEV entry on the day Google patched it, even though Google confirmed exploitation. A vendor's "exploit exists in the wild" statement should trigger the same urgency as a KEV listing. Our guides on how to prioritize vulnerabilities beyond CVSS, what CISA KEV is and what a zero-day vulnerability is cover the full process, and what CWE is explains the weakness taxonomy behind tags like CWE-416. For a recent kernel example, see our coverage of the Linux TCP remote use-after-free CVE-2026-98432.

FAQ

Is use-after-free the same as a buffer overflow?
No. A buffer overflow writes past the end of a valid block of memory (CWE-787 or CWE-119). A use-after-free uses memory that was valid once but has been released. Both are memory safety bugs and both can lead to code execution.

Can use-after-free bugs happen in Python, Java or JavaScript?
Not in your own code, because those runtimes manage memory for you. They can happen inside the runtime or native libraries those languages call, such as a browser's JavaScript engine or a C extension.

Is every use-after-free exploitable?
No. Many only cause a crash. Exploitability depends on whether an attacker can trigger the free, control what lands in the freed memory and reach the stale use from untrusted input.

How do I fix a use-after-free in a product I use?
Apply the vendor's update. For browsers, that also means relaunching, since Chrome and Edge install updates only on restart.

Data: CISA Known Exploited Vulnerabilities catalog, release of November 9, 2026, counted by Nexus Void Research. Sources: MITRE CWE-416, Chromium memory safety page, Google Security Blog, CISA.