Hubbry Logo
FuzzingFuzzingMain
Open search
Fuzzing
Community hub
Fuzzing
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Fuzzing
Fuzzing
Fuzzing
View on Wikipedia
from Wikipedia
American Fuzzy Lop's afl-fuzz running on a test program

In programming and software development, fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks. Typically, fuzzers are used to test programs that take structured inputs. This structure is specified, such as in a file format or protocol and distinguishes valid from invalid input. An effective fuzzer generates semi-valid inputs that are "valid enough" in that they are not directly rejected by the parser, but do create unexpected behaviors deeper in the program and are "invalid enough" to expose corner cases that have not been properly dealt with.

For the purpose of security, input that crosses a trust boundary is often the most useful.[1] For example, it is more important to fuzz code that handles a file uploaded by any user than it is to fuzz the code that parses a configuration file that is accessible only to a privileged user.

History

[edit]

The term "fuzz" originates from a 1988 class project[2] in the graduate Advanced Operating Systems class (CS736), taught by Prof. Barton Miller at the University of Wisconsin, whose results were subsequently published in 1990.[3][4] To fuzz test a UNIX utility meant to automatically generate random input and command-line parameters for the utility. The project was designed to test the reliability of UNIX command line programs by executing a large number of random inputs in quick succession until they crashed. Miller's team was able to crash 25 to 33 percent of the utilities that they tested. They then debugged each of the crashes to determine the cause and categorized each detected failure. To allow other researchers to conduct similar experiments with other software, the source code of the tools, the test procedures, and the raw result data were made publicly available.[5] This early fuzzing would now be called black box, generational, unstructured (dumb or "classic") fuzzing.

According to Prof. Barton Miller, "In the process of writing the project description, I needed to give this kind of testing a name. I wanted a name that would evoke the feeling of random, unstructured data. After trying out several ideas, I settled on the term fuzz."[4]

A key contribution of this early work was simple (almost simplistic) oracle. A program failed its test if it crashed or hung under the random input and was considered to have passed otherwise. While test oracles can be challenging to construct, the oracle for this early fuzz testing was simple and universal to apply.

In April 2012, Google announced ClusterFuzz, a cloud-based fuzzing infrastructure for security-critical components of the Chromium web browser.[6] Security researchers can upload their own fuzzers and collect bug bounties if ClusterFuzz finds a crash with the uploaded fuzzer.

In September 2014, Shellshock[7] was disclosed as a family of security bugs in the widely used UNIX Bash shell; most vulnerabilities of Shellshock were found using the fuzzer AFL.[8] (Many Internet-facing services, such as some web server deployments, use Bash to process certain requests, allowing an attacker to cause vulnerable versions of Bash to execute arbitrary commands. This can allow an attacker to gain unauthorized access to a computer system.[9])

In April 2015, Hanno Böck showed how the fuzzer AFL could have found the 2014 Heartbleed vulnerability.[10][11] (The Heartbleed vulnerability was disclosed in April 2014. It is a serious vulnerability that allows adversaries to decipher otherwise encrypted communication. The vulnerability was accidentally introduced into OpenSSL which implements TLS and is used by the majority of the servers on the internet. Shodan reported 238,000 machines still vulnerable in April 2016;[12] 200,000 in January 2017.[13])

In August 2016, the Defense Advanced Research Projects Agency (DARPA) held the finals of the first Cyber Grand Challenge, a fully automated capture-the-flag competition that lasted 11 hours.[14] The objective was to develop automatic defense systems that can discover, exploit, and correct software flaws in real-time. Fuzzing was used as an effective offense strategy to discover flaws in the software of the opponents. It showed tremendous potential in the automation of vulnerability detection. The winner was a system called "Mayhem"[15] developed by the team ForAllSecure led by David Brumley.

In September 2016, Microsoft announced Project Springfield, a cloud-based fuzz testing service for finding security critical bugs in software.[16]

In December 2016, Google announced OSS-Fuzz which allows for continuous fuzzing of several security-critical open-source projects.[17]

At Black Hat 2018, Christopher Domas demonstrated the use of fuzzing to expose the existence of a hidden RISC core in a processor.[18] This core was able to bypass existing security checks to execute Ring 0 commands from Ring 3.

In September 2020, Microsoft released OneFuzz, a self-hosted fuzzing-as-a-service platform that automates the detection of software bugs.[19] It supports Windows and Linux.[20] It was archived three years later on November 1, 2023.[21]

Early random testing

[edit]

Testing programs with random inputs dates back to the 1950s when data was still stored on punched cards.[22] Programmers would use punched cards that were pulled from the trash or card decks of random numbers as input to computer programs. If an execution revealed undesired behavior, a bug had been detected.

The execution of random inputs is also called random testing or monkey testing.

In 1981, Duran and Ntafos formally investigated the effectiveness of testing a program with random inputs.[23][24] While random testing had been widely perceived to be the worst means of testing a program, the authors could show that it is a cost-effective alternative to more systematic testing techniques.

In 1983, Steve Capps at Apple developed "The Monkey",[25] a tool that would generate random inputs for classic Mac OS applications, such as MacPaint.[26] The figurative "monkey" refers to the infinite monkey theorem which states that a monkey hitting keys at random on a typewriter keyboard for an infinite amount of time will eventually type out the entire works of Shakespeare. In the case of testing, the monkey would write the particular sequence of inputs that would trigger a crash.

In 1991, the crashme tool was released, which was intended to test the robustness of Unix and Unix-like operating systems by randomly executing systems calls with randomly chosen parameters.[27]

Types

[edit]

A fuzzer can be categorized in several ways:[28][1]

  1. A fuzzer can be generation-based or mutation-based depending on whether inputs are generated from scratch or by modifying existing inputs.
  2. A fuzzer can be dumb (unstructured) or smart (structured) depending on whether it is aware of input structure.
  3. A fuzzer can be white-, grey-, or black-box, depending on whether it is aware of program structure.

Reuse of existing input seeds

[edit]

A mutation-based fuzzer leverages an existing corpus of seed inputs during fuzzing. It generates inputs by modifying (or rather mutating) the provided seeds.[29] For example, when fuzzing the image library libpng, the user would provide a set of valid PNG image files as seeds while a mutation-based fuzzer would modify these seeds to produce semi-valid variants of each seed. The corpus of seed files may contain thousands of potentially similar inputs. Automated seed selection (or test suite reduction) allows users to pick the best seeds in order to maximize the total number of bugs found during a fuzz campaign.[30]

A generation-based fuzzer generates inputs from scratch. For instance, a smart generation-based fuzzer[31] takes the input model that was provided by the user to generate new inputs. Unlike mutation-based fuzzers, a generation-based fuzzer does not depend on the existence or quality of a corpus of seed inputs.

Some fuzzers have the capability to do both, to generate inputs from scratch and to generate inputs by mutation of existing seeds.[32]

Aware of input structure

[edit]

Typically, fuzzers are used to generate inputs for programs that take structured inputs, such as a file, a sequence of keyboard or mouse events, or a sequence of messages. This structure distinguishes valid input that is accepted and processed by the program from invalid input that is quickly rejected by the program. What constitutes a valid input may be explicitly specified in an input model. Examples of input models are formal grammars, file formats, GUI-models, and network protocols. Even items not normally considered as input can be fuzzed, such as the contents of databases, shared memory, environment variables or the precise interleaving of threads. An effective fuzzer generates semi-valid inputs that are "valid enough" so that they are not directly rejected from the parser and "invalid enough" so that they might stress corner cases and exercise interesting program behaviours.

A smart (model-based,[32] grammar-based,[31][33] or protocol-based[34]) fuzzer leverages the input model to generate a greater proportion of valid inputs. For instance, if the input can be modelled as an abstract syntax tree, then a smart mutation-based fuzzer[33] would employ random transformations to move complete subtrees from one node to another. If the input can be modelled by a formal grammar, a smart generation-based fuzzer[31] would instantiate the production rules to generate inputs that are valid with respect to the grammar. However, generally the input model must be explicitly provided, which is difficult to do when the model is proprietary, unknown, or very complex. If a large corpus of valid and invalid inputs is available, a grammar induction technique, such as Angluin's L* algorithm, would be able to generate an input model.[35][36]

A dumb fuzzer[37][38] does not require the input model and can thus be employed to fuzz a wider variety of programs. For instance, AFL is a dumb mutation-based fuzzer that modifies a seed file by flipping random bits, by substituting random bytes with "interesting" values, and by moving or deleting blocks of data. However, a dumb fuzzer might generate a lower proportion of valid inputs and stress the parser code rather than the main components of a program. The disadvantage of dumb fuzzers can be illustrated by means of the construction of a valid checksum for a cyclic redundancy check (CRC). A CRC is an error-detecting code that ensures that the integrity of the data contained in the input file is preserved during transmission. A checksum is computed over the input data and recorded in the file. When the program processes the received file and the recorded checksum does not match the re-computed checksum, then the file is rejected as invalid. Now, a fuzzer that is unaware of the CRC is unlikely to generate the correct checksum. However, there are attempts to identify and re-compute a potential checksum in the mutated input, once a dumb mutation-based fuzzer has modified the protected data.[39]

Aware of program structure

[edit]

Typically, a fuzzer is considered more effective if it achieves a higher degree of code coverage. The rationale is, if a fuzzer does not exercise certain structural elements in the program, then it is also not able to reveal bugs that are hiding in these elements. Some program elements are considered more critical than others. For instance, a division operator might cause a division by zero error, or a system call may crash the program.

A black-box fuzzer[37][33] treats the program as a black box and is unaware of internal program structure. For instance, a random testing tool that generates inputs at random is considered a blackbox fuzzer. Hence, a blackbox fuzzer can execute several hundred inputs per second, can be easily parallelized, and can scale to programs of arbitrary size. However, blackbox fuzzers may only scratch the surface and expose "shallow" bugs. Hence, there are attempts to develop blackbox fuzzers that can incrementally learn about the internal structure (and behavior) of a program during fuzzing by observing the program's output given an input. For instance, LearnLib employs active learning to generate an automaton that represents the behavior of a web application.

A white-box fuzzer[38][32] leverages program analysis to systematically increase code coverage or to reach certain critical program locations. For instance, SAGE[40] leverages symbolic execution to systematically explore different paths in the program (a technique known as concolic execution). If the program's specification is available, a whitebox fuzzer might leverage techniques from model-based testing to generate inputs and check the program outputs against the program specification. A whitebox fuzzer can be very effective at exposing bugs that hide deep in the program. However, the time used for analysis (of the program or its specification) can become prohibitive. If the whitebox fuzzer takes relatively too long to generate an input, a blackbox fuzzer will be more efficient.[41] Hence, there are attempts to combine the efficiency of blackbox fuzzers and the effectiveness of whitebox fuzzers.[42]

A gray-box fuzzer leverages instrumentation rather than program analysis to glean information about the program. For instance, AFL and libFuzzer utilize lightweight instrumentation to trace basic block transitions exercised by an input. This leads to a reasonable performance overhead but informs the fuzzer about the increase in code coverage during fuzzing, which makes gray-box fuzzers extremely efficient vulnerability detection tools.[43]

Uses

[edit]

Fuzzing is used mostly as an automated technique to expose vulnerabilities in security-critical programs that might be exploited with malicious intent.[6][16][17] More generally, fuzzing is used to demonstrate the presence of bugs rather than their absence. Running a fuzzing campaign for several weeks without finding a bug does not prove the program correct.[44] After all, the program may still fail for an input that has not been executed, yet; executing a program for all inputs is prohibitively expensive. If the objective is to prove a program correct for all inputs, a formal specification must exist and techniques from formal methods must be used.

Exposing bugs

[edit]

In order to expose bugs, a fuzzer must be able to distinguish expected (normal) from unexpected (buggy) program behavior. However, a machine cannot always distinguish a bug from a feature. In automated software testing, this is also called the test oracle problem.[45][46]

Typically, a fuzzer distinguishes between crashing and non-crashing inputs in the absence of specifications and to use a simple and objective measure. Crashes can be easily identified and might indicate potential vulnerabilities (e.g., denial of service or arbitrary code execution). However, the absence of a crash does not indicate the absence of a vulnerability. For instance, a program written in C may or may not crash when an input causes a buffer overflow. Rather the program's behavior is undefined.

To make a fuzzer more sensitive to failures other than crashes, sanitizers can be used to inject assertions that crash the program when a failure is detected.[47][48] There are different sanitizers for different kinds of bugs:

Fuzzing can also be used to detect "differential" bugs if a reference implementation is available. For automated regression testing,[49] the generated inputs are executed on two versions of the same program. For automated differential testing,[50] the generated inputs are executed on two implementations of the same program (e.g., lighttpd and httpd are both implementations of a web server). If the two variants produce different output for the same input, then one may be buggy and should be examined more closely.

Validating static analysis reports

[edit]

Static program analysis analyzes a program without actually executing it. This might lead to false positives where the tool reports problems with the program that do not actually exist. Fuzzing in combination with dynamic program analysis can be used to try to generate an input that actually witnesses the reported problem.[51]

Browser security

[edit]

Modern web browsers undergo extensive fuzzing. The Chromium code of Google Chrome is continuously fuzzed by the Chrome Security Team with 15,000 cores.[52] For Microsoft Edge [Legacy] and Internet Explorer, Microsoft performed fuzzed testing with 670 machine-years during product development, generating more than 400 billion DOM manipulations from 1 billion HTML files.[53][52]

Toolchain

[edit]

A fuzzer produces a large number of inputs in a relatively short time. For instance, in 2016 the Google OSS-fuzz project produced around 4 trillion inputs a week.[17] Hence, many fuzzers provide a toolchain that automates otherwise manual and tedious tasks which follow the automated generation of failure-inducing inputs.

Automated bug triage

[edit]
Main article: Bug triage

Automated bug triage is used to group a large number of failure-inducing inputs by root cause and to prioritize each individual bug by severity. A fuzzer produces a large number of inputs, and many of the failure-inducing ones may effectively expose the same software bug. Only some of these bugs are security-critical and should be patched with higher priority. For instance the CERT Coordination Center provides the Linux triage tools which group crashing inputs by the produced stack trace and lists each group according to their probability to be exploitable.[54] The Microsoft Security Research Centre (MSEC) developed the "!exploitable" tool which first creates a hash for a crashing input to determine its uniqueness and then assigns an exploitability rating:[55]

  • Exploitable
  • Probably Exploitable
  • Probably Not Exploitable, or
  • Unknown.

Previously unreported, triaged bugs might be automatically reported to a bug tracking system. For instance, OSS-Fuzz runs large-scale, long-running fuzzing campaigns for several security-critical software projects where each previously unreported, distinct bug is reported directly to a bug tracker.[17] The OSS-Fuzz bug tracker automatically informs the maintainer of the vulnerable software and checks in regular intervals whether the bug has been fixed in the most recent revision using the uploaded minimized failure-inducing input.

Automated input minimization

[edit]

Automated input minimization (or test case reduction) is an automated debugging technique to isolate that part of the failure-inducing input that is actually inducing the failure.[56][57] If the failure-inducing input is large and mostly malformed, it might be difficult for a developer to understand what exactly is causing the bug. Given the failure-inducing input, an automated minimization tool would remove as many input bytes as possible while still reproducing the original bug. For instance, Delta Debugging is an automated input minimization technique that employs an extended binary search algorithm to find such a minimal input.[58]

[edit]
See also: American fuzzy lop (fuzzer) § Forks

The following is a list of fuzzers described as "popular", "widely used", or similar in the academic literature.[59][60]

Name White/gray/black-box Smart/dumb Description Written in License
AFL[61][62] Gray Dumb C Apache 2.0
AFL++[63] Gray Dumb C Apache 2.0
AFLFast[64] Gray Dumb C Apache 2.0
Angora[65] Gray Dumb C++ Apache 2.0
honggfuzz[66][67] Gray Dumb C Apache 2.0
QSYM[68] [?] [?] [?] [?]
SymCC[69] White[70] [?] C++ GPL, LGPL
T-Fuzz[71] [?] [?] [?] [?]
VUzzer[72] [?] [?] [?] [?]

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Fuzzing

View on Grokipedia
from Grokipedia
Fuzzing, also known as fuzz testing, is an automated technique that involves providing invalid, unexpected, or random data as inputs to a in order to identify defects such as crashes, memory leaks, assertion failures, or security vulnerabilities. This method systematically stresses the software under test by generating malformed inputs, often at high speed, to uncover implementation bugs that might otherwise go undetected through traditional testing approaches. The origins of fuzzing trace back to 1988, when Professor Barton P. Miller and his students at the University of Wisconsin-Madison developed the technique during a research project on the reliability of UNIX utilities. Inspired by a that caused electrical noise to crash their programs, they created a tool to generate random inputs—coining the term "fuzz" after the random noise—and found that 25-33% of common utilities crashed, hung, or otherwise failed under such conditions. This empirical study, published in 1990, demonstrated fuzzing's effectiveness in revealing reliability issues and laid the foundation for its evolution into a cornerstone of software assurance practices. Fuzzing encompasses several variants based on the tester's knowledge of the software's internals: black-box fuzzing, which operates without access to and relies on external inputs; white-box fuzzing, which uses full code analysis to guide input generation; and grey-box fuzzing, a hybrid that incorporates partial feedback to improve efficiency. Additionally, fuzzers can be categorized by input generation methods, such as mutation-based (altering valid inputs) or generation-based (creating inputs from scratch based on specifications). These approaches are particularly valuable for discovering security flaws like buffer overflows and injection vulnerabilities. In recent years, advancements including coverage-guided fuzzers and integration with have enhanced its scalability and precision, with ongoing research exploring AI-assisted techniques to address complex software ecosystems.

Fundamentals

Definition and Purpose

Fuzzing, also known as fuzz testing, is an automated technique that involves providing invalid, unexpected, or random data as inputs to a in order to discover defects such as crashes, failed assertions, or memory errors. This approach was pioneered in the late as a simple method for feeding random inputs to applications to evaluate their reliability. The primary purposes of fuzzing are to identify bugs and expose security vulnerabilities, such as buffer overflows, use-after-free errors, and denial-of-service conditions, thereby enhancing software robustness without necessitating detailed knowledge of the program's internal structure or . By systematically perturbing inputs, fuzzing complements traditional testing methods and has proven effective in uncovering issues that evade specification-based verification. In distinction from other testing methodologies, basic fuzzing operates as a black-box technique, observing only the external input-output of the program without access to its internals, unlike white-box or model-driven approaches that rely on program semantics or formal specifications. The basic workflow entails generating diverse test inputs, injecting them into the target application, monitoring for anomalies like crashes or hangs, and logging failures for subsequent analysis.

Core Principles

Fuzzing operates through three fundamental components that form its operational backbone. The input generator creates cases, often by mutating valid inputs or generating novel ones from models of expected formats, to probe the program's behavior under unexpected conditions. The execution environment provides a controlled setting to run the target program with these inputs, typically sandboxed to manage resource usage and isolate potential crashes or hangs. The then monitors outputs to detect anomalies, such as segmentation faults, assertion failures, or sanitizer-detected issues like memory errors, flagging them as potential defects. At its core, fuzzing explores the vast input space of a program by systematically generating diverse to uncover hidden flaws. Random sampling forms a primary , where are produced pseudo-randomly to broadly cover possible values and reveal implementation bugs that deterministic testing might miss. Boundary value testing complements this by focusing on edge cases, such as maximum or minimum values for types, which are prone to overflows or validation errors. Feedback loops enable iterative refinement, where observations from prior executions—such as execution traces or coverage —guide the generation of subsequent to prioritize unexplored regions and enhance . Success in fuzzing is evaluated using metrics that quantify exploration depth and defect detection quality. rates, for instance, measure the proportion of the program's structure exercised by test cases, with branch coverage calculated as the percentage of unique branches executed relative to total branches: Branch Coverage Percentage=(Unique Branches ExecutedTotal Branches)×100\text{Branch Coverage Percentage} = \left( \frac{\text{Unique Branches Executed}}{\text{Total Branches}} \right) \times 100 This metric guides toward deeper code penetration. Crash uniqueness assesses the diversity of failures found, counting distinct crashes (e.g., via stack traces or hashes) to avoid redundant reports and indicate broader exposure. Fault revelation efficiency evaluates the rate of novel bugs discovered per unit of fuzzing time or effort, providing a practical gauge of the technique's in real-world testing scenarios. Instrumentation plays a pivotal role in enabling these principles by embedding lightweight probes into the target program during compilation or execution. These probes collect runtime data, such as transitions or accesses, to inform feedback loops without modifying the program's observable semantics or performance significantly. Techniques like binary allow this monitoring even for unmodified binaries, ensuring compatibility across diverse software environments.

Historical Development

Origins and Early Experiments

The concept of in emerged in the 1950s during the era, when programmers commonly used decks of punch cards with random or garbage data to probe for errors in early computer programs, simulating real-world input variability without systematic methods. This practice laid informal groundwork for automated input-based testing, and by the and , rudimentary automated checks were incorporated into early operating systems to validate system stability against unexpected conditions. The modern technique of fuzzing originated in 1988 as a graduate class project in the Advanced Operating Systems course (CS736) taught by Barton P. Miller at the University of Wisconsin-Madison. Inspired by a thunderstorm that introduced line noise into Miller's dial-up connection, causing random corruption of inputs and subsequent crashes in UNIX utilities, the project aimed to systematically evaluate software reliability using automated random inputs. Students developed a tool called "fuzz" to generate random ASCII streams, including printable and non-printable characters, NULL bytes, and varying lengths up to 25,000 bytes, feeding them into 88 standard UNIX utilities across seven different UNIX implementations, such as 4.3BSD, SunOS 3.2, and AIX 1.1. For interactive programs, a complementary tool named "ptyjig" simulated random keyboard and mouse inputs via pseudo-terminals. The experiments revealed significant vulnerabilities, with 25-33% of the utilities crashing or hanging across the tested systems—for instance, 29% on a VAX running 4.3BSD and 25% on a Sun workstation running . Common failures included segmentation violations, core dumps, and infinite loops, often triggered by poor input validation in areas like buffer and string parsing; notable examples involved utilities like "troff" and "ld" producing exploitable faults. These results, published in 1990, demonstrated fuzzing's potential to uncover bugs overlooked by traditional testing, prompting UNIX vendors to integrate similar tools into their quality assurance processes. Despite its successes, the early fuzzing approach had notable limitations, including the purely random nature of input generation, which lacked structure or guidance toward edge cases, potentially missing deeper program paths. Crash analysis was also manual and challenging, relying on core dumps and examination without access to for many utilities, limiting reproducibility and root-cause diagnosis.

Key Milestones and Modern Advancements

In the late and early , fuzzing evolved from ad-hoc to more structured frameworks targeted at specific domains. The PROTOS project, initiated in 1999 by researchers at the , introduced a systematic approach to protocol fuzzing by generating test cases based on protocol specifications to uncover implementation flaws in network software. This framework emphasized heuristic-based mutation of protocol fields, leading to the discovery of over 50 vulnerabilities in widely used protocols like SIP and SNMP by 2003. Building on this, Microsoft's SAGE (Automated Whitebox Fuzz Testing) tool, released in 2008, pioneered whitebox fuzzing by combining with random input generation to systematically explore program paths in binary applications. SAGE significantly enhanced coverage in , reportedly finding dozens of bugs in Windows components that methods missed. The 2010s marked a surge in coverage-guided fuzzing, driven by open-source tools that integrated genetic algorithms and compiler instrumentation. American Fuzzy Lop (AFL), developed by Michał Zalewski and publicly released in 2013, employed novel compile-time to track code coverage and evolve inputs via , achieving breakthroughs in efficiency for binary fuzzing. AFL played a pivotal role in exposing follow-up vulnerabilities related to the Shellshock bug (CVE-2014-6271 and CVE-2014-6277) in Bash during 2014, demonstrating fuzzing's ability to uncover command injection flaws in shell interpreters. Concurrently, LLVM's LibFuzzer, introduced in 2015, provided an in-process fuzzing engine tightly integrated with AddressSanitizer and coverage , enabling seamless fuzzing of C/C++ libraries with minimal overhead. This tool's adoption accelerated bug detection in projects like , where it complemented sanitizers to identify memory errors. Google's OSS-Fuzz, launched in , represented a toward continuous, large-scale fuzzing for , integrating engines like AFL and LibFuzzer into pipelines across thousands of cores. As of May 2025, OSS-Fuzz has helped identify and fix over 13,000 vulnerabilities and 50,000 bugs across 1,000 projects, underscoring fuzzing's role in proactive maintenance. In parallel, syzkaller, developed by starting in 2015, adapted coverage-guided fuzzing for operating system kernels by generating syscall sequences informed by kernel coverage feedback, leading to thousands of bug reports. For instance, syzkaller exposed race conditions and memory issues in subsystems like networking and filesystems, with ongoing enhancements improving its state-machine modeling for complex kernel interactions. Modern advancements from 2017 onward have focused on scalability and hybridization. AFL++, a of AFL initiated in 2017, incorporated optimizations like mirror scheduling and advanced strategies (e.g., dictionary-based and havoc modes), boosting performance by up to 50% on real-world benchmarks while maintaining compatibility. This evolution enabled deeper exploration in environments like web browsers and embedded systems. Google's ClusterFuzz, first deployed in 2011 and scaled extensively by the 2010s, exemplified cloud-based fuzzing by orchestrating distributed execution across 25,000+ cores, automating , and integrating with OSS-Fuzz to handle high-volume campaigns. Its impact was evident in high-profile detections, such as Codenomicon's 2014 fuzzing-based discovery of the vulnerability (CVE-2014-0160) in , which exposed a buffer over-read affecting millions of servers. Recent trends up to 2025 include hybrid techniques blending fuzzing with for seed prioritization, as seen in tools like those extending syzkaller, and AI enhancements in OSS-Fuzz, which in 2024 discovered 26 new vulnerabilities in established projects, including a long-standing flaw in . further amplifying detection rates in kernel and protocol domains.

Fuzzing Techniques

Mutation-Based Fuzzing

Mutation-based fuzzing generates test inputs by applying random or modifications to a set of valid inputs, such as existing files, network packets, or messages, without requiring prior knowledge of the input format or protocol. The process begins by selecting a from a queue, optionally trimming it to minimize size while preserving behavior, then applying a series of s to produce variants for execution against the target program. Common mutation operations include bit flips (e.g., inverting 1, 2, or 4 bits at random positions), arithmetic modifications (e.g., adding or subtracting small integers to 8-, 16-, or 32-bit values), byte insertions or deletions, overwriting with predefined "interesting" values (e.g., 0, 1, or boundary cases like 0xFF), and dictionary-based swaps using domain-specific tokens. If a mutated input triggers new or crashes, it is added to the queue for further ; otherwise, the process cycles to the next . This approach offers low computational overhead due to its reliance on simple, stateless transformations and the reuse of valid seeds, which increases the likelihood of passing initial stages compared to purely random . It is particularly effective for binary or unstructured formats where structural models are unavailable or costly to develop, enabling rapid exploration of edge cases with minimal setup. For instance, dictionary-based enhance by incorporating protocol-specific terms, such as HTTP headers, to target relevant input regions without exhaustive random trials. Key algorithms optimize seed selection and mutation application to balance exploration and exploitation. The PowerSchedule algorithm, introduced in AFL, dynamically assigns "energy" (i.e., the number of mutations attempted per seed) based on factors like input length, path depth, and historical coverage contributions, favoring shorter or more promising seeds to allocate computational resources efficiently—typically executing 1 to 10 times more mutations on high-value paths. In havoc mode, a core mutation strategy, random perturbations are stacked sequentially (e.g., 2 to 4096 operations per input, selected via a batch exponent tt where the number of tweaks is 2t2^t), including bit flips, arithmetic changes, block deletions or duplications, and dictionary insertions, with a low probability (around 6%) of invoking custom extensions to avoid over-mutation. The mutation rate is calibrated inversely with input length to maintain diversity; for an input of length LL, the probability of altering a specific byte approximates 1/L1 / L, ensuring proportional changes across varying sizes. In practice, mutation-based fuzzing has proven effective for testing file parsers with minimal structural knowledge. A study on image parsers using tools like zzuf applied bit-level mutations to files (e.g., varying chunk counts from 5 to 9), generating 200,000 variants per , which exposed handling flaws but achieved only ~24% of the obtained by generation-based methods due to limited deep-path exploration without format awareness. Similarly, a 2024 study fuzzing XML parsers such as , Apache Xerces, and Expat found that byte-level mutations with AFL detected more crashes than tree-level strategies, particularly in Xerces (up to 57 crashes with protocol-conformant seeds vs. 38 with public seeds), though no security vulnerabilities beyond illegal instructions were found.

Generation-Based Fuzzing

Generation-based fuzzing employs formal models such as context-free grammars, schemas, or finite state machines (FSMs) to synthetically generate test inputs that adhere to specified input formats or protocols while incorporating deliberate faults. This method contrasts with mutation-based approaches by constructing inputs from scratch according to the model, ensuring syntactic validity to reach deeper program states without early rejection by input parsers. In protocol fuzzing, FSMs model the sequence of states and transitions, allowing the creation of input sequences that simulate protocol handshakes or sessions with injected anomalies. Key techniques include random grammar mutations, where production rules are probabilistically altered to introduce variations in structure, and constraint solving to produce semantically valid yet malformed data. For example, constraint solvers can enforce field dependencies in a schema while randomizing values to violate expected behaviors, such as generating HTTP requests with invalid headers that still parse correctly. In practice, parsers generated from tools like for HTTP grammars enable the derivation of test cases by expanding non-terminals and mutating terminals, focusing faults on semantic layers. The primary benefits of generation-based fuzzing lie in its ability to explore complex state spaces through valid inputs, enabling tests of intricate logic in parsers and protocol handlers that random or mutated might bypass. However, this comes at the cost of higher computational overhead, as input generation involves recursive expansion of the model for each test case. The scale of possible derivations in a without is determined by the product of the number of rule choices for each non-terminal, leading to rapid growth in input variety but increased . In network protocol applications, generation-based methods facilitate stateful fuzzing by producing sequences that respect transition dependencies, as seen in frameworks like Boofuzz, which use FSM-driven primitives to craft multi-packet interactions for protocols such as TCP or SIP. This approach has proven effective for uncovering vulnerabilities in state-dependent implementations, where invalid sequences reveal flaws in session management.

Coverage-Guided and Hybrid Fuzzing

Coverage-guided fuzzing enhances traditional mutation-based approaches by incorporating runtime feedback to direct the generation of test inputs toward unexplored code regions. This technique involves instrumenting the target program to monitor execution coverage, typically at the level of basic blocks or control-flow edges, using lightweight mechanisms such as to record reached transitions. Inputs that trigger new coverage are assigned higher priority for mutation, enabling efficient exploration of the program's state space; for instance, (AFL) employs a shared to track edge coverage across executions, favoring "power schedules" that allocate more mutations to promising seeds. This feedback loop contrasts with undirected fuzzing by systematically increasing , often achieving deeper penetration into complex binaries. Hybrid fuzzing builds on coverage guidance by integrating complementary techniques, such as generation-based methods or , to overcome limitations in path exploration and input synthesis. In these approaches, is combined with adaptive seeding strategies; for example, a fitness score can guide prioritization via the formula edge_score=new_edges_discoveredtotal_mutations\text{edge\_score} = \frac{\text{new\_edges\_discovered}}{\text{total\_mutations}}, which quantifies the efficiency of inputs in revealing novel . Grey-box models further hybridize by selectively invoking to resolve hard-to-reach branches when coverage stalls, as in Driller, which augments fuzzing with concolic execution to generate inputs that bypass concrete execution dead-ends without full symbolic overhead. More recent advancements incorporate , such as NEUZZ, which trains neural networks to approximate program behavior and enable gradient-based optimization for fuzzing guidance, smoothing discrete branch decisions into continuous landscapes for better seed selection. As of 2025, further advancements include LLM-guided hybrid fuzzing, which uses large language models for semantic-aware input generation to improve exploration in stateful systems. These methods have demonstrated significant effectiveness in detecting vulnerabilities in large-scale, complex software, including web browsers, where traditional fuzzing struggles with deep state interactions. For example, coverage-guided hybrid techniques have uncovered numerous security bugs in by achieving higher coverage and faster crash reproduction compared to black-box alternatives, contributing to real-world vulnerability disclosure in production environments. Quantitative evaluations show improvements in bug-finding rates, with hybrid fuzzers like Driller achieving a 13% increase in unique crashes (77 vs. 68) over pure coverage-guided baselines like AFL in the DARPA CGC benchmarks.

Applications

Bug Detection and Vulnerability Exposure

Fuzzing uncovers software defects by systematically supplying invalid, malformed, or random inputs to program interfaces, with the goal of provoking exceptions, corruptions, or logic errors that reveal underlying flaws. This dynamic approach monitors runtime behavior for indicators of , such as segmentation faults or assertion violations, which signal potential defects in code handling edge cases. By exercising rarely encountered paths, fuzzing exposes issues that deterministic testing often misses, including those arising from unexpected data flows or boundary conditions. Among the vulnerabilities commonly detected, buffer overflows stand out, where excessive input data overwrites adjacent memory regions, potentially allowing . Integer overflows, which occur when arithmetic operations exceed representable values in a , can lead to incorrect computations and subsequent exploits. Race conditions, involving timing-dependent interactions in multithreaded environments, manifest as inconsistent states or under concurrent access. In C/C++ programs, fuzzing frequently identifies null pointer dereferences by generating inputs that nullify pointers before dereference operations, triggering crashes that pinpoint the error location. Studies indicate that fuzzing outperforms by executing programs orders of magnitude more frequently, thereby exploring deeper into state spaces and uncovering unique crashes that human-led efforts overlook. For instance, empirical evaluations show fuzzers detecting vulnerabilities in complex systems where traditional methods achieve limited coverage. Integration with memory sanitizers like amplifies this impact by instrumenting code to intercept and report precise error details, such as the and offset for a , enabling faster triage and patching. To sustain effectiveness over time, corpus-based fuzzing employs seed input collections derived from prior tests or real-world , replaying them to verify regressions and mutate them for new discoveries. This strategy ensures that code modifications do not reintroduce fixed bugs while expanding coverage. Continuous fuzzing embedded in pipelines further automates this process, running fuzzer jobs on every commit or pull request to catch defects early in the development cycle, thereby reducing the cost of remediation.

Validation of Static Analysis

Fuzzing serves as a dynamic complement to static analysis tools, which often generate warnings about potential issues such as memory leaks or buffer overflows but suffer from high false positive rates. In this validation process, outputs from static analyzers like or Infer are used to guide targeted fuzzing campaigns, where fuzzers generate inputs specifically aimed at reproducing the flagged code paths or functions. This involves extracting relevant code slices or hotspots from the warnings—such as tainted data flows in taint analysis—and creating minimal, compilable binaries for fuzzing, allowing the fuzzer to exercise the suspected vulnerable locations efficiently. The primary benefit of this approach is the reduction of false positives through empirical verification: if a warning does not lead to a crash or anomaly under extensive fuzzing, it is likely spurious, thereby alleviating the manual burden on developers. For instance, in scenarios involving taint analysis warnings for potential information leaks, fuzzing can confirm whether tainted inputs actually propagate to sensitive sinks, as demonstrated in evaluations on libraries like where alerts were pruned if non-crashing. This method not only confirms true positives but also provides concrete evidence for dismissal, improving overall developer productivity in large-scale . Integration often employs feedback-directed fuzzing techniques, where static hotspots inform the fuzzer's power schedule or seed selection to prioritize exploration toward warning locations. Tools like FuzzSlice automate this by generating type-aware inputs for function-level slices, while advanced frameworks such as Lyso use multi-step directed greybox fuzzing, correlating alarms across program flows (via control and data flow graphs) to break validation into sequential goals. A key metric for effectiveness is the false positive reduction rate; for example, FuzzSlice identified 62% of developer-confirmed false positives in open-source warnings by failing to trigger crashes on them, and hybrid approaches have reported up to 100% false positive elimination in benchmark tests. Case studies in large codebases highlight practical impact, such as applying targeted fuzzing to validate reports in projects like and , where static tools flagged numerous potential issues but fuzzing confirmed only a subset, enabling focused fixes. Similarly, directed fuzzing guided by static analysis on libraries (e.g., Libsndfile) has uncovered and verified previously unknown vulnerabilities from alarm correlations, demonstrating for enterprise-scale validation without exhaustive manual review. These integrations underscore fuzzing's role in bridging static warnings to actionable insights, particularly for legacy or complex systems.

Domain-Specific Implementations

Fuzzing has been extensively adapted for , where it targets complex components such as DOM parsers and engines to uncover vulnerabilities that could lead to code execution or data leaks. Google's ClusterFuzz infrastructure, which supports fuzzing of , operates on a scale of 25,000 cores and has identified over 27,000 bugs in Google's codebase, including , as of February 2023. This large-scale deployment enables continuous testing of browser rendering pipelines and script interpreters, leveraging coverage-guided techniques to prioritize inputs that exercise rarely reached code paths in these high-risk areas. In kernel and operating system fuzzing, tools like syzkaller focus on interfaces to systematically probe kernel behaviors, including those in device drivers and file systems, which are prone to memory corruption and race conditions. Syzkaller employs grammar-based input generation and kernel coverage feedback via mechanisms like KCOV to discover deep bugs that traditional testing overlooks. As of 2024, syzkaller has uncovered nearly 4,000 vulnerabilities in the alone, many of which affect drivers for storage and . These findings have led to critical patches, demonstrating the tool's effectiveness in simulating real-world OS interactions without requiring full . Fuzzing extends to other domains, such as network protocols, where stateful implementations like TLS demand modeling of handshake sequences and message flows to detect flaws in cryptographic handling or state transitions. Protocol state fuzzing, for instance, has revealed multiple previously unknown vulnerabilities in major TLS libraries, including denial-of-service issues in and , by systematically exploring valid and malformed protocol states. In embedded systems, adaptations for resource-constrained and stateful environments often involve firmware emulation or semi-hosted execution to maintain persistent states across fuzzing iterations, addressing challenges like limited memory and non-deterministic hardware interactions. These tailored approaches have improved coverage in IoT devices and microcontrollers, identifying buffer overflows and logic errors that could compromise system integrity. Scaling fuzzing for domain-specific targets, especially resource-intensive ones like browsers and kernels, relies on distributed infrastructures to distribute workloads across clusters and achieve high throughput. However, challenges arise in efficient task scheduling, where imbalances can lead to underutilized resources or redundant efforts, as well as in managing for stateful targets. Solutions like dynamic centralized schedulers in frameworks such as UniFuzz optimize distribution and strategies across nodes, reducing overhead and enhancing bug discovery rates in large-scale deployments.

Tools and Infrastructure

(AFL) and its enhanced fork AFL++ are prominent coverage-guided fuzzing frameworks that employ mutation-based techniques to generate inputs, leveraging compile-time for efficient branch coverage feedback. AFL uses a fork-server model to minimize process overhead, enabling rapid execution of test cases, while AFL++ extends this with optimizations such as persistent mode for in-memory fuzzing without repeated initialization, custom mutator APIs for domain-specific mutations, and support for various instrumentation backends including and . These frameworks are open-source and widely adopted for fuzzing user-space applications, particularly in C and C++ binaries. LibFuzzer serves as an in-process, coverage-guided evolutionary fuzzer tightly integrated with the compiler infrastructure, allowing seamless linking with the target library to feed mutated inputs directly without external process spawning. It supports and other sanitizers for detecting memory errors during fuzzing sessions, and is commonly invoked via build systems like by adding compiler flags such as -fsanitize=fuzzer to enable . LibFuzzer excels in fuzzing libraries and APIs, prioritizing speed through in-process execution and corpus-based mutation strategies. Other notable frameworks include Honggfuzz, which provides hardware-accelerated coverage feedback using PT or IBS for precise edge detection, alongside software-based options, and supports multi-threaded fuzzing to utilize all CPU cores efficiently. Syzkaller is a specialized, unsupervised coverage-guided fuzzer designed for operating system kernels, generating syscall programs based on declarative descriptions and integrating with kernel coverage tools like KCOV to explore deep code paths. Peach Fuzzer, in its original open-source community edition (no longer actively maintained since 2019), focuses on protocol-oriented fuzzing through generation-based and mutation-based approaches, requiring users to define data models via Peach Pit XML files for structured input creation and stateful testing of network protocols; its technology forms the basis for the actively developed Protocol Fuzzer Community Edition.
FrameworkTypePrimary Languages/TargetsLicense
AFL++Coverage-guided mutationC/C++, binaries (user-space)Apache 2.0
LibFuzzerCoverage-guided evolutionary (in-process)C/C++, libraries/APIsApache 2.0
HonggfuzzCoverage-guided (HW/SW feedback)C/C++, binariesApache 2.0
SyzkallerCoverage-guided (kernel-specific)Kernel syscalls (Linux, others)Apache 2.0
Peach FuzzerGeneration/mutation (protocol-oriented)Protocols, networks (multi-language)MIT
OSS-Fuzz, Google's continuous fuzzing service, integrates frameworks like AFL++ and LibFuzzer to test over 1,000 open-source projects as of 2025, having identified and facilitated fixes for more than 13,000 vulnerabilities and 50,000 bugs across diverse software ecosystems.

Supporting Toolchain Elements

Automated input minimization is a critical post-fuzzing process that reduces the size of failure-inducing inputs to facilitate and analysis. The ddmin algorithm, a foundational delta-debugging technique, systematically partitions the input into subsets and tests them to isolate the minimal set of changes that still trigger the failure, achieving a 1-minimal configuration where removing any element eliminates the bug. This approach has been applied in fuzzing scenarios, where it dramatically shrinks large random inputs; for instance, a 10^6-character fuzz input for the CRTPLOT utility was reduced to a single failure-inducing character in just 24 tests. In practice, such minimization often compresses inputs to 1-10% of their original size or less, enabling developers to focus on relevant portions without extraneous data. Bug triage automation streamlines the classification and prioritization of crashes generated during fuzzing campaigns, which can number in the thousands. Techniques for clustering crashes rely on analyzing stack traces or execution similarities to group related failures by cause, reducing manual review overhead. For example, Igor employs a dual-phase method: first minimizing proof-of-concept inputs via coverage-reduction fuzzing to prune traces, then applying similarity (using the Weisfeiler-Lehman kernel) to cluster crashes, achieving near-100% in grouping for 39 bugs across 10 programs. Complementary tools like AddressSanitizer enhance root cause analysis by instrumenting code to detect memory errors such as use-after-free or buffer overflows at runtime, providing detailed reports that pinpoint violation sites with low overhead (about 73% slowdown). In fuzzing workflows, AddressSanitizer has uncovered over 300 previously unknown bugs in , including 210 heap-use-after-free instances, by enabling rapid test execution and precise error localization. Corpus management optimizes the collection and maintenance of seed inputs for fuzzing, ensuring efficient exploration without redundancy. Seeding involves curating initial inputs that cover diverse code paths, while deduplication algorithms remove similar corpora entries based on coverage or hash signatures to prevent wasteful mutations. Integration with continuous integration (CI) systems automates corpus synchronization across builds, allowing incremental fuzzing sessions to reuse and expand prior discoveries, as seen in frameworks that distill corpora to high-quality subsets improving bug detection rates. This process mitigates redundancy, with studies showing distilled corpora can reduce storage needs while boosting coverage-guided fuzzing effectiveness by focusing on unique, impactful seeds. Reporting pipelines automate the transformation of fuzzing findings into actionable outputs, such as assessments or advisories. These workflows aggregate crash data, apply to validate bugs, and generate reports that include minimized inputs and stack traces for . Advanced pipelines extend to patch suggestion and CVE assignment, using automated analysis to correlate crashes with known vulnerabilities and draft (CVE) entries for confirmed issues. In large-scale setups like OSS-Fuzz, such pipelines have facilitated the reporting of thousands of bugs, streamlining the path from detection to remediation by integrating with issue trackers and databases.

Challenges and Future Directions

Limitations and Common Pitfalls

Fuzzing techniques, while effective for uncovering software vulnerabilities, are inherently constrained by several factors that limit their ability to achieve comprehensive testing. One primary limitation is the difficulty in attaining full , particularly for deep or complex execution paths that require specific input sequences to trigger. Traditional fuzzers often struggle to generate inputs that navigate intricate control flows, leading to gaps in exploration where bugs remain undetected. This issue is exacerbated in programs with non-deterministic behaviors, such as those involving timing-dependent operations or external interactions, where the same input may produce varying outputs, complicating feedback-driven strategies. In multi-threaded programs, fuzzing faces state explosion, as the exponential growth of possible thread interleavings creates an infeasibly large state space, making it challenging to systematically test concurrent behaviors and increasing the likelihood of overlooking race conditions or deadlocks. False negatives represent another significant pitfall, where fuzzing fails to detect existing bugs due to insufficient input diversity or reliance on random mutations without targeted guidance. Bugs triggered only under rare conditions, such as uncommon environmental states or precise value combinations, are particularly prone to evasion, as fuzzers may not sample these scenarios within practical timeframes. Over-dependence on random inputs without mechanisms to ensure semantic validity can result in a high rejection rate of test cases, further reducing the chances of reaching vulnerable code paths and perpetuating incomplete assessments. Resource demands pose practical barriers to fuzzing's scalability, requiring substantial computational power and memory for extended campaigns to yield meaningful results. Long-running fuzzing sessions can consume high CPU and memory resources, especially when processing large input corpora or simulating complex executions, which may render the approach infeasible for resource-constrained environments. A common pitfall is the occurrence of non-reproducible crashes, where detected anomalies cannot be reliably recreated due to timing sensitivities or incomplete , hindering and verification efforts. Environmental factors further complicate fuzzing setups, particularly when targets depend on specific hardware or network configurations that are difficult to replicate in testing environments. Hardware-specific dependencies, such as proprietary peripherals in embedded systems, can lead to inaccurate simulations and missed vulnerabilities that manifest only on actual devices. Network-reliant programs introduce additional challenges, as fuzzing often requires mocking external dependencies, which may not fully capture real-world interactions and result in overlooked issues arising from connectivity or protocol variations. Recent advancements in fuzzing have increasingly incorporated techniques to enhance input generation and mutation strategies. Neural fuzzing approaches, such as Learn&Fuzz introduced in 2017, leverage neural networks to automatically infer input grammars from sample inputs, enabling predictive mutations that improve coverage in grammar-based fuzzing by modeling statistical patterns in valid inputs. This method has demonstrated superior performance in generating syntactically valid test cases for complex protocols, outperforming traditional manual grammar engineering. Building on this, generative adversarial networks (GANs) have emerged for input synthesis, with variational auto-encoder GANs (VAE-GANs) proposed to produce diverse, high-quality fuzzing inputs by learning latent representations of seed data, achieving up to 57% improvement in edge discovery when integrated with AFL++ compared to baseline fuzzers. Similarly, GAN-based seed generation techniques have shown efficacy in creating crash-reproducing inputs from prior failures, particularly for image-processing applications, by adversarially training generators to mimic vulnerable patterns. AI-driven adaptations are further refining fuzzing efficiency through (RL) for dynamic seed scheduling. RL-based hierarchical schedulers, such as those employing multi-level coverage metrics, optimize seed selection in greybox fuzzing by treating the process as a , detecting 20% more bugs compared to tools like AFL on CGC benchmarks. These approaches adaptively prioritize seeds based on rewards from new path coverage, addressing inefficiencies in static scheduling. In parallel, fuzzing for quantum-resistant cryptographic software has gained traction to validate post-quantum algorithm implementations against side-channel and implementation flaws. Techniques combining fuzzing with hardware performance counters have detected vulnerabilities in NIST-standardized post-quantum signatures, such as reduced security in flawed , by monitoring timing discrepancies during fuzz campaigns. Such methods ensure robustness in cryptographic libraries like liboqs, where fuzzing has uncovered bugs in algorithms like HQC before deployment. Broader applications of fuzzing are expanding to novel domains, including testing AI models against adversarial inputs and adapting to serverless environments. Fuzzing machine learning systems involves generating adversarial perturbations to expose robustness issues, with greybox techniques like those in TAEFuzz discovering up to 46.1% more errors in targeted image-based deep learning systems. This bidirectional trend—fuzzing ML models while using ML to enhance fuzzers—promises improved security for deployed AI. In serverless computing, fuzzing frameworks have been tailored to handle ephemeral functions, such as those using WebAssembly in platforms like Spin, where structure-sensitive fuzzers like SwFuzz scale testing across distributed invocations without persistent state overhead. For scalability in edge computing, in-place fuzzing architectures like E-FuzzEdge enable efficient campaigns on resource-constrained devices by minimizing data transfer, boosting throughput by 3-5x in IoT scenarios through localized mutation and feedback loops. Middleware-based tools like EdgeFuzz further support distributed fuzzing in edge networks, coordinating tests across nodes to uncover inter-device vulnerabilities. Future research directions emphasize hybrid methodologies and ethical frameworks to address evolving challenges. Integrating fuzzing with formal verification, as in HyPFuzz, uses symbolic execution to guide fuzzers toward hard-to-reach processor states, detecting 100% of known bugs in benchmarks like RISC-V cores while reducing manual effort. Ethical fuzzing practices for privacy-sensitive applications prioritize responsible disclosure and data minimization, ensuring tests on apps handling personal information comply with standards like GDPR by anonymizing inputs and limiting exposure of sensitive paths, as outlined in prudent evaluation guidelines. These hybrids and ethical considerations are poised to make fuzzing more reliable and deployable in critical systems, fostering verifiable security without compromising user privacy.

References

  1. https://www.nist.gov/publications/fuzz-testing-software-assurance
  2. https://owasp.org/www-community/Fuzzing
  3. https://dl.acm.org/doi/10.1145/96267.96279
  4. https://www.paradyn.org/papers/fuzz.pdf
  5. https://www.imperva.com/learn/application-security/fuzzing-fuzz-testing/
  6. https://www.code-intelligence.com/blog/fuzz-testing-landscape-2025
  7. https://pages.cs.wisc.edu/~bart/fuzz/fuzz.html
  8. https://dl.acm.org/doi/10.1145/3512345
  9. https://wcventure.github.io/FuzzingPaper/Paper/TRel18_Fuzzing.pdf
  10. https://arxiv.org/pdf/1808.09700
  11. https://www.usenix.org/system/files/raid2019-wang-jinghan.pdf
  12. https://www.usenix.org/system/files/sec21fall-nagy.pdf
  13. http://www.cs.sun.ac.za/courses/cs771/resources/ResearchReport2018.pdf
  14. https://www.testingreferences.com/testinghistory.php
  15. https://pages.cs.wisc.edu/~bart/fuzz/
  16. https://www.ndss-symposium.org/ndss2008/automated-whitebox-fuzz-testing/
  17. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/main-may10.pdf
  18. https://lcamtuf.coredump.cx/afl/
  19. https://blog.llvm.org/2015/04/fuzz-all-clangs.html
  20. https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html
  21. https://github.com/google/oss-fuzz
  22. https://github.com/google/syzkaller
  23. https://www.usenix.org/system/files/woot20-paper-fioraldi.pdf
  24. https://blog.chromium.org/2012/04/fuzzing-for-security.html
  25. https://blog.hboeck.de/archives/868-How-Heartbleed-couldve-been-found.html
  26. https://security.googleblog.com/2024/11/leveling-up-fuzzing-finding-more.html
  27. https://aflplus.plus/docs/afl-fuzz_approach/
  28. https://www.ise.io/wp-content/uploads/2018/04/analysisfuzzing.pdf
  29. https://journals.tubitak.gov.tr/elektrik/vol33/iss2/2/
  30. https://www.fuzzingbook.org/html/Grammars.html
  31. https://www.cscjournals.org/manuscript/Journals/IJCSS/Volume13/Issue3/IJCSS-1481.pdf
  32. https://arxiv.org/abs/2008.01150
  33. http://www.inf.u-szeged.hu/~akiss/pub/fulltext/hodovan2018grammarinator.pdf
  34. https://digitalcommons.calpoly.edu/cgi/viewcontent.cgi?article=4088&context=theses
  35. https://ieeexplore.ieee.org/document/8626141
  36. https://lcamtuf.coredump.cx/afl/technical_details.txt
  37. https://www.ndss-symposium.org/wp-content/uploads/2017/09/driller-augmenting-fuzzing-through-selective-symbolic-execution.pdf
  38. https://arxiv.org/abs/1807.05620
  39. https://arxiv.org/pdf/2511.03995
  40. https://google.github.io/clusterfuzz/reference/coverage-guided-vs-blackbox/
  41. https://security.googleblog.com/2022/09/fuzzing-beyond-memory-corruption.html
  42. https://www.code-intelligence.com/blog/what-bugs-can-you-find-with-fuzzing
  43. https://www.appsecengineer.com/blog/the-role-of-fuzz-testing-in-software-security-part-1
  44. https://www.usenix.org/system/files/sec21-wu-qiushi.pdf
  45. https://www.usenix.org/system/files/sec19fall_jung_prepub.pdf
  46. http://www.umiacs.umd.edu/~tdumitra/courses/ENEE657/Fall19/papers/Klees18.pdf
  47. https://www.usenix.org/system/files/atc20-jeon.pdf
  48. https://www.code-intelligence.com/what-is-fuzz-testing
  49. https://srg.doc.ic.ac.uk/files/papers/pazzer-fuzzing-24.pdf
  50. https://www.usenix.org/system/files/usenixsecurity25-bao-andrew.pdf
  51. https://dl.acm.org/doi/10.1145/3597503.3623321
  52. https://cs.uwaterloo.ca/~m285xu/assets/publication/fuzz_slice-paper.pdf
  53. https://i.blackhat.com/eu-19/Wednesday/eu-19-Arya-ClusterFuzz-Fuzzing-At-Google-Scale.pdf
  54. https://github.com/google/clusterfuzz
  55. https://futures.cs.utah.edu/papers/25ICSE-a.pdf
  56. https://www.usenix.org/system/files/conference/usenixsecurity15/sec15-paper-de-ruiter.pdf
  57. https://cybersecurity.springeropen.com/articles/10.1186/s42400-022-00123-y
  58. https://aflplus.plus/
  59. https://www.usenix.org/system/files/woot20paper-fioraldi.pdf
  60. https://llvm.org/docs/LibFuzzer.html
  61. https://github.com/google/honggfuzz
  62. https://peachtech.gitlab.io/peach-fuzzer-community/
  63. https://about.gitlab.com/blog/gitlab-open-sources-protocol-fuzz-test-engine/
  64. https://www.cs.purdue.edu/homes/xyzhang/fall07/Papers/delta-debugging.pdf
  65. https://dl.acm.org/doi/10.1145/3460120.3485364
  66. https://www.usenix.org/system/files/conference/atc12/atc12-final39.pdf
  67. https://arxiv.org/abs/1905.13055
  68. https://mboehme.github.io/paper/IEEESoftware20.pdf
  69. https://www.researchgate.net/publication/356980212_Survey_of_Software_Fuzzing_Techniques
  70. https://www.techscience.com/cmc/v78n1/55370/html
  71. https://www.sciencedirect.com/science/article/abs/pii/S0167404822002073
  72. https://ieeexplore.ieee.org/document/8115618
  73. https://www.sciencedirect.com/science/article/abs/pii/S0952197625000946
  74. https://www.scitepress.org/Papers/2024/127619/127619.pdf
  75. https://www.ndss-symposium.org/ndss-paper/reinforcement-learning-based-hierarchical-seed-scheduling-for-greybox-fuzzing/
  76. https://ieeexplore.ieee.org/document/9734757
  77. https://blog.quarkslab.com/finding-bugs-in-implementations-of-hqc-the-fifth-post-quantum-standard.html
  78. https://dl.acm.org/doi/10.1145/3714463
  79. https://users.cs.northwestern.edu/~ychen/Papers/SWFuzz_ASIA.pdf
  80. https://www.scitepress.org/Papers/2025/135216/135216.pdf
  81. https://www.usenix.org/conference/usenixsecurity23/presentation/chen-chen
  82. https://oaklandsok.github.io/papers/schloegel2024.pdf
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.