Use After Free
CWE-416: Use After Free
Use after free is a memory-safety bug where a program keeps using a pointer after the memory it refers to has been released. If an attacker can get their own data allocated into that freed slot, the stale pointer now points at attacker-controlled content, which often leads to code execution. It is a leading cause of browser and kernel exploits because complex object lifetimes, callbacks, and event handlers make it easy to free an object while another part of the code still holds a reference.
Ranks change between editions as the underlying CVE data changes, so exam questions rarely hinge on an exact rank. Know what each weakness is, how it is exploited, and how it is prevented.
How it shows up in the real world
- A browser frees a DOM node during a JavaScript event handler, then the rendering engine dereferences the old pointer after the handler returns.
- A network service frees a session object on error but leaves it in a lookup table, so a later request reuses the dangling pointer.
- A PDF reader releases an annotation object when a page is closed, but a timer callback registered earlier still holds the pointer and writes through it, letting attacker-controlled heap data stand in for the freed object.
How to mitigate it
- Use memory-safe languages, or in C++ rely on smart pointers and clear ownership rules instead of raw pointers.
- Set pointers to NULL immediately after freeing them and avoid sharing raw pointers across components with different lifetimes.
- Test with AddressSanitizer and fuzzing to catch lifetime errors before release.
- Ship with hardened allocators and exploit mitigations such as ASLR, CFI, and memory tagging where the platform supports them.
Go deeper
Practice this topic
Test your knowledge of Use After Free with exam-style practice questions.