Use-after-free

Programs written in languages such as C and C++ manage memory by hand: they request a block, use it, and free it when they are done. A use-after-free happens when the program frees a block but still holds a pointer to it, and later reads or writes through that stale pointer. By then, the memory may have been handed out again and filled with something else.

If an attacker can control what ends up in that freed memory, they can influence what the program does with it. Depending on the bug, the result ranges from a crash to leaking data from memory to full remote code execution. MITRE tracks the weakness as CWE-416, and it appears in many browser, operating system and interpreter vulnerabilities.

Example

A web scripting engine frees an object when a request ends but leaves a global pointer to it. The next request on the same worker process uses that pointer before it is reset. An attacker who first fills the freed memory with crafted data can make the second request follow their instructions.

Why it matters for a SOC analyst

You will not hunt for use-after-free bugs yourself, but the term appears in advisories constantly. It signals a memory corruption flaw that can often lead to code execution, so a "use-after-free" in a network-facing component deserves fast patching and a look for signs of exploitation.