When a fuzzer reports a crash, first reproduce it with the saved input, then minimize that input, group it with other reports that share a root cause, judge impact, fix it, and keep the input as a regression test. Do not start with severity guesses.
Step 1: reproduce
A report you cannot reproduce is a rumor. Fuzzers save the failing input, so run the target with exactly that file in a single process with no fuzzing engine. Go's tooling prints a re-run command for the saved input, and OSS-Fuzz has documentation on reproducing crashes locally.
Use the same build flags, especially sanitizers. A crash that appears under a sanitizer may not crash in a normal build, but it can still be a real memory error.
Step 2: minimize
Smaller inputs are easier to read and debug. Fuzzing engines try to minimize automatically. Go's documentation says the engine minimizes a failing input to the smallest value that still fails, with a default minimization time of 60 seconds that you can change or turn off.
If the input is still large, minimize further by hand or with the engine's minimizer, and confirm it still fails for the same reason.
Step 3: read the report
For a sanitizer report, find the error type, the line of the bad access, and the stack for where memory was allocated and freed. Clang's AddressSanitizer output includes those traces. The top frames usually point at the real bug.
Step 4: deduplicate
One bug can produce thousands of crashing inputs. Group by the top few stack frames and by error type. OSS-Fuzz notes that it cannot deduplicate timeouts and out of memory bugs well, so it reports only one of each per fuzz target until that one is fixed. Expect something similar in your own pipeline and track by root cause, not by input count.
Step 5: judge impact
Ask practical questions.
- Is the input reachable from untrusted data, or only from a trusted internal caller?
- Is it a read or a write out of bounds, a double free, a plain null dereference, or a hang?
- Does it need unusual configuration?
A write past a buffer from network input is urgent. A timeout on a tool that only runs locally is not. Record your reasoning in the ticket.
Step 6: fix and lock it in
Fix the cause, not the symptom. Add the minimized input to the seed corpus or as a unit test, then re-run the fuzzer for a while to confirm it moves past that spot. Check sibling code for the same pattern.
Quick check
Is every fuzzer crash a vulnerability?
No. Some are harmless assertion failures or only reachable from trusted callers. But treat any memory corruption reachable from untrusted input as a security bug until shown otherwise.
Sources
Last reviewed: 19 October 2026.
