Fuzzing (fuzz testing) is an automated testing technique that feeds a program large amounts of invalid, unexpected or random input to find crashes, memory errors and security vulnerabilities.
How fuzzing works
A fuzzer repeatedly generates inputs, runs the target with them and watches for crashes, hangs or failed assertions. Interesting inputs are saved for developers to reproduce. The idea dates back to 1988, when Barton Miller’s students at the University of Wisconsin crashed many Unix utilities with random input. Main approaches:
- Mutation-based – modifying sample files or messages by flipping bits, inserting bytes and splicing inputs.
- Generation-based – building inputs from a grammar or protocol specification, useful for complex formats.
- Coverage-guided – instrumenting the program and keeping inputs that reach new code paths. American Fuzzy Lop (AFL, 2013) and LLVM’s libFuzzer popularised this approach.
Fuzzers are usually combined with sanitizers such as AddressSanitizer, which turn silent memory corruption into immediate, reportable crashes.
Why fuzzing matters
Fuzzing is one of the most effective ways to discover buffer overflows, use-after-free bugs and parser flaws in code written in C and C++. Google’s OSS-Fuzz service, launched in 2016, continuously fuzzes hundreds of open-source projects and has found many thousands of bugs, many of them security vulnerabilities. Attackers and exploit brokers fuzz popular software too, and researchers use fuzzing in bug bounty programs to find issues in browsers, operating systems and network protocols.
How fuzzing is used in practice
- Integrate fuzz targets into CI/CD so that every change is tested continuously.
- Prioritise code that parses untrusted input: file formats, network protocols, image and font libraries.
- Run fuzzers with sanitizers and keep a corpus of good seed inputs.
- Combine fuzzing with code review, static analysis and memory-safe languages.
