A use-after-free (UAF) is a memory-safety vulnerability in which a program keeps using a piece of memory after it has already been freed.
How use-after-free works
In C and C++ a program allocates memory for an object, uses it and later releases (“frees”) it. If some code still holds a pointer to that memory – a dangling pointer – and uses it again, the program reads or writes memory that may now belong to something else. An attacker can deliberately trigger the free, fill the released memory with crafted data (heap spraying or grooming) and make the program treat this data as the old object. When the program calls a function through that object, execution jumps to code the attacker chose.
The weakness is catalogued as CWE-416. It is especially common in complex software with many objects and callbacks: browser engines, PDF readers, operating system kernels and drivers.
Why use-after-free matters
UAF bugs are one of the most frequent causes of in-the-wild zero-day exploits in Chrome, Safari, Firefox and the Windows kernel. A browser UAF typically gives remote code execution inside the renderer simply by visiting a web page; attackers then chain it with a sandbox escape. Together with buffer overflows, use-after-free belongs to the memory-safety class that Microsoft and Google say causes around 70% of their serious security bugs.
How to prevent use-after-free
- Write new components in memory-safe languages such as Rust.
- Use smart pointers and clear ownership rules in C++; set pointers to null after freeing.
- Apply hardening such as Chrome’s MiraclePtr, hardened allocators and memory tagging (ARM MTE).
- Fuzz code with AddressSanitizer, which reports UAF accesses immediately.
- For users: install browser and OS updates quickly, because UAF exploits are often used before or right after a patch is released.
