Fuzzing has quietly become one of the most productive vulnerability discovery techniques in software security. Coverage-guided fuzzers in the AFL and libFuzzer lineage [1], run at scale through infrastructure like Google's OSS-Fuzz [2], have surfaced an enormous number of memory-safety and logic bugs in widely used open-source code. But the technique's bottlenecks are well known: someone has to write the harness, someone has to get the fuzzer past hard-to-reach program states, and someone has to triage the pile of crashes it produces. The most interesting research direction of the past few years is the application of large language models to each of those bottlenecks. This roundup surveys where that work stands and what it changes for offensive and defensive practitioners.
The Plateau of Coverage-Guided Fuzzing
Coverage-guided greybox fuzzing—mutate inputs, keep the ones that reach new code, repeat—is the workhorse of the field, embodied in AFL and its successor AFL++ [3], LLVM's libFuzzer, and honggfuzz. Paired with sanitizers like AddressSanitizer, it turns subtle memory corruption into loud, reproducible crashes. The limits are equally well documented. Campaigns plateau: after the easy coverage is found, progress stalls at validated inputs, checksums, and deeply stateful logic. Structure-aware approaches (grammar-based fuzzers, dictionaries, protocol-specific mutators) help but demand per-target engineering. And the biggest limitation is not algorithmic at all—it is that code without a fuzz harness never gets fuzzed. In large codebases, the set of fuzzed entry points is usually a small fraction of the attack surface, which makes harness creation, not mutation strategy, the binding constraint.
LLM-Generated Harnesses: Attacking the Real Bottleneck
This is where language models have had the clearest impact. Google has publicly experimented with using LLMs to automatically generate new fuzz targets for OSS-Fuzz projects [4]—the OSS-Fuzz-Gen line of work—by having models read a library's headers, documentation, and existing usage, then draft harnesses that exercise previously unfuzzed APIs. The workflow that makes this trustworthy is mechanical validation: generated harnesses must compile, must actually increase coverage relative to existing targets, and must be screened for false-positive crashes caused by the harness misusing the API rather than a genuine bug in the library. That last failure mode is the characteristic pitfall of the approach—a model that passes a null pointer where the API contract forbids it will produce impressive-looking crashes that waste triage time. Teams adopting the technique should treat generated harnesses as junior-engineer output: cheap to produce, valuable after review, dangerous to trust blindly.
Directed Fuzzing Grows Up
Not all fuzzing aims for breadth. Directed greybox fuzzing—the research line popularized by AFLGo [5]—biases the search toward specified code locations instead of maximizing global coverage. The practical applications are compelling: aim the fuzzer at the code changed in a recent patch to check whether a fix is complete, at a function flagged by static analysis, or at the site of a previously reported vulnerability to hunt for variants. Language models slot into this picture as input and guidance generators: proposing seed inputs likely to reach a target area, drafting dictionaries and grammar fragments for structured formats, and suggesting which code paths in a diff deserve attention. The combination is attractive for patch-oriented security work, where the question is not 'what bugs exist anywhere' but 'did this specific change introduce or incompletely fix a bug'—a question directed techniques answer far more efficiently than blind campaigns.
Triage: From Crash Pile to Actionable Bug
A productive fuzzing campaign produces more crashes than any team wants to read. The established automation layer—deduplication by stack hashing, test-case minimization with tools like afl-tmin, sanitizer reports as ground truth for the fault type—is now being extended with LLM-assisted analysis: summarizing the likely root cause from a stack trace and surrounding source, clustering crashes that share an underlying defect despite differing stacks, and drafting bug reports with suggested severity. The evidence so far supports a clear division of labor. Models are genuinely useful for summarization and clustering, where a wrong answer costs a little reviewer time. They are unreliable as oracles for exploitability, where confident-sounding but wrong assessments can misroute prioritization. The safe pattern is to let automation order the queue and draft the narrative, while a human validates any judgment that determines whether a bug ships to a fix pipeline or gets closed.
What This Means for AppSec Teams
For application security teams, three implications stand out. First, the cost of standing up fuzzing has dropped: continuous fuzzing in CI—the model behind OSS-Fuzz's CIFuzz and ClusterFuzzLite [6]—plus machine-assisted harness generation means parsers, decoders, and native-code components in your own stack can realistically be fuzzed without a dedicated fuzzing team. Second, the skill profile shifts: the scarce ability is no longer writing mutators but curating targets, reviewing generated harnesses, and validating machine triage—security judgment applied to machine output. Third, the same economics apply to attackers, who can point identical tooling at your dependencies; the window between a bug being findable and being found is shrinking, which raises the value of fast patch pipelines and of running the campaign against your own code before someone else does. Fuzzing has always rewarded whoever runs it first. AI assistance mostly turns up the speed.
Conclusion
The research direction is consistent: LLMs are not replacing coverage-guided fuzzing, they are removing its human bottlenecks—harness authorship, target selection, and first-pass triage. The mechanical core of the discipline, mutation plus coverage feedback plus sanitizers, remains the engine, and mechanical validation remains the antidote to model error at every step. Teams that combine the two—machine scale with human verification—get most of the benefit and few of the failure modes. If your codebase contains a parser that has never been fuzzed, that is the place to start, and there has never been a cheaper time to start it.
References
- [1]libFuzzer – a library for coverage-guided fuzz testing — LLVM Project
- [2]OSS-Fuzz: Continuous Fuzzing for Open Source Software — Google
- [3]AFL++ (AFLplusplus) — AFLplusplus Project
- [4]AI-Powered Fuzzing: Breaking the Bug Hunting Barrier — Google Security Blog
- [5]AFLGo: Directed Greybox Fuzzing — AFLGo Project (GitHub)
- [6]ClusterFuzzLite: Continuous fuzzing for CI/CD — Google