GitHub Security Lab presented an open-source workflow called Fuzzing Taskflow, designed to automate large parts of testing C/C++ projects using fuzzing and language-model agents. When directed at a GitHub repository, the workflow can analyze the build system, identify suitable entry points, create fuzzing harnesses, run AFL++, read coverage reports, improve the harnesses, and triage crashes while preparing a separate report for each potential issue.
The project is built on the GitHub Security Lab Taskflow Agent framework, which represents workflows as a set of paths executed by the agent from start to finish. The article’s author, Antonio Morales, notes that the goal is not to eliminate the researcher’s role, but to transfer repetitive, time-consuming tasks to the agent while keeping decision-making and execution in separate layers.
How Does the Workflow Work?
Usage begins from the project repository by running the command ./scripts/fuzzing/run_fuzzing.sh PROJECT, for example, inside a Codespace. The workflow installs the tools, clones the repository, analyzes important functions, then creates fuzzing targets and runs campaigns against them. Its architecture consists of a shell runner, YAML files describing the workflow stages and instructions directed to the model, and MCP tools that perform operations such as running AFL, compiling harnesses, reading coverage, and storing crashes.
The agent does not invoke AFL or clang directly; instead, it decides what should be tested and which coverage gap deserves follow-up, while MCP tools perform low-level operations. State is stored in an SQLite database named fuzz_context.db, allowing results to be passed between stages without relying on shared memory.
Coverage Improvement Loop
Each harness is built twice: an .afl version for guiding AFL using the appropriate instrumentation, and a .cov version for replaying the input list and measuring line and branch coverage. After each round, the agent reviews uncovered branches, then chooses an action such as adding a new seed, modifying the harness source to call another interface, enriching the AFL dictionary with values checked by the code, or ignoring a cold path that is not worth the cost.
The time budget doubles from 30 to 60, 120, 240, 480, and 960 seconds, or approximately 32 minutes per target at the stated maximum. The workflow stops when it detects diminishing returns: if two consecutive rounds achieve less than one percentage point of line coverage, according to the adjustable default value, it moves to another target.
Handling Inputs and Crashes
The workflow supports custom mechanisms for JSON, XML, regular-expression, PNG, and binary TLV formats with embedded lengths. It can also generate a dictionary from string and numeric constants found in C and H files. The dictionary is further enriched after each coverage step based on checks near uncovered lines. Each harness also maintains a persistent corpus directory and uses afl-cmin to reduce its size while retaining useful inputs between rounds and campaigns.
After the campaign ends, crashes are minimized using afl-tmin, rerun under AddressSanitizer, and deduplicated based on a top-of-stack fingerprint. The workflow also retests known crashes to verify the impact of fixes and classifies results into categories including: vulnerability, library hardening, harness error, out-of-memory, timeout, assertion failure, or duplicate.
Why Does This Matter?
The practical value here is that the workflow attempts to automate the loop that often limits the effectiveness of continuous fuzzing: writing harnesses, reading coverage, choosing the next gap, and triaging crashes. This could reduce the cost of beginning to test a project that has not previously undergone fuzzing, or help expand coverage for an existing project.
However, GitHub Security Lab imposes a fundamental restriction: the workflow runs afl-fuzz, clang, and build commands selected by the model directly on the host system, without an intermediate container. Therefore, an agent affected by prompt injection could execute whatever the user is able to execute. The project recommends running it inside a disposable environment, such as a Codespace or temporary virtual machine, and without elevated privileges.
Reports of vulnerabilities and proposed fixes are also not final results. The article emphasizes that the model’s analysis may be wrong and that the proposed patch is marked as requiring review. Accordingly, Fuzzing Taskflow represents a well-prepared starting point for the researcher, not a substitute for human verification of reachability, exploitability, and root cause.