A fuzzer crash proves a bug exists, not that it is exploitable. Severity depends on five things: whether an attacker can reach the code, how much they control the bad bytes, what kind of bug it is, what mitigations stand in the way, and what the process can do. Answer those in order and write down the reasoning.
1. Can an attacker reach this code?
Your fuzz target feeds a parser directly. In the real product, that parser may sit behind authentication, only read files your own staff create, or never run at all. Trace the callers. A parser that handles internet-facing requests is a different risk from one that reads a local config file.
2. How much do they control?
Read the sanitizer report. For a write, how many bytes, and are the values chosen by the input? A one byte overflow whose value is fixed at zero is harder to use than an overflow that copies attacker bytes. The report states whether the bad access was a read or a write and its size, which are your first clues.
3. What kind of bug is it?
Different classes carry different risk:
- Write out of bounds, use-after-free: often the most serious, because they can corrupt control data.
- Out-of-bounds read: can leak memory contents, and may still enable follow-on attacks.
- Uninitialized read: may leak data, depends on what that memory held.
- Undefined behavior such as integer overflow: depends on what the overflowed value is used for.
- Timeout or out-of-memory: denial of service, serious on a public service, minor in a local tool.
Do not rank them by headline alone. A read in a path that returns data to the caller can matter more than a write in a dead end.
4. What mitigations apply?
Hardening in the compiler, operating system or runtime can make exploitation harder, but it rarely removes the bug, and relying on it as the reason to ignore a flaw is a weak position. Note them, but treat them as reducing likelihood, not making the issue disappear. Sanitizer builds change behavior too, so a crash under a sanitizer may not look the same in a release build.
5. What can the process do?
A bug in a sandboxed worker with no network and no secrets is bounded. The same bug in a process holding credentials or running as an administrator is not. Consider the privileges and data around the code.
Write down the answer
For each issue, record the five answers in a sentence or two. Then pick a severity with a standard scale used in your company, and say why. Avoid claiming a bug is exploitable without proof, and avoid claiming it is harmless without checking reachability.
Reachability applies to dependencies too
The same logic is why dependency findings are triaged by whether the vulnerable function is actually reachable from your code. Our posts on reachability cover that side.
Try it yourself
Open the demo and walk through how an exploitability check weighs a finding. Compare its questions with the five above.
Click through it at your own pace, or open it full screen.
Quick check
Is every ASan report a security vulnerability?
No. It is a memory safety bug. Whether it is a vulnerability depends on reachability, control over the data and what the process can do.
Can I ignore a crash because only a fuzzer triggers it?
Be careful. If an attacker can send the same input through a real entry point, it is not just a fuzzer artifact. Check the callers first.
Sources
Last reviewed: 19 October 2026.
