Fuzzing
Fuzzing (Fuzz Testing) · Also known as: fuzz testing, fuzzer, mutation testing
Fuzzing is a software testing technique that inputs large numbers of random or semi-random test cases to a program to find bugs, crashes, and security vulnerabilities. Pioneered by Barton Miller in 1990, fuzzing has become a primary method for discovering zero-day vulnerabilities in complex software. Modern fuzzing tools like libFuzzer, AFL, and HoneyPot combine coverage-guided mutation with instrumentation to efficiently explore program paths and trigger vulnerabilities. Fuzzing has discovered thousands of critical vulnerabilities in major software including browsers, compilers, and cryptographic libraries.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Fuzzing is invaluable for testing parsers, decoders, and complex input handling code where edge cases are hard to predict. Use fuzzing early and often during development as a regression testing technique. Fuzzing is particularly effective for security-critical components (cryptography, input validation, protocol parsers) and for finding memory corruption vulnerabilities in C/C++ code.
Strengths & limitations
- Automatically discovers vulnerabilities without requiring knowledge of the program's intended behavior
- Extremely effective at finding memory corruption bugs, crash-causing inputs, and logic flaws
- Can run continuously for days or weeks, accumulating coverage and finding rare edge case bugs
- Coverage-guided fuzzers intelligently explore program paths, focusing effort on promising areas
- Ineffective for finding vulnerabilities in logic or algorithms that do not cause crashes
- Struggles with complex input formats or programs requiring specific environmental setup
- May require custom harnesses or instrumentation for non-trivial programs
- False negatives: absence of crashes does not guarantee absence of vulnerabilities
Frequently asked
What is coverage-guided fuzzing?
Coverage-guided fuzzing uses information about which code paths are exercised to guide mutation. Inputs that reach new code paths are retained as seeds, focusing the fuzzer on exploring uncovered areas. This greatly improves efficiency over random fuzzing.
How long should I run a fuzzer?
Continuously, ideally. Coverage graphs typically show diminishing returns after initial intensive fuzzing, but bugs continue to be found. Many organizations run fuzzers 24/7 on critical software.
Can fuzzing find all vulnerabilities?
No. Fuzzing is excellent at finding crashes and memory corruption but may miss logic flaws, authentication bypass, and vulnerabilities requiring specific input sequences not discoverable by random mutation.
How do I set up fuzzing for my program?
Write a fuzz target that accepts mutated input and exercises the program. Link with a fuzzing engine (libFuzzer, AFL++). Provide seed inputs. Compile with sanitizers (AddressSanitizer, UndefinedBehaviorSanitizer) to detect memory errors.
What is differential fuzzing?
Differential fuzzing compares outputs of multiple implementations (e.g., different compiler versions) to find bugs. Discrepancies often indicate correctness issues or security vulnerabilities.
Sources
- Miller, B. P., Fredriksen, L., & So, B. (1990). An empirical study of the reliability of UNIX utilities. Communications of the ACM, 33(12), 32-44. DOI: 10.1145/96267.96279 ↗
- Böhme, M., Pham, V. T., Sharma, A., & Cichon, M. (2020). Fuzzing: Challenges and reflections. IEEE Security & Privacy, 19(2), 56-62. link ↗
How to cite this page
ScholarGate. (2026, June 3). Fuzzing (Fuzz Testing). ScholarGate. https://scholargate.app/en/cryptography/fuzzing
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- Dynamic Application Security TestingCryptography↔ compare
- Symbolic ExecutionCryptography↔ compare
- Taint AnalysisCryptography↔ compare