GitHub's fuzzing agent uses coverage gaps to revise its harnesses

Two builds turn a coverage gap into a task

On September 24, GitHub Security Lab's Antonio Morales published an open-source taskflow for fuzzing C and C++ projects. It feeds source-coverage gaps back to the model, which can revise the harness or inputs AFL++ will try next. The fuzzing taskflow runs on GitHub Security Lab's separate Taskflow Agent framework. The post describes the workflow and its code; it does not publish an independent benchmark of bugs found or coverage gained.¹²³

A fuzz target is a small program that passes generated inputs into selected library code. The taskflow asks an agent to inspect a repository, identify APIs, and propose such harnesses. It then builds each candidate twice: an AFL-instrumented binary for mutation, and a Clang source-coverage binary for replaying the generated corpus. AFL++ mutates inputs and keeps cases that reach new program states; the separate coverage replay records which source lines and branches those cases execute.¹⁴⁵

This distinction matters. AFL++ performs the input mutation. The model helps choose target APIs, construct harnesses, and react to coverage reports; MCP tools run the compiler, fuzzer, and related commands. The post describes three layers: a shell driver chains stages, taskflow YAML files give the agent stage-specific instructions, and MCP tools perform operations while SQLite holds shared state.¹²³

Uncovered branches change the next attempt

After an iteration, the taskflow replays the fuzzer's queue with the coverage build. A branch the corpus has not reached gives the agent a concrete target. Morales describes four possible responses: add a seed input, alter the harness to call another API, add useful constants to AFL's dictionary, or skip a cold path such as vendor code. The workflow then runs another fuzzing stage and compares coverage again.¹

The documented stage budgets double from 30 seconds through 960 seconds per target. The default stopping rule is two consecutive iterations that each add less than one percentage point of absolute line coverage. Those are design settings reported by the taskflow's author, not evidence that the settings are optimal across projects.¹

repository
  → inspect build and select API entry points
  → generate harness; compile AFL and coverage variants
  → AFL++ mutates corpus
  → replay queue; report uncovered source branches
  → revise seed, harness, or dictionary; repeat
  → minimize crash; replay with AddressSanitizer
  → group, classify, and prepare a report for human review

Coverage is a steering signal, not a security verdict. OSS-Fuzz documents source-based coverage by replaying a corpus against coverage-instrumented fuzz targets, a useful explanation of what the second build measures. AFL++ separately explains how instrumentation-guided mutation retains inputs that reach new state transitions. Neither coverage percentage proves the code secure or establishes that an unexecuted path contains a vulnerability.⁴⁵

Crashes still need a person to decide what they mean

The reported triage stage minimizes crashes with afl-tmin, replays them under AddressSanitizer, groups cases by a normalized top-of-stack hash, and checks known crashes. The model can then draft a report with reachability and exploitability assessments, a suggested patch, and a regression-test sketch. The author cautions that proposed fixes can be wrong and require review. A crash, a deduplicated group, and a vulnerability are different units; the implementation's labels include harness bugs, timeouts, out-of-memory failures, assertion failures, duplicates, and vulnerability candidates.¹²

GitHub Security Lab's September 28 account gives a separate sign that its agent framework has been used on real targets: Kevin Stubbings reported that Android audit taskflows had found and reported 24 app vulnerabilities. Those workflows gather Android entry points such as exported components, deep links, URL schemes, and WebView bridges. The article says some proof-of-concept cases need a researcher or debugger to establish behavior, and it does not say that all 24 were independently confirmed, fixed, or publicly disclosed. This count is evidence about the Android audit work, not the C/C++ fuzzing pipeline above.⁶⁷

The public AI-agent disclosure index is useful for checking specific findings, but the index does not validate the 24-item total. A concrete claim about a particular Android vulnerability needs its own advisory and affected-version record; the count alone cannot supply either.⁸

The fuzzing script runs commands on the host

The fuzzing repository documents Python 3.11 or later, Linux or a Codespace with apt, Git, and GitHub CLI. Its quick start is ./scripts/fuzzing/run_fuzzing.sh tukaani-project/xz; the author suggests DaveGamble/cJSON for a small smoke test. The README says installation can add AFL++, Clang/LLVM, lcov, ctags, cscope, and Graphviz, and describes the repository as actively developed under the MIT license. These instructions make the entry point inspectable; this reporting did not execute the taskflow or reproduce its results.¹²

The fuzzing repository says its fuzzer, compilers, and model-selected build commands execute on the host without a container isolation layer. Its authors recommend a disposable Codespace or virtual machine, low privileges, and network access limited to build needs. The parent Taskflow Agent repository describes Docker as a deployment convenience; the fuzzing README still warns that commands execute without container isolation.²³

Independent Android-agent research gives useful context without testing this tool. MobileCybench reports evaluated agents on 495 reviewed probes across 13 Android apps and found results varied by access setting; its best tested agent in the malicious-app setting triggered probes in 53.8% of applications using only an obfuscated APK. That preprint's probe task, agents, and access assumptions differ from GitHub's taskflows, so its figures are neither a replication nor a comparison of the reported 24 findings.⁹

The released taskflow couples generated harnesses to AFL++ and uses source-coverage gaps to choose follow-up work. GitHub has published its implementation and reported separate Android findings, but the available sources give no comparative benchmark for the C/C++ taskflow's bug yield, false-positive rate, cost, or advantage over an established fuzzing setup. Security researchers still need to verify its generated harnesses and crash reports.