What is fuzzing?
Fuzzing, or fuzz testing, sends a program enormous numbers of deliberately malformed, oversized, truncated or random inputs and watches for failures: crashes, hangs, memory errors, unhandled exceptions or wrong output. Each failure marks a place where the code mishandles input it did not expect. In memory-unsafe languages such as C and C++, many of those turn out to be exploitable bugs, such as buffer overflows and use-after-free errors. Fuzzing is a dynamic technique: the program actually runs, and a tool called a fuzzer generates the inputs and records what breaks. Defenders fuzz their own code to find these bugs first; attackers fuzz popular software to find zero-days.
How fuzzers create input
- Mutation-based: start from valid samples, such as real PDF files or captured network packets, and alter them by flipping bits, repeating bytes, cutting fields short or inserting extreme values. It is quick to set up and needs no knowledge of the format.
- Generation-based: build inputs from a model of the file format or protocol, so they are valid enough to pass early parsing checks and reach deeper code. It takes more setup and covers complex formats better.
- Coverage-guided: instrument the program, keep any input that reaches new code paths, and mutate those inputs further. AFL (American Fuzzy Lop), its successor AFL++, and libFuzzer made this approach the standard for native code.
Detectors make quiet bugs visible. Building the target with AddressSanitizer, for instance, turns a silent out-of-bounds read into an immediate crash with a stack trace.
Example: a coverage-guided fuzzing run
A team maintains an image-thumbnail library written in C. They write a short harness that hands a byte buffer to the library's decode function, build it with libFuzzer and AddressSanitizer, and seed it with twenty sample images. Overnight the fuzzer tries millions of mutated files and saves one that triggers ERROR: AddressSanitizer: heap-buffer-overflow in the PNG chunk parser. The saved file reproduces the crash every time, so a developer can step through it, fix the missing length check and add the file to the regression tests. Keeping the fuzzer in the build pipeline stops later changes from bringing the bug back.
Where fuzzing is used
- File parsers and media codecs, which process untrusted files from anywhere.
- Network protocol implementations and services, by sending malformed packets or requests.
- Web applications and APIs, where scanners fuzz parameters, headers and JSON fields to provoke errors.
- Widely used open-source projects, which Google's OSS-Fuzz service fuzzes continuously.
Fuzzing vs. SAST, DAST and penetration testing
- SAST reads the code without running it. Fuzzing runs the program and needs no understanding of the code to find a crash.
- DAST probes a running web application with known attack payloads. Fuzzing leans on volume and malformed input, and many DAST tools include a fuzzing component.
- Penetration testers use fuzzers as one tool, then work out whether a crash can actually be exploited.
- Fuzzing is good at input-handling bugs and poor at logic or authorization flaws, which produce no crash to notice.
Fuzzing on the CompTIA Security+ exam
SY0-801 does not name fuzzing as a separate item. It is taught beside static code analysis among the application security controls in objective 4.1, as a dynamic technique that complements reading the code. Wording such as send large amounts of random or malformed input to the application to find crashes or find unexpected input-handling errors in a running program points to fuzzing. Distractors include static code analysis, which never runs the program; code signing, which proves origin rather than quality; and input validation, which is the defense that fuzzing often shows to be missing.