What Is a Use-After-Free Vulnerability? UAF Explained

A use-after-free vulnerability is a memory bug where a program frees a block of memory and then keeps using a pointer to it. MITRE tracks it as CWE-416. Once that memory is handed out again, the stale pointer reads or writes whatever now lives there. In browsers, where web pages can influence what gets allocated, that mistake can turn into code execution, as the Chrome XML zero-day CVE-2026-125350 showed in November 2026.

What is a use-after-free vulnerability?

A use-after-free is a bug where software references memory after releasing it, so later reads or writes hit memory that now belongs to something else. MITRE's CWE-416 entry describes it in exactly those terms and lists "dangling pointer" as an alternate name for the stale reference.

The sequence has three steps:

1. The program allocates an object and keeps a pointer to it.
2. Some code path frees the object, but at least one pointer to it is not cleared.
3. Later code follows the old pointer and treats the memory as if the original object were still there.

If nothing else has reused the memory, the program may keep working or crash. If something else has been allocated in that spot, the program is now operating on the wrong data.

Why does a use-after-free lead to code execution?

A use-after-free leads to code execution when an attacker can influence what fills the freed memory, so the program's next use of the stale pointer acts on attacker-controlled data. In a browser, a web page shapes many allocations, which gives an attacker that influence.

CWE-416 lists the consequences as memory corruption, crashes and execution of unauthorized code. Which one you get depends on what the stale pointer is used for. A pointer that is only read may leak data. A pointer to an object with function pointers or a virtual table can redirect control flow. That second case is why use-after-free bugs show up so often in exploited browser vulnerabilities.

Why browsers keep shipping use-after-free bugs

Browser engines such as Chromium's Blink are large C++ codebases. C++ leaves memory lifetime to the programmer, and a browser has thousands of objects with lifetimes tied to page events: a script removes a DOM node, a parser finishes a document, a tab closes mid-load. Every one of those events is a chance for one part of the code to free an object that another part still references.

The XML component in Chrome is a good example. Parsing a document creates and destroys many objects quickly, and the order depends on input the page controls. The CVE record for the Chrome zero-day CVE-2026-125350 says a crafted HTML page was enough to execute code inside the sandbox.

Use-after-free is not specific to browsers. It appears in kernels, hypervisors, media parsers and network daemons, anywhere C or C++ manages object lifetimes by hand.

What does "inside the sandbox" mean for a use-after-free?

It means the attacker's code runs in Chrome's restricted renderer process, which cannot directly read arbitrary files or install software. To take over the machine, an attacker normally needs a second bug that escapes the sandbox.

Do not read that as reassurance. Attackers who use browser zero-days in the wild often chain a renderer bug with a sandbox escape or an operating system privilege escalation. The sandbox raises the cost of an attack; it does not remove the need to patch.

How do developers prevent use-after-free bugs?

The CWE-416 entry lists two main mitigations: choose a language with automatic memory management, and set pointers to NULL when the memory they point to is freed. Clearing pointers turns a silent corruption into a predictable crash, which is much harder to exploit.

In large existing C++ codebases, teams layer additional defenses on top:

• Ownership rules and smart pointers. Code that makes ownership explicit leaves fewer raw pointers outliving their objects.
• Memory-safe languages for new components. Writing new parsers in a memory-safe language removes the bug class for that code.
• Fuzzing with memory error detectors. Fuzzers feed malformed input to parsers, and sanitizers flag a use-after-free the moment it happens instead of when it crashes.
• Hardened allocators. Allocators that delay or randomize reuse of freed memory make it harder for an attacker to control what lands in the freed slot.

None of these is complete on its own. That is why browsers still ship several use-after-free fixes in a typical release.

What should IT teams do about use-after-free CVEs?

Treat any use-after-free in software that parses untrusted input (browsers, document viewers, mail clients, VPN gateways) as a likely code execution bug, even if the advisory is vague. Patch it on your fastest track, especially when the vendor or CISA says it is exploited.

Practical steps:

• Prioritize by exposure, not by the word "memory". A use-after-free in a component that handles web content or email deserves a faster response than one that needs local admin access.
• Watch for the phrase "exists in the wild" in Chrome advisories. That is Google's signal that a patch is urgent, and it usually lands before any technical detail does.
• Make sure the patch is actually running. A browser that downloaded the fix but never relaunched is still vulnerable. See our guide to browser zero-day response when the vendor shares nothing for the verification steps.
• Accept that details come later. Vendors often restrict bug reports until most users update, for reasons covered in why vendors withhold zero-day details.

The glossary entry for memory safety covers the wider family of bugs that use-after-free belongs to.