Cybersecurity glossary
What is Use-After-Free?
Learn what a use-after-free vulnerability is, how accessing freed memory enables attacker-controlled objects, how UAF exploits work in browsers and native code, and how to prevent dangling pointer bugs.
Definition
Use-After-Free (UAF) is a memory safety vulnerability in which a program continues to use a pointer to memory after that memory has been freed, so a later allocation may occupy the same address and attacker-controlled data is interpreted as a live object.
Why use-after-free matters
Object lifetime is a contract: while a pointer is live, the memory it names must still be the object you think it is. When code frees that memory and later dereferences the old pointer, the contract is gone.
Use-After-Free turns lifetime mistakes into attacker-shaped objects. In browsers, kernels, and parsers, UAF remains one of the most reliable routes to sandbox escapes and remote code execution.
How a UAF exploit develops
Allocate and expose a pointer
An object is created and referenced from multiple places—caches, callbacks, or globals.
Free while references remain
One path destroys the object without clearing or synchronizing other references.
Reallocate the same slot
Attacker-controlled allocations spray the heap to occupy the freed address.
Stale pointer is used
Virtual calls, field reads, or writes interpret attacker bytes as a real object.
Gain a corruption primitive
Type confusion or controlled vtable use yields arbitrary read/write or code execution.
Typical UAF sources
Async callbacks
Timers, network completions, or GC finalizers run after an object was freed.
Cache vs owner mismatch
A cache retains a raw pointer while the owner destroys the object.
Error-path frees
Early returns free memory that a later cleanup or caller still uses.
Cross-thread lifetimes
One thread frees while another still holds and uses the pointer.
Prevention and detection
| Control | Notes |
|---|---|
| Clear ownership | Single owner; use unique/shared pointers or explicit lifetime scopes |
| Null after free | Helps for simple cases; insufficient alone against copies of the pointer |
| ASan / HWASan | Detect UAF reliably in tests and fuzzing builds |
| Quarantine frees | Delayed reuse makes accidental UAF crash earlier during testing |
| Sandboxing | Contain renderer/parser processes so a UAF is not full host compromise |
| Memory-safe rewrites | Eliminate dangling references in new components where practical |
- Map every free/destroy path against all retained references.
- Prefer smart pointers or explicit arenas over raw owning pointers.
- Run ASan fuzzing on components with complex object graphs.
- Audit async callbacks that capture raw this or object pointers.
- Synchronize cross-thread destruction; avoid lock-free lifetime guesses.
- Sandbox browsers, codecs, and document parsers aggressively.
- Treat reproducible UAF crashes as security bugs until proven benign.
- Reduce raw pointer caches; store IDs or weak references instead.
The practical takeaway
Use-After-Free means using memory after it was returned to the allocator—often letting attackers refill that slot. Fix ownership and lifetimes; do not rely on luck of heap layout.
If a crash stack shows a virtual call on a recently freed object, assume exploitability and prioritize the fix.
Related security terms
Double Free
Freeing the same allocation twice—often related lifetime mismanagement.
Heap Overflow
Another heap corruption class that can also yield object overwrite primitives.
Type Confusion
Interpreting memory with the wrong type—frequently chained with UAF.
Memory Corruption
Parent category for lifetime and bounds memory safety failures.
Frequently asked questions
What is use-after-free in simple terms?
The program frees an object, but keeps a pointer to it. Later it uses that pointer as if the object still exists. Attackers try to place their own data in that freed slot.
Why is UAF so common in browsers?
Browsers juggle complex object graphs, callbacks, and garbage collection across many threads and event handlers. Lifetime mistakes in C++ DOM or renderer code have historically produced high-impact UAFs.
Is a dangling pointer always exploitable?
Not always. Some UAFs only crash. Exploitability rises when attackers can reallocate the freed slot with controlled content before the stale pointer is used.
How do mitigations help?
Delayed free, pointer tagging, sandboxes, and hardened allocators raise cost. They do not replace correct ownership and lifetime design.
How do you find UAF bugs?
AddressSanitizer, Hardware-assisted AddressSanitizer, fuzzing with lifetime-stressing inputs, and careful code review of free paths and async callbacks.
What is the difference between UAF and double-free?
UAF uses memory after one free. Double-free frees the same address twice. Both indicate broken ownership; they can appear together in the same buggy lifecycle.
How do memory-safe languages help?
They typically prevent dangling references by construction (borrow checkers, GC). Risk remains at FFI boundaries into unsafe native code.
References
Explore authoritative guidance and frameworks related to use-after-free.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.