What Is Fuzzing in Cybersecurity?

Fuzzing (fuzz testing) is an automated technique that feeds a program large volumes of invalid, unexpected or random input and watches for crashes, hangs, failed assertions and memory errors. Those failures often point to security bugs such as buffer overflows, use-after-free errors and parsing flaws that ordinary unit tests miss, because nobody thought to write that input by hand.

This guide covers what fuzzing is, where it came from, how a fuzzer works, the main types, the tools teams use, how to run a first fuzz test, and where fuzzing fits next to other application security testing.

What Fuzzing Does in a Security Program

Most security controls are reactive. A firewall or intrusion detection system reacts to traffic that has already reached a system. Fuzzing is proactive: you attack your own code with hostile and malformed input before anyone else does, then fix what breaks.

Fuzzers are usually described by how much they know about the target:

• Black-box fuzzing sends input with no view of the code and judges only by crashes or responses. It is quick to start and works on closed-source programs, but it can miss paths that need specific input to reach.
• White-box fuzzing uses the program’s logic and structure to steer inputs toward code that has not run yet. It costs more time and compute, but it can reach deeper code.
• Grey-box (coverage-guided) fuzzing sits in between. It adds light instrumentation so the fuzzer can see which code each input reached. Most modern tools, including AFL++ and libFuzzer, work this way.

Not every crash is a security vulnerability. Some are harmless robustness bugs, and a timeout can come from a slow test setup rather than a flaw, so findings still need triage.

Where Fuzz Testing Came From

The term comes from Professor Barton Miller’s Advanced Operating Systems class at the University of Wisconsin-Madison. The fuzz project was assigned in fall 1988, and the results were published in December 1990 in Communications of the ACM as “An Empirical Study of the Reliability of UNIX Utilities.” The method was simple: pipe random characters into command-line utilities and record which ones crashed or hung. The same group repeated the work in 1995, 2000 (Windows NT), 2006 (Mac OS X) and 2020 (UW-Madison fuzz project page).

How a Fuzzer Works

1. Pick a target. A function or program that takes untrusted input, such as a file parser, network protocol handler, image decoder or API endpoint.
2. Give it seeds. A small set of valid sample inputs, called the seed corpus.
3. Generate or mutate inputs. The fuzzer flips bits, truncates, repeats and splices inputs, or builds new ones from a grammar.
4. Watch for failures. Crashes, timeouts and sanitizer reports, for example AddressSanitizer catching an out-of-bounds read.
5. Keep what is interesting. Coverage-guided fuzzers save any input that reaches new code, so the corpus grows into deeper paths over time.
6. Minimize and triage. The failing input is shrunk to the smallest case that still fails, then saved as a regression test. Teams deduplicate crashes and judge which ones are exploitable.

Types of Fuzz Testing

Coverage guidance is the reason modern fuzzing is so effective. Read more in our glossary entry on coverage-guided fuzzing.

Common Fuzz Testing Tools

• AFL++: the community-maintained successor to American Fuzzy Lop, a coverage-guided fuzzer for C and C++ binaries.
• libFuzzer: LLVM’s in-process, coverage-guided fuzzing engine, usually paired with Clang sanitizers.
• Honggfuzz and Centipede: other fuzzing engines supported by OSS-Fuzz.
• Boofuzz: a fork of the Sulley framework, often used for network protocol fuzzing.
• Go native fuzzing: built into the standard Go toolchain since Go 1.18. Run it with go test -fuzz=FuzzName (Go docs).
• OSS-Fuzz and ClusterFuzzLite: Google’s free continuous fuzzing service for open-source projects, and a lighter option for running fuzzers in your own CI.

How to Run Your First Fuzz Test (Go Example)

Go is the easiest place to start because nothing extra needs installing. In a _test.go file, write a function named FuzzXxx that takes *testing.F, add a few seed values with f.Add(...), and call f.Fuzz with your target. Then run:

go test -fuzz=FuzzParse -fuzztime=60s

If it finds a failing input, Go writes it to testdata/fuzz/FuzzParse/, and a plain go test replays it from then on as a regression test. Keep fuzz targets fast and deterministic, and run them on AMD64 or ARM64 so coverage instrumentation works.

Benefits and Limits of Fuzzing

Benefits

• Finds what humans miss. Fuzzers try edge cases no one writes tests for, which is why they excel at memory-safety and parser bugs.
• Reproducible findings. A crash comes with the input that caused it, so debugging and confirming a bug is easier, and false alarms are fewer than with many scanners.
• Cheap to keep running. Once a harness exists, it can run in CI on every change.
• Broad reach. It applies to software, network protocols and APIs.

Limits

• Fuzzing only finds bugs that produce an observable failure.
• It struggles with checksums and deeply structured input unless you give it a grammar.
• It needs a harness written for each target, and long runs can need real compute and storage.
• It finds bugs but does not fix them. Developers still have to patch what it reports, and triage takes time.
• It complements code review and static testing. It does not replace them.

Real-World Examples of Fuzzing

Google built ClusterFuzz, a distributed fuzzing infrastructure, and launched OSS-Fuzz in 2016. It is a free service that continuously fuzzes open-source projects and privately alerts maintainers to the bugs it finds. According to the OSS-Fuzz documentation, as of August 2023 it had helped identify and fix over 10,000 vulnerabilities and 36,000 bugs across 1,000 projects. It supports C/C++, Rust, Go, Python, Java/JVM, JavaScript and Lua.

OSS-Fuzz was created in response to Heartbleed, the 2014 OpenSSL vulnerability. Google’s documentation describes Heartbleed as a relatively simple memory buffer overflow bug that fuzzing could have detected, at a time when fuzzing was not widely used and took a lot of manual effort.

Fuzzing has also moved into mainstream languages. Go has included native fuzzing in its standard toolchain since Go 1.18, so developers can run a fuzz test with the same go test command they already use.

Fuzzing FAQ

Further Reading

To see how fuzzing compares with code scanning and runtime testing, read SAST vs DAST vs IAST vs RASP and our list of the best SAST tools.

Mark Hill