Fuzzing

Comprehensive Fuzzing Guide A practitioner’s reference for fuzz testing — fundamentals, coverage feedback, harness construction, corpus strategy, sanitizer usage, and the tool stack for web, binary, kernel, API, and smart-contract targets. Compiled from 46 research sources. Table of Contents Fundamentals Fuzzing Taxonomy Coverage-Guided Fuzzing Harness Construction Corpus Management & Seed Selection Dictionaries & Structure-Aware Fuzzing Sanitizers Binary Fuzzing (AFL++, libFuzzer, honggfuzz, LibAFL) Web Fuzzing (ffuf, wfuzz, feroxbuster, Burp Intruder) API Fuzzing (REST, GraphQL, Protobuf) Kernel & OS Fuzzing Directed & Grammar-Based Fuzzing AI-Augmented Fuzzing JVM Fuzzing (Jazzer, LibAFL) Rust & Python Fuzzing Snapshot Fuzzing (Nyx, HyperHook) Smart Contract Fuzzing Protocol & Network Fuzzing (Boofuzz, ICS) Crash Triage & Minimization CI/CD Integration Bugs That Survive Continuous Fuzzing Real-World Wins & CVEs Tools & Frameworks Reference Wordlist & Corpus Resources Quick Reference Cheatsheet 1. Fundamentals Fuzzing is automated software testing by bombarding a target with a large volume of semi-random, invalid, or unexpected inputs and watching for crashes, hangs, memory errors, or assertion failures. The technique originates with Barton Miller’s 1988 University of Wisconsin-Madison experiment, where random inputs crashed roughly a third of tested Unix utilities. ...

Use-after-free (UaF) vulnerabilities are one of the most exploited classes of memory corruption bugs. They’ve been at the heart of browser zero-days, Linux kernel privilege escalations, and countless CVEs. Despite being well understood, they remain stubbornly common — a testament to how easy they are to introduce and how hard they are to catch with conventional testing. What Is a Use-After-Free? A use-after-free occurs when a program: Allocates a chunk of memory on the heap Frees that memory (returning it to the allocator) Continues to use a pointer that still references the now-freed region The memory is no longer “owned” by the program. The allocator is free to give it to something else. When the program reads or writes through the dangling pointer, it’s operating on memory that may now belong to an entirely different object — or may have been zeroed, corrupted, or repurposed by an attacker. ...