Skip to content

What is use after free?

Last reviewed June 2, 2026

Use after free (CWE-416) is a memory-corruption vulnerability where a program continues to use a pointer after the memory it points to has been freed. An attacker can reallocate that memory with controlled data, leading to crashes, information disclosure, or arbitrary code execution. It is prevented by nulling freed pointers, using safe languages, and applying memory-safety tooling.

What use after free is

Use after free, tracked as CWE-416, occurs when a program frees a block of memory but keeps and later uses a pointer to it. That stale pointer is called a dangling pointer. Because the freed memory may be reused for something else in the meantime, dereferencing the dangling pointer reads or writes data the program no longer controls.

Use after free is a frequent and severe weakness in C and C++ programs and is especially common in long-lived, object-heavy software such as browsers and operating-system kernels.

How the attack works

A program frees an object but a second pointer still references it. The attacker then triggers a new allocation of the same size, and the allocator hands back the just-freed memory, now filled with attacker-controlled data. When the program follows the old dangling pointer, it operates on the attacker's data instead of the original object.

If the original object contained a function pointer or virtual table pointer, the attacker's replacement data can redirect a later call to code of their choosing. This heap-grooming technique makes use-after-free a reliable route to code execution despite seeming like a mere lifetime mistake.

Real-world impact

  • Crashes and unpredictable behavior from operating on reused memory.
  • Information disclosure by reading data that landed in the freed region.
  • Arbitrary code execution by overwriting object pointers or vtables.
  • A leading source of exploited browser and kernel vulnerabilities, frequently in the CWE Top 25.

How to prevent it

  • Set pointers to null immediately after freeing so reuse fails loudly rather than silently.
  • Use smart pointers and RAII (in C++) or memory-safe languages like Rust that prevent dangling references at compile time.
  • Avoid sharing raw ownership of heap objects; centralize and clearly define object lifetimes.
  • Test with AddressSanitizer and fuzzing, which are effective at catching use-after-free during development.
  • Adopt allocator hardening and exploit mitigations to make reuse harder to weaponize.

Keep exploring

Frequently asked questions

What is use after free in simple terms?
It is when a program throws away a chunk of memory but keeps using the old pointer to it, so it ends up reading or writing memory that has since been reused for something else.
Why is use after free exploitable?
An attacker can fill the freed memory with their own data before the program reuses the stale pointer. If that data overwrites an object's function pointer, the next call can jump to attacker-controlled code.
How do you prevent use after free?
Null out pointers after freeing, use smart pointers or memory-safe languages, define clear object ownership, and catch bugs early with AddressSanitizer and fuzzing.
Which CWE covers use after free?
Use after free is CWE-416, Use After Free, a memory-management weakness that regularly appears in the CWE Top 25.