Table of contents
18
By Salman Khan, OSCP+, Founder of XHack, SRT (Synack Red Team member)
Read this in 30 seconds: AI fuzzing means using a language model to do the human parts around a fuzzer, such as drafting the harness, suggesting seeds, fixing the build and sorting the crashes, while the fuzzer itself still does the finding. I read Google’s OSS-Fuzz results, an ISSTA 2024 study and DARPA’s AIxCC results on 10 November 2026, and built a small fuzz-and-triage demo on a toy parser I wrote. This guide covers software you own or projects whose rules allow fuzzing.
- The best public result is a coverage and bug-count result, not a magic one. In November 2024, Google reported that LLM-written fuzz targets extended coverage to 272 C and C++ projects on OSS-Fuzz (up from 160), added 370,000 lines of covered code and found 26 new vulnerabilities, including CVE-2024-9143 in OpenSSL.
- AI fuzzing harnesses match human ones on outcomes but struggle with complex APIs. An ISSTA 2024 study of 736,430 generated drivers across 86 questions from 30 C projects, costing over $8,000 in tokens, found on-par fuzzing outcomes, difficulty with intricate APIs, and better results from repeated queries, examples and iterative prompting.
- AI fuzzing and autonomous systems find and patch in a controlled setting. In DARPA’s AI Cyber Challenge final (August 2025), systems found 54 of 63 synthetic vulnerabilities, patched 43, found 18 real ones, and patched in 45 minutes on average.
- Most crashes are not vulnerabilities. In my toy AI fuzzing demo, 4 crash signatures came out of 20,000 executions, and 3 were ordinary input-validation errors that a good harness should treat as expected, so triage and the harness’s definition of a bug decide the value.
- XHack covers the reasoning around the fuzzer. Its agent orchestrates real tools and reads their output, from $20 a month with a 7-day trial, and a fuzzer such as AFL++ stays the engine.
If you searched for AI fuzzing, you want to know whether a language model can find bugs a conventional fuzzer misses. The evidence says it can help, mostly by getting more code under test, and that the hard parts of fuzzing are still deciding what counts as a bug and reading the crashes.
This AI fuzzing guide explains where AI fits in the fuzzing workflow, what the three strongest sources show and don’t show, and gives a runnable demo of the workflow on a toy target. I did not run a paid agent on real software, so the research figures are the sources’ own and the demo result is from my own toy code.
AI fuzzing is a language model helping with the setup, the build and the triage of a fuzzing campaign, while a coverage-guided fuzzer such as AFL++ or libFuzzer generates and runs the inputs. The model does not replace the fuzzer, because the fuzzer’s speed and coverage feedback are what find bugs.
A fuzzing campaign has six steps, and the model helps most with the human-shaped ones.
| Step | What happens | Where AI helps |
|---|---|---|
| Choose a target | Pick a parser, protocol handler or API worth testing | Suggest candidates by reading code |
| Write a harness | A small function that feeds fuzzer input to the target | Draft it, and fix compile errors |
| Seed the corpus | Provide valid example inputs and dictionaries | Propose seeds and keywords from the format |
| Run the fuzzer | Execute millions of mutated inputs with sanitizers | Little, the fuzzer does this |
| Triage crashes | Group, minimise and classify what crashed | Summarise stacks and suggest root causes |
| Fix and regress | Patch the bug and add a regression test | Draft the patch and the test |
For AI fuzzing, fuzz software you own, or projects that invite it, and keep it off other people’s live services. Fuzzing is aggressive by design, because it feeds malformed input at high speed and can crash processes, fill disks and corrupt data.
Our AI bug bounty policy guide covers what programs say about AI-assisted work and automation.
The fuzzers behind AI fuzzing are mature open-source projects, and the AI layer sits on top of them. I read each project’s GitHub page on 10 November 2026.
| Tool | Job | Licence | Latest release read |
|---|---|---|---|
| AFL++ | Coverage-guided fuzzer for compiled programs | AGPL-3.0 | v5.03c, 2 September 2026 |
| OSS-Fuzz | Google’s continuous fuzzing service for open-source projects | Apache-2.0 | Continuous, no tagged release |
| OSS-Fuzz-Gen | Google’s framework for LLM-generated fuzz targets | Apache-2.0 | Continuous, no tagged release |
| Atheris | Coverage-guided fuzzing for Python | Apache-2.0 | No tagged release |
| cargo-fuzz | Fuzzing for Rust projects | Apache-2.0 | 0.13.2, 9 June 2026 |
Pick by language. Our AI reverse engineering guide covers the binary side of AI fuzzing when you do not have source.
In AI fuzzing, an LLM helps where the work is reading code and writing glue, and it does not help where the work is raw throughput or deciding what a bug is.
Three sources carry most of the weight in AI fuzzing, and each answers a different question.
| Source | What it did | Reported result |
|---|---|---|
| Google Security Blog, 20 Nov 2024 | Used LLMs to generate fuzz targets for projects on OSS-Fuzz, with project-specific context in the prompts | Coverage in 272 C and C++ projects (up from 160), 370,000+ new lines covered, 26 new vulnerabilities, including CVE-2024-9143 in OpenSSL, likely present for about two decades |
| ISSTA 2024 study, arXiv 2307.12469 | Tested six prompting strategies on five LLMs over 86 driver questions from 30 C projects | 736,430 drivers evaluated; outcomes on par with industry drivers; difficulty with APIs with intricate specifics; repeat queries, examples and iterative prompting helped |
| DARPA AIxCC results, Aug 2025 | Autonomous systems found and patched flaws across 54 million lines of code | 54 of 63 synthetic vulnerabilities found and 43 patched, 18 real vulnerabilities found, 11 real patches, 45 minutes average patch time |
Read them with care. Google’s result is a vendor’s own report on its own service, and the post itself notes that line coverage is not a guarantee that a function is free of bugs. The ISSTA authors say LLM drivers still face obstacles for practical use, and that the work fed back into OSS-Fuzz-Gen. AIxCC used synthetic planted vulnerabilities in a controlled competition, so its 86 percent found and 68 percent patched figures show capability, not what you will get on your codebase.
The common thread is that AI fuzzing works best when it gets the model project-specific context, such as headers, types and existing tests, and when it is wrapped in a loop that compiles and runs the output.
The shape of AI fuzzing is easy to see on a toy target, so I wrote one. This script includes a small parser with two deliberate bugs, a harness, a basic mutation fuzzer and a crash-triage step that groups crashes by signature and shrinks each to a minimal input. It uses only the Python standard library, runs in-process and touches nothing else. It is not a replacement for AFL++, and the harness function is the part an LLM can draft.
"""A tiny mutation fuzzer plus crash triage, to show the workflow on a toy parser we wrote ourselves.
Real work belongs in AFL++, libFuzzer or similar. This script is stdlib-only, runs in-process,
touches no network and no other software. Usage: python3 mini_fuzz.py [seed] [iterations]
"""
import json, random, sys, traceback
# ---- the target: a toy "KEY=VALUE;" parser with two deliberate bugs ----
def parse(data: bytes):
out = {}
for item in data.split(b";"):
if not item:
continue
key, _, value = item.partition(b"=")
if key == b"len": # bug 1: trusts a length field
n = int(value)
out["buf"] = [0] * 8
out["buf"][n] = 1 # IndexError when n >= 8
elif key == b"ver": # bug 2: unhandled non-numeric version
out["ver"] = 100 // int(value) # ValueError, or ZeroDivisionError for 0
else:
out[key.decode("utf8")] = value.decode("utf8") # UnicodeDecodeError on bad bytes
return out
# ---- the harness: the part an LLM can draft and you review ----
def fuzz_one(data: bytes):
parse(data)
SEEDS = [b"name=abc;ver=3", b"len=2;name=x", b"a=b;c=d"]
def mutate(rng, data: bytes) -> bytes:
b = bytearray(data)
for _ in range(rng.randint(1, 3)):
op = rng.choice(("flip", "insert", "delete", "splice"))
if op == "flip" and b:
b[rng.randrange(len(b))] ^= 1 << rng.randrange(8)
elif op == "insert":
b.insert(rng.randrange(len(b) + 1), rng.choice(b"0123456789=;\xff\x00"))
elif op == "delete" and len(b) > 1:
del b[rng.randrange(len(b))]
elif op == "splice":
b += rng.choice(SEEDS)
return bytes(b[:64])
def signature(exc) -> str:
frames = traceback.extract_tb(exc.__traceback__)
return f"{type(exc).__name__} @ " + " > ".join(f"{f.name}:{f.lineno}" for f in frames[-2:])
def shrink(data: bytes, sig: str) -> bytes:
changed = True
while changed and len(data) > 1:
changed = False
for i in range(len(data)):
cand = data[:i] + data[i + 1:]
try:
fuzz_one(cand)
except Exception as e:
if signature(e) == sig:
data, changed = cand, True
break
return data
def main(seed=1, iterations=20000):
rng, corpus, crashes = random.Random(seed), list(SEEDS), {}
for _ in range(iterations):
data = mutate(rng, rng.choice(corpus))
try:
fuzz_one(data)
except Exception as e:
s = signature(e)
entry = crashes.setdefault(s, {"count": 0, "smallest": data})
entry["count"] += 1
if len(data) < len(entry["smallest"]):
entry["smallest"] = data
report = [{"signature": s, "count": v["count"], "minimised_input": shrink(v["smallest"], s).decode("latin1")}
for s, v in sorted(crashes.items(), key=lambda kv: -kv[1]["count"])]
print(json.dumps({"seed": seed, "executions": iterations, "unique_crashes": len(report), "crashes": report}, indent=2))
if __name__ == "__main__":
main(*(int(a) for a in sys.argv[1:3]))With seed 1 and 20,000 executions it reported 4 unique crash signatures, and running it twice gave identical output. Three were ValueError or UnicodeDecodeError raised on malformed input, such as an empty version value or an invalid byte. The fourth was an IndexError that the minimiser reduced to len=22, which is the real bug: the parser trusts a length field.
That result is the lesson. A naive harness counts every exception as a crash, so the 3 expected rejections hide the 1 real bug. A better harness catches the exceptions the parser is meant to raise and treats only the rest as findings, and deciding which is which is the oracle problem. An LLM can propose which exceptions look intentional, and you confirm it from the specification.
For a library you own, ask the model for the glue and not the verdict:
Here are the public headers and two existing unit tests for this library.
Write a libFuzzer-style harness that feeds fuzzer bytes into <function>.
List the exceptions or error codes the library documents as normal input rejection,
and say how to ignore them. Do not claim any bug exists. Mark anything you are unsure about.For triage, give it the sanitizer output and ask it to group and explain, then verify the root cause in the code yourself.
AI fuzzing has real limits, and most of them are about judgement and cost.
So yeah, here is where we talk about our own product. I am biased, it is my company, and I think XHack is the strongest all-in-one option for the reasoning around AI fuzzing, with a clear boundary: a fuzzer such as AFL++ stays the engine.
XHack’s agent works on the parts that need judgement. According to its unrestricted AI agent page, it orchestrates real tools against live targets, reads their output and adapts its strategy, and our guide to it lists vulnerability research assistance alongside exploit development and reverse engineering. Pointed at your own code in a sandbox, that is the harness-reading and crash-triage work in the middle of the workflow above.
XHack combines three things most providers sell separately: an autonomous AI agent, a continuous security platform and human testers.
Individual plans are $20, $49 and $150 a month, with a 7-day free trial, one per person. See the pricing page and the agent for bug bounty guide. Run it on code you own and judge it by what it finds, because brutal honesty is kind of our thing.
AI fuzzing is the use of a language model to help with a fuzzing campaign, usually by drafting fuzz harnesses, suggesting seed inputs, fixing build errors and triaging crashes. A coverage-guided fuzzer such as AFL++ or libFuzzer still generates and runs the inputs, so AI fuzzing is an assistant to the fuzzer and not a replacement for it.
AI fuzzing can help get more code under test, which is how Google reported 26 new vulnerabilities from LLM-generated targets in projects that already had hundreds of thousands of hours of fuzzing, including CVE-2024-9143 in OpenSSL. The bugs were found by fuzzing, with the AI writing the targets that reached the code.
Reasonably, with limits. An ISSTA 2024 study of 736,430 generated drivers found outcomes on par with industry drivers, but difficulty with APIs with intricate specifics. Repeat queries, examples and iterative prompting helped, and every AI fuzzing harness should be reviewed before you trust it.
Fuzzing software you own or have permission to test is normal practice, and this is not legal advice. Fuzzing someone else’s live service without written permission can break the law and their terms, and it can crash the service, so use a local build or a project that publishes fuzzing rules.
Yes, or an equivalent fuzzer. An LLM cannot run billions of mutated inputs with coverage feedback and sanitizers, and that is where the bugs are found. Use the model for the harness and the triage, and the fuzzer for the throughput.
The fuzzer is free and open source, and the cost is compute and model usage. The ISSTA study spent over $8,000 in tokens on a large comparison and 3.75 CPU-years of fuzzing, which shows the upper end, while a single-project AI fuzzing campaign is far cheaper. Measure your own token and compute use.
AI fuzzing helps with the setup and the triage, and the fuzzer still does the finding. Draft harnesses with a model, review them, define what counts as a bug, run a real fuzzer in a sandbox and triage the crashes by signature before you trust any of them.
Keep AI fuzzing to software you own or are allowed to test, and re-check the tools and results, because this field is moving quickly.
Categories
Related articles
