What Is Fuzzing in Cyber Security? How Security Teams Find Vulnerabilities

Fuzzing in cyber security is an automated testing technique that feeds programs random, malformed, or mutated input while monitoring for crashes, memory errors, or unexpected behavior, uncovering vulnerabilities that manual code review and standard testing routinely miss.

Unlike traditional testing methods that check whether software does what it’s supposed to, fuzzing checks what happens when software receives input nobody planned for. That distinction matters because attackers don’t send well-formed requests either, they send exactly the malformed, unexpected data fuzzing is built to simulate, making it one of the few testing techniques that genuinely mirrors real attacker behavior.

Where fuzzing came from: a thunderstorm and a dial-up connection

Fuzzing traces to a single stormy night in 1988, when University of Wisconsin-Madison professor Barton Miller found electrical noise on his dial-up connection was corrupting his terminal input, crashing Unix programs he’d assumed were solid.

Miller turned the accident into a class project, assigning students to build a “fuzz generator” that bombarded Unix utilities with random input and recorded which ones crashed. The results shocked him: roughly 25 to 33 percent of standard, supposedly robust utilities failed under nothing more sophisticated than random noise. That single experiment launched an entire field, one Miller later documented in his book, and the term “fuzzing” stuck permanently to describe the technique.

Black box, grey box, and white box fuzzing explained

Black box grey box white box fuzzing describes how much internal knowledge a fuzzer has about its target. Black box fuzzing treats the program as opaque, sending input and observing only crashes or outputs. White box fuzzing uses full source code access and formal analysis. Grey box sits between the two, using lightweight instrumentation without complete code visibility.

Fuzzing Model	Knowledge Used	Best For
Black box	None, inputs and outputs only	Closed-source binaries
Grey box	Compile-time coverage instrumentation	Most modern coverage-guided fuzzers
White box	Full source access, symbolic execution	Deep formal verification

This distinction matters practically because most modern, effective fuzzing tools live in the grey box middle ground, using compile-time instrumentation to guide mutation without requiring the deep symbolic analysis white box techniques demand.

Coverage-guided fuzzing: how AFL changed everything

Coverage-guided fuzzing instruments a target program at compile time to track which code paths each test input actually exercises, then uses that feedback to steer future mutations toward unexplored branches rather than blindly generating random data forever.

This is the specific innovation that transformed fuzzing from a novelty into a production-grade security technique. Pure random fuzzing, Miller’s original 1988 approach, wastes enormous effort re-testing the same shallow code paths repeatedly. AFL, and its actively maintained successor AFL++, proved that feeding execution coverage back into the mutation engine finds dramatically more bugs, and finds them deeper in program logic, than random input ever could on its own.

What is race condition in cyber security, and can fuzzing find it?

It is a vulnerability where program behavior depends on the uncontrolled timing between concurrent threads or processes, most commonly appearing as a TOCTOU flaw, where an attacker manipulates a resource in the gap between a security check and the action that follows it.

Standard fuzzing genuinely struggles here, and it’s worth being honest about the limitation rather than overselling the technique. Race conditions are non-deterministic by nature, a bug might trigger once in 10,000 executions depending on CPU load and thread scheduling, and adding debugging instrumentation can change timing enough to make the bug vanish entirely, a phenomenon researchers call a Heisenbug. Real, confirmed vulnerabilities like CVE-2021-21315 in Node.js and CVE-2020-24815 in Ghostscript show TOCTOU flaws are genuinely exploitable, but finding them through fuzzing alone typically requires massive execution volume and specialized concurrency-aware fuzzing extensions, not standard mutation fuzzing run for a few hours. Treat fuzzing as one useful tool against race conditions, not a reliable primary defense against this specific bug class.

Sanitizers: catching the bugs a crash alone won’t reveal

Sanitizers are compiler-based instrumentation tools that detect memory and behavioral errors that don’t necessarily cause an immediate crash on their own, turning silent, dangerous bugs into loud, catchable ones during a fuzzing run.

AddressSanitizer, or ASan, catches heap and stack buffer overflows, use-after-free, and double-free errors. MemorySanitizer, MSan, catches reads from uninitialized memory. UndefinedBehaviorSanitizer, UBSan, catches integer overflows and null pointer dereferences. Without a sanitizer attached, a use-after-free bug might silently corrupt memory without crashing the program at all, meaning a fuzzer running for days could pass right over a genuinely serious, exploitable vulnerability simply because nothing visibly broke. Pairing a fuzzer with the right sanitizer is what separates a fuzzing setup that finds real bugs from one that looks busy but misses them.

AFL++, libFuzzer, and Honggfuzz: the standard toolset compared

Fuzzing tools in production fuzzing today center on three names: AFL++, libFuzzer, and Honggfuzz, each with a genuinely different sweet spot rather than one being simply better than the others.

libFuzzer runs in-process, compiling your target as a library for extremely fast, repeated execution, making it the natural choice for fuzzing libraries and APIs where you have source access and Clang available. AFL++ wins decisively when you’re fuzzing a closed-source binary you can’t recompile, using QEMU mode to instrument binaries at runtime, with additional modes covering firmware, embedded targets, and mobile platforms libFuzzer simply can’t reach. Honggfuzz offers similar coverage-guided capability and integrates cleanly into the same infrastructure. Mature fuzzing programs frequently run more than one of these against the same target and compare coverage results, since each tool’s mutation strategy explores the input space slightly differently.

What is reverse engineering, and how does it connect to fuzzing?

The process of analyzing compiled software or hardware to understand its internal structure and behavior without access to original source code, typically using disassemblers and debuggers to reconstruct how a program actually works.

Reverse engineering and fuzzing feed each other directly in practice. When fuzzing a black-box target with no available source, reverse engineering the input format first, understanding what a valid file or protocol actually looks like, produces a dramatically more effective fuzzer than pure random mutation against an unknown structure. After a fuzzer finds a crash, reverse engineering skills become essential again during triage, determining whether that crash represents a genuinely exploitable security vulnerability or a harmless, low-severity bug not worth further investigation.

Continuous fuzzing in production: how Google’s OSS-Fuzz works

OSS-Fuzz is Google’s continuous fuzzing infrastructure for open-source software: maintainers submit fuzz targets and build instructions, and the infrastructure runs multiple fuzzing engines and sanitizer combinations against the project around the clock, automatically filing bugs as they’re discovered.

This model matters because it treats fuzzing as an ongoing process rather than a one-time pre-release check. OSS-Fuzz has reported thousands of vulnerabilities and tens of thousands of bugs across open-source projects it monitors, running libFuzzer, AFL++, and Honggfuzz combined with different sanitizers simultaneously against the same codebase. Any business relying on open-source components, which is nearly every business today, benefits indirectly from this infrastructure, though understanding it exists is also a useful reminder that your own custom, internally developed code gets none of this continuous scrutiny unless you build something similar for it yourself.

Getting started: your first fuzzing target without a research team

Start with libFuzzer against one small, well-defined function that parses external input, a file format parser or a data validation routine, paired with AddressSanitizer enabled from the very first run, rather than attempting to fuzz an entire application at once.

Choose a target genuinely worth the effort: code that processes untrusted, external input directly is where fuzzing delivers the highest return, since that’s exactly the code attackers can reach. Cyber Security Solutions Ltd helps development teams identify and scope exactly this kind of high-value first fuzzing target as part of broader vulnerability assessment work, since a narrowly scoped, well-instrumented fuzzing target run for days consistently outperforms a broad, unfocused campaign run for hours.