I've been spending a lot of time fuzzing lately. And after a while you realize the actual bottleneck isn't finding crashes. It's figuring out which crashes are worth your time.
ASAN spits out hundreds of logs. Some of them are heap overflows into metadata with clean write primitives. Some are one-byte null writes that go nowhere. Reading through them manually is tedious and honestly kind of demoralizing. You start missing things.
So I built Wendigo. It does the boring part for me.
You give Wendigo a crash. It tells you what kind of bug it is, how likely it is to be exploitable, and what you'd actually need to do to exploit it. It handles ASAN, KASAN, and raw GDB crash dumps. It generates HTML reports with memory layout diagrams so you can see what's going on without interpreting raw addresses.
The Problem with Generic Triage
A lot of crash triage tools just look at the bug class and assign a fixed score. Heap overflow? High severity. Use-after-free? High severity. But that's not actually useful.
A 1-byte null write into heap metadata is fundamentally different from a 4KB read past an allocation boundary, which is different again from a controlled write to an attacker-influenced offset. The exploit primitive matters. The allocation size matters. Whether you can control the value and destination both matter. Wendigo looks at all of that.
Parses ASAN, KASAN, and GDB crash output. Identifies the exact bug class: heap overflow, use-after-free, null deref, stack corruption, type confusion, and more.
Scores based on actual exploit primitives, not just bug class. Considers access size, control over value and destination, allocation metadata proximity, and crash context.
Checks PIE, stack canary, RELRO, FORTIFY, and NX. Factors this into the exploitability score. A heap overflow in a non-PIE binary without RELRO scores differently than the same bug in a hardened binary.
Maps each finding to the appropriate CWE. Useful for reporting, bug tracking, and when you need to communicate severity to people who aren't going to read the raw crash log.
Generates full HTML reports with memory layout diagrams so you can visualize what happened. Much faster to review than reading raw addresses and stack traces.
Handles ASAN output, KASAN output for kernel fuzzing, and raw GDB dumps. One tool regardless of what your fuzzing setup looks like.
Scoring Logic
The scoring isn't a lookup table. It's built from the actual characteristics of the crash. A few things that matter:
- Write vs read: write primitives are generally more useful for exploitation
- Access size: larger writes into adjacent metadata are more interesting than small ones
- Attacker control: can the value be controlled? Can the destination offset be influenced?
- Allocation context: where in the heap does this land? Adjacent to what?
- Binary hardening: ASLR, canaries, RELRO all affect what you can do with a given primitive
- Crash reproducibility: intermittent crashes score lower than deterministic ones
The output is a score and a plain-language explanation of why it scored that way. Not just a number.
$ wendigo --input crash.asan.log --binary ./target --output report.html
[+] Parsing ASAN output...
[+] Bug class: heap-buffer-overflow
[+] Access type: WRITE (8 bytes)
[+] Binary hardening: PIE=yes, CANARY=yes, RELRO=partial
[+] Exploitability score: 6.2/10 (MEDIUM-HIGH)
[+] CWE-122: Heap-based Buffer Overflow
[+] Generating HTML report with memory layout...
[+] Report written to report.htmlWhy I Built It
Honestly, I built it for myself. I was running StockFuzz against Stockfish, UxFuzz against UxPlay, and Syzkaller variants against out-of-tree Linux drivers. Each campaign was producing dozens to hundreds of crash files and I was spending more time triaging than actually understanding the bugs.
The existing tools either scored everything the same or required too much manual context to be useful at scale. So I wrote something that actually reflects how I think about crash severity when I'm looking at one manually.
Other researchers might find it useful. The code is on GitHub, it's open source, and it handles the formats I actually use. If your workflow is different, contributions are open.
Wendigo is open source at github.com/oxmesh/wendigo. Built for researchers who fuzz real software and need to prioritize crashes faster.