Fuzz Testing Explained (2026): The Numbers, the Mechanics, and the Ones to Distrust
A security review lands on your desk with one line: "add fuzzing before release." You search, and the explainers tell you fuzzing finds crashes, memory bugs and hidden vulnerabilities. They rarely say how often it works, on what kind of software, or whether it applies to the Android or iOS app your team ships. The published results are real, and they are narrower than those explainers suggest.
Fuzz testing, or fuzzing, is a technique that feeds a program large numbers of invalid, unexpected or random inputs and watches for crashes or other undesirable behavior. The largest published results come from continuous fuzzing of open-source projects, where a crash, memory error or undefined behavior is easy to detect mechanically. This report gives those figures with their populations and dates, explains the mechanics behind them, flags the benchmark numbers you should not rely on, and says what is and is not published for mobile apps.
Key fuzz testing statistics (2026)
OSS-Fuzz cumulative results: over 13,000 vulnerabilities and 50,000 bugs identified and fixed across about 1,000 open-source projects, from the programme's 2016 start to May 2025. Google counts the two categories separately and does not state that they are mutually exclusive, so do not add them. Evidence type: cumulative total published by the maintainers. OSS-Fuzz README
First-session detection: in a study of about 1.12 million fuzzing sessions across 878 OSS-Fuzz projects (project selection as of 7 January 2025), 36% of studied projects detected a fuzzing bug in their first session and 20% in the second. Evidence type: academic analysis of programme logs, preprint October 2025. arXiv:2510.16433
Later-session detection: in the same study, the detection rate falls below 5% by the 26th session and then stabilises around a median of 2.19%. arXiv:2510.16433
Issues per build: a February 2026 study of 61,444 fuzzing bugs and 999,248 builds from 559 OSS-Fuzz projects reports a median detection rate "generally low across all languages (around 0.02 issues per build)". Evidence type: academic analysis, MSR '26. arXiv:2602.05312
AI-generated fuzz targets, November 2024: across 272 C/C++ OSS-Fuzz projects, up from 160 in the earlier run, AI-assisted target generation added more than 370,000 lines of newly covered code. Population: C/C++ projects only. Evidence type: result measured and published by Google. Google Security Blog
False-positive filtering, 2026: on 1,500 benchmark functions from OSS-Fuzz, constraint-based generation plus context-aware crash validation filtered out more than half of the crashes initially classified as program errors. Evidence type: Google Research experimental result. Google Research
Android GUI fuzzing, 2023: property-based fuzzing of 20 real-world Android apps found 30 previously unknown bugs in 18 of them. Evidence type: peer-reviewed study, ESEC/FSE 2023. ESEC/FSE 2023
Evaluation quality, 2018: Klees et al. examined the experimental evaluations in 32 fuzzing papers and found problems in every evaluation they considered. Evidence type: peer-reviewed, ACM CCS 2018. arXiv:1808.09700
Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
What fuzzing is, and what a harness actually does
NIST defines fuzz testing as "a software testing technique that involves providing invalid, unexpected, or random test inputs to the software system under test," with the system then monitored "for crashes and other undesirable behavior." The definition dates from 1 March 2015, so read it as a stable definition, not a statement about current practice. NIST OWASP describes the technique as aimed at finding "bugs, vulnerabilities, or unexpected behavior by automatically providing a program with unexpected, malformed, or semi-malformed inputs," and attributes its origin to a 1989 effort at the University of Wisconsin–Madison led by Professor Barton Miller and students. OWASP
The definitions hide the machinery. A working setup, using the documentation for LLVM's libFuzzer as the reference, has four parts.
The fuzz target. The code that receives the generated input. In libFuzzer it is a function with a fixed signature,
LLVMFuzzerTestOneInput(const uint8_t *Data, size_t Size), that takes a byte array and calls the code you want to exercise. The target does not depend on libFuzzer, so other engines can drive it too.The corpus. The seed inputs the engine mutates. The documentation recommends seeding it "with a varied collection of valid and invalid inputs"; inputs that reach new code paths are added.
Mutation and feedback. libFuzzer calls itself an "in-process, coverage-guided, evolutionary fuzzing engine." It tracks which code each input reaches and mutates the corpus to maximise coverage.
The oracle. Most fuzzing does not check output values. It relies on a sanitizer or a crash. The documentation recommends pairing libFuzzer with AddressSanitizer or UndefinedBehaviorSanitizer, so a failure stops the run and writes the triggering input to disk. LLVM libFuzzer documentation
That is why fuzzing is strongest where a bug can be detected mechanically. A memory error is an unambiguous signal. A wrong total on a checkout screen is not, until someone writes the rule that says it is wrong.
The same documentation lists cases where in-process fuzzing does not apply: a target that validates inputs and asserts on invalid ones, significant global state that cannot be reset, and persistent threads. It also states that libFuzzer's original authors have stopped active work on it in favour of another engine, Centipede, though it remains supported for bug fixes. A 2026 tooling decision should not treat it as the actively developed frontier.
Three axes, not three boxes
Fuzzers are often sorted into categories, but the categories answer different questions. Feedback access: can the engine see which code an input reached (coverage-guided) or not (black-box)? Input production: are new inputs mutated from existing ones or generated from a grammar or model? Execution model: does the target run in the engine's process or a separate one? libFuzzer is in-process, coverage-guided and mutation-based at once. Ask all three questions about any tool you evaluate.
The three programmes that publish outcome numbers
OSS-Fuzz. The 13,000-vulnerability and 50,000-bug figure is the largest cumulative count in the public record. It is a total, not a rate. Google's November 2024 post reported over 11,000 vulnerabilities "in the 8 years of the project": the same metric at an earlier date, not a second finding. Google Security Blog The README lists supported languages as C/C++, Rust, Go, Python, Java/JVM, JavaScript and Lua, so describing OSS-Fuzz as C/C++-only is out of date.
ClusterFuzz and Chromium. Chromium's security documentation states that ClusterFuzz runs on more than 12,000 cores, performs hundreds of millions of test cases per day, and has found and fixed roughly two thousand security bugs in "Chromium and other third party software" since 2009. The page is undated, so these are project-reported figures with no measurement date, and the population includes third-party software. Chromium security bugs
Microsoft. Microsoft's C++ documentation states that its Security Development Lifecycle "requires fuzzing at every untrusted interface of every product." That is a policy statement from the vendor, not an outcome report, and the page carries no update date this report could confirm. Microsoft Learn
Google is the first party for its own figures, not an independent auditor of them, and most outcome numbers in this field come from Google-run programmes. The independent check comes from academic analyses of the same programme, covered next.
What the research adds: rates the programmes do not publish
Programme totals answer "how much has been found?" They do not answer "how often does fuzzing find something new?" Two academic studies answer the second question from the programme's own logs.
The 2025 session study analysed about 1.12 million sessions from 878 projects, selected from 1,288 OSS-Fuzz projects because they had at least 365 coverage measurements, and 49,470 issue reports from 808 projects. Its pattern: 36% of studied projects found a bug in the first session, 20% in the second, and the rate fell below 5% by the 26th session before settling near a median of 2.19%. If you are deciding whether to keep a fuzzing job running, that curve is more useful than any total. It suggests the easy bugs surface early and the long tail is thin. arXiv:2510.16433
The study also reports that OSS-Fuzz fuzzes for around ten minutes by default per day. That is the duration behind "continuous fuzzing" for that programme, not a general figure. Its authors add that OSS-Fuzz projects are core open-source projects with higher security requirements than average, so repeating the experiment on other projects might yield different results.
The 2026 cross-language study grouped 559 OSS-Fuzz projects by primary language. Its median of about 0.02 issues per build is low across every group, with Python lowest at 0.014. Rust projects showed the best bug reproducibility, a median near 98.8%, while unreproducible bugs were more frequent in Go. Languages with higher patch coverage, Go and Python, showed longer time to detection. arXiv:2602.05312
The 559 projects are the cohort left after the authors' exclusions, not all of OSS-Fuzz. Both studies and the README describe overlapping projects, so their counts are different analyses of one programme. Do not sum them.
The AI shift: 2024 results and the 2026 false-positive tax
In November 2024, Google reported that AI-assisted target generation added more than 370,000 lines of newly covered code across 272 C/C++ OSS-Fuzz projects, up from 160. The largest single project went from 77 to 5,434 covered lines. Google also reported 26 new vulnerabilities in projects that already had hundreds of thousands of hours of fuzzing, including CVE-2024-9143 in OpenSSL. These are November 2024 results for C/C++ projects, not evidence of a 2025 or 2026 change. Google Security Blog
The same post carries the most useful sentence about coverage: "line coverage is not a guarantee that a function is free of bugs," and code coverage "isn't able to measure all possible code paths and states." Coverage is the standard progress metric for coverage-guided fuzzers, and a weak target. Set it as a goal and you are measuring something other than bug-finding.
The 2026 result is the corrective. Google's OSS-Fuzz-Gen paper reports that automated fuzz-driver generation "in practice often produces false positive crashes, especially for complex functions." On 1,500 benchmark functions, constraint-based generation and context-aware crash validation filtered out more than half of the crashes initially classified as program errors, at modest additional cost. Google Research Generated targets can produce crashes that look like bugs and are not, so budget triage time before you count findings.
The benchmark numbers you should not trust
Fuzzers are routinely compared on how many bugs they find, and those charts are the weakest evidence in the field. Klees et al. surveyed the evaluations in 32 fuzzing papers and found problems in every one they considered. Their own extensive evaluation then showed that those problems can produce wrong or misleading assessments. arXiv:1808.09700
Google's FuzzBench announcement, from March 2020, describes the same family of weakness. Research evaluations "often have shortcomings": they "don't use a large and diverse set of real world benchmarks, use few trials, use short trials, or lack statistical tests to illustrate if findings are significant." Google Open Source Blog
Those four defects make a practical test for any comparison chart. Are the targets real and varied? How many trials ran? How long was each? Is a statistical test behind the difference? A chart that cannot answer all four does not support a tool choice. That is not a claim that every fuzzing chart is wrong. Thirty-two papers are not every comparison, and the FuzzBench post says "often", not "always". Both are dated statements about method, and still among the clearest on what a fair test needs.
Fuzzing on mobile: what is published, and what is not
Most programme numbers above come from libraries and browsers, where a byte buffer can be handed to a function and a sanitizer can judge the result. Mobile apps add inputs of other kinds: UI event sequences, stored data, inter-process messages and network payloads. Those need a different harness, and where the defect is a wrong value rather than a crash, no sanitizer flags it, so a person has to specify what correct looks like. Library and native code inside an app can still be fuzzed at function boundaries.
The best published Android evidence is PBFDroid, presented at ESEC/FSE 2023. It applied property-based GUI fuzzing to 20 real-world Android apps and found 30 previously unknown bugs in 18 of them. Of the 30, 29 were data manipulation errors: 22 non-crashing logic bugs and 7 crashes. The authors report that none of the 22 non-crashing errors could be found by state-of-the-art techniques. When the paper was written, 19 bugs had been confirmed and 9 fixed. ESEC/FSE 2023
Read it with its shape attached. It is one cohort of 20 apps, not a rate across all apps. Humans specified the properties according to each app's features, which is the labour cost the authors flag. The documented run instructions use an Android emulator. The replication repository holds APKs for 17 open-source apps while the abstract describes 20, so cite the abstract's 20 and do not treat the repository as the full study set. Replication package
The scoped gap is this: no comparable published assessment of equivalent fuzz targets across Android and iOS, and no published comparison of physical devices against emulators for fuzzing outcomes, appear in the sources cited here. That is narrower than "there is no mobile fuzzing data", which would be false. No first-party Quash measurement covers it either.
Settling it would take a design that fixes, in advance: which apps are included and why; the input surface and harness; the fuzzing engine; hardware or emulator conditions and how they are compared; run duration; the oracle that defines a bug; and how findings are deduplicated and triaged. None of those has a published answer for mobile apps, so none should be read into the figures above. If your concern is the wider security posture of a mobile app, start with Quash's guide to mobile app security testing; for the broader discipline fuzzing sits within, see what security testing covers.
Disclosure: Quash is our product. It is a mobile-first AI testing platform, not a fuzzer, and nothing in this report measures it.
If you are choosing a fuzzer
Start by identifying which kind of number you are being given. A cumulative total shows what a programme has accumulated over years. A rate shows how often a configuration finds something per unit of effort. A snapshot is a total at one date. They answer different questions, so do not compare or add them.
Then put any comparison chart through the four questions above: real and varied targets, number of trials, trial length, statistical test. If a vendor cannot answer them, treat the chart as marketing.
Ask about false positives before bug counts. The OSS-Fuzz-Gen result shows generated targets can produce many spurious crashes, so a tool that reports more crashes has not necessarily found more bugs. Ask how crashes are deduplicated and validated, and how long triage takes.
Finally, measure on your own code. Pick a representative input surface, run for a stated duration, count distinct defects and how many are real, and keep the setup fixed so the next tool is judged on the same terms. If your input surface is a function that takes bytes, the published programme numbers are a fair guide. If it is an app's UI and data flows, plan for human-written properties and a pilot of your own before you commit budget.
Methodology and source notes
This report prefers primary sources: the bodies that define the technique, the projects that publish their own results, peer-reviewed and preprint studies, and official vendor documentation. Each figure carries its metric, population, period and evidence type, and undated sources are labelled.
Limits of the evidence. The OSS-Fuzz, ClusterFuzz and Microsoft figures are published by the programmes themselves and are not independently audited. The ClusterFuzz page is undated and covers third-party software as well as Chromium. The Microsoft page's update date is unconfirmed. The 2025 and 2026 academic studies cover OSS-Fuzz projects only, and their authors caution against generalising. The mobile evidence is one peer-reviewed Android cohort whose replication package lists fewer apps than its abstract. The origin of fuzzing is given as OWASP's 1989 attribution; no single origin date is asserted. The NIST definition (2015), the Klees et al. study (2018) and the FuzzBench post (2020) are older than 24 months and are used as dated definitions and positions on method, not as current conditions.
This report includes no market-size, spending, adoption or commercial pricing figures for fuzzing tools, and it does not reconstruct any total from vendor figures. Search-volume metrics are not facts about the topic and are not used.
Continue reading
More articles from the Quash editorial desk.
