Collaborative Fuzzing: Methods & Insights

• Collaborative fuzzing is a coordinated approach where multiple fuzzers share seeds, coverage data, and runtime state to improve bug detection.
• It employs diverse mechanisms such as centralized scheduling, adaptive resource allocation, and seed synchronization to optimize testing efficiency.
• Empirical studies show that adaptive coordination in collaborative fuzzing enhances coverage and reduces duplicated efforts, leading to more robust vulnerability discovery.

Searching arXiv for papers on collaborative fuzzing and closely related orchestration frameworks. Collaborative fuzzing is a class of fuzzing systems in which multiple fuzzing instances, fuzzers, or program-analysis engines actively cooperate by sharing seeds, coverage, and state, coordinating their efforts to maximize new coverage and bug discovery per unit resource. It is distinct from individual fuzzing, which relies on a single engine with fixed heuristics and assumptions; from portfolio or parallel modes that simply run multiple instances concurrently with limited coordination; and from swarm fuzzing, where collaboration is largely confined to differently parameterized instances of the same engine family. Across recent systems, the central premise is that no single fuzzer generalizes across all targets or across all phases of a campaign, so coordinated composition, synchronization, and scheduling can improve robustness, target reachability, or vulnerability detection under the same or constrained resource budgets (Shi et al., 14 Jul 2025, Chen et al., 2018, Fu et al., 2023).

1. Conceptual scope and problem formulation

Collaborative fuzzing is motivated by the observation that individual fuzzers embody strong assumptions about mutation scheduling, power scheduling, seed prioritization, coverage granularity, or solver use, and these assumptions perform unevenly across programs and across time. BandFuzz characterizes collaborative fuzzing as a unified framework that dynamically selects which fuzzer to run at any given time, based on online feedback, while EnFuzz frames it as making multiple fuzzers “actively cooperate” rather than merely co-exist in parallel. UltraFuzz extends the notion to distributed environments, where collaboration includes global seed prioritization, deduplication, and synchronization of fuzzing status and coverage (Shi et al., 14 Jul 2025, Chen et al., 2018, Zhou et al., 2020).

A recurring distinction in the literature is between collaboration and uncoordinated concurrency. Portfolio-style execution often assigns one core per fuzzer and attributes gains to added computational resources rather than to coordination. BandFuzz identifies this as a major challenge for prior collaborative frameworks such as EnFuzz, CollabFuzz, and Cupid, while autofz argues that static equal-split ensembles leave performance on the table because runtime effectiveness changes with the evolving workload (Shi et al., 14 Jul 2025, Fu et al., 2023). AFL-EDGE formulates the parallel case differently: collaboration is achieved by mutually-exclusive, similarly-weighted task distribution so that instances explore different parts of the program with minimal overlap, rather than repeatedly mutating the same seeds (Wang et al., 2021).

The concept has broadened beyond classical user-space greybox fuzzing. Sydr-Fuzz couples coverage-guided fuzzers with a dynamic symbolic executor in a continuous Security Development Lifecycle pipeline; SmartFuzz recasts collaborative fuzzing as a multi-agent reflective search over smart-contract transaction sequences; MTCFuzz uses unified coverage across cooperating components such as an operating system and firmware; and FunFuzz applies multi-island collaboration to LLM-generated compiler test programs (Vishnyakov et al., 2022, Chen et al., 15 Nov 2025, Ichikawa, 26 Mar 2026, Béjar et al., 4 May 2026). This suggests that “collaborative fuzzing” denotes a family of coordination mechanisms rather than a single architecture.

2. Collaboration mechanisms and system architectures

Most collaborative fuzzers revolve around a coordinator that mediates execution, synchronization, and shared state. In BandFuzz, the coordinator manages fuzzer processes, enforces round budgets, tracks status, maintains a global seed pool, and performs scheduling via a bandit model. Each integrated fuzzer runs in its own Docker container, seed files are synchronized through filesystem tracking, and failures such as long stalls can trigger restart. The workflow iterates over arm selection, seed-pool synchronization, bounded execution, reward computation, and model update (Shi et al., 14 Jul 2025).

EnFuzz uses a lighter orchestration model based on a monitor thread, a GlobalSeedPool, a GlobalCover map, and a crash store. Local fuzzers push interesting seeds asynchronously, while the monitor periodically dispatches globally useful seeds to every fuzzer’s local queue. UltraFuzz centralizes scheduling more aggressively: a main node manages a prioritized seed queue, request queue, task assignment, coverage broadcast through a global bitmap, and elastic conversion of worker roles between fuzzing and evaluation. AFL-EDGE likewise introduces an external distributor, but the collaborative object is not a shared pool; it is a set of per-instance allow-lists that constrain which seeds each AFL instance may mutate (Chen et al., 2018, Zhou et al., 2020, Wang et al., 2021).

A compact comparison of representative architectures is useful.

System	Core collaboration object	Coordination style
EnFuzz	GlobalSeedPool and GlobalCover	GALS seed synchronization
UltraFuzz	Centralized scheduler, DB, global bitmap	On-demand dispatch and elastic evaluation
BandFuzz	Global seed pool and bandit scheduler	Single-core adaptive fuzzer selection
AFL-EDGE	Per-instance allow-lists	Mutually-exclusive task distribution
autofz	Runtime trend measurements and resource plan	Preparation/focus phase scheduling

Hybrid systems expand the architecture beyond multiple fuzzers. Sydr-Fuzz adds a hybrid fuzzing orchestrator, Sydr as DSE, security predicate checkers, Casr-based crash triage, corpus minimization, and llvm-cov-based reporting. Its collaboration includes cross-pollination between libFuzzer or AFL++ workers and Sydr, plus analysis stages needed for continuous SDL outputs. The hybrid directed-fuzzing work based on Sydr-Fuzz and LibAFL-DiFuzz similarly places an orchestrator between a directed fuzzer and symbolic execution, but focuses the collaboration on target-relevant seed scheduling and objective post-processing (Vishnyakov et al., 2022, Parygina et al., 7 Jul 2025).

Domain-specific variants preserve the same structural idea but change the collaborating entities. SmartFuzz uses six expert LLM agents—TxSeqDrafter, TxSeqRefiner, FunChecker, ArgChecker, SNDChecker, and AMTChecker—coordinated by a Reactive Collaborative Chain. MTCFuzz treats the operating system and firmware as cooperative targets and instruments QEMU so that both sides contribute to a unified trace. FunFuzz isolates five evolutionary “islands,” each with its own prompt, population, and coverage frontier, and periodically migrates elite candidates between islands (Chen et al., 15 Nov 2025, Ichikawa, 26 Mar 2026, Béjar et al., 4 May 2026).

3. Feedback signals, scheduling, and resource allocation

The central algorithmic question in collaborative fuzzing is what signal should drive coordination. Classical systems emphasize coverage and crashes. EnFuzz synchronizes seeds that extend coverage or trigger crashes; UltraFuzz deduplicates through hash, path checksum, and coverage bitmap comparison; AFL-EDGE distributes tasks using edge coverage with hit-count bucketing; autofz computes recent fuzzer “trends” from AFL bitmap contributions accumulated during a preparation phase (Chen et al., 2018, Zhou et al., 2020, Wang et al., 2021, Fu et al., 2023).

BandFuzz refines this picture by defining reward as difficulty-weighted branch coverage. For each newly covered branch, it computes a coverage interval $c_b = t - t_p$, where $t_p$ is the first-discovery round of the predecessor block, aggregates these values over newly covered branches and seeds, normalizes the result to $r_t \in [0,1]$, discretizes it through Bernoulli sampling, and updates a Beta-Bernoulli Thompson Sampling posterior. The selection rule is

$$a_t = \arg\max_i \hat{\theta}_i,\qquad \hat{\theta}_i \sim \mathrm{Beta}(\alpha_i,\beta_i),$$

with periodic reset of all $\alpha_i$ and $\beta_i$ every $I_R$ minutes to address non-stationarity (Shi et al., 14 Jul 2025).

Resource allocation policies vary sharply. EnFuzz uses static core assignments and periodic synchronization. autofz uses a two-phase control loop: a preparation phase that fairly measures all fuzzers in short slices, and a focus phase that allocates CPU time proportionally to measured contributions or selects only the strongest fuzzer when the peak difference exceeds an adaptive threshold. UltraFuzz dispatches tasks on demand to whichever worker becomes free and elastically converts fuzzing workers into evaluation workers when the seed-triage backlog grows. AFL-EDGE instead reduces overlap by partitioning tasks so that different instances mutate different seeds while preserving the union of observed edges (Fu et al., 2023, Zhou et al., 2020, Wang et al., 2021).

Several systems incorporate fairness controls because raw coverage gains are confounded by different execution speeds. BandFuzz’s auto-cycle maintains

$$F.\mathrm{avg\_cycle\_time} = \lfloor F.\mathrm{total\_duration}/F.\mathrm{num\_selection}\rfloor,\qquad F.\mathrm{cycles} = T_I/F.\mathrm{avg\_cycle\_time},$$

so each selected fuzzer receives comparable wall-clock time per round. UltraFuzz separates scheduling from fuzzing and applies AFL-style energy assignment globally at dispatch time. autofz uses equal resource allocation during preparation specifically so that trend comparison is meaningful (Shi et al., 14 Jul 2025, Zhou et al., 2020, Fu et al., 2023).

Hybrid and domain-specific systems broaden the signal space. Sydr-Fuzz prioritizes seeds for symbolic execution using new function discovery, new coverage, libFuzzer feature increases, and a preference for newer and smaller seeds, then feeds solver-generated inputs back into the fuzzers. The directed hybrid approach uses a lexicographic score vector $$S(x) = (I_{\mathrm{ETS}}(x), I_{\mathrm{cov}}(x), f_{\mathrm{file}}(x))$$ so that target-related interestingness dominates coverage, which dominates file score. SmartFuzz uses feedback categories such as FunctionNotFound, ArgumentMismatch, NonPayableFunction, IncorrectTransactionValue, SenderError, and VulnerabilityFound(type) to drive sequence-level and local repairs. MTCFuzz defines multi-target feedback as the union

$$C_{\mathrm{multi}} = \left(\bigcup_{i=1}^{N_k} C(T_{\mathrm{kernel}}^i)\right)\cup \left(\bigcup_{j=1}^{N_o} C(T_{\mathrm{fw}}^j)\right),$$

so progress in firmware is preserved even when kernel coverage plateaus (Vishnyakov et al., 2022, Parygina et al., 7 Jul 2025, Chen et al., 15 Nov 2025, Ichikawa, 26 Mar 2026).

4. Major design families

A first family is ensemble or composition-based collaboration among multiple fuzzers. EnFuzz exemplifies the early form: select diverse base fuzzers along coverage granularity, input generation, and mutation or selection strategy, then synchronize interesting seeds. autofz and BandFuzz represent more adaptive successors. autofz dynamically composes and schedules fuzzers at runtime based on trend measurements, while BandFuzz uses Thompson Sampling and a fixed computational budget without requiring extra cores. A plausible implication is that the research trajectory has moved from “share seeds among diverse engines” toward “treat each engine as an arm whose utility changes over time” (Chen et al., 2018, Fu et al., 2023, Shi et al., 14 Jul 2025).

A second family is distributed and parallel resource-saving fuzzing. UltraFuzz addresses task conflicts, workload imbalance, and seed-evaluation bottlenecks through centralized dynamic scheduling, instant synchronization, and elastic allocation between fuzzing and evaluating workers. AFL-EDGE addresses similar concerns inside a homogeneous AFL deployment, but operationalizes collaboration as exclusivity rather than synchronization, assigning different coverage responsibility to different instances (Zhou et al., 2020, Wang et al., 2021).

A third family is hybrid collaboration between fuzzing and symbolic execution or DSE. Sydr-Fuzz integrates libFuzzer or AFL++ with Sydr, security predicates, coverage reporting, and Casr-based triage. The directed-fuzzing variant narrows this architecture to predefined target regions, using Enhanced Target Sequences and objective-seed minimization. In both cases, collaboration is a closed loop: the fuzzer supplies diverse concrete seeds, symbolic execution solves hard path constraints, and the newly solved inputs are reinjected into the fuzzer (Vishnyakov et al., 2022, Parygina et al., 7 Jul 2025).

A fourth family is multi-target or cross-component collaboration. MTCFuzz shows that the collaborators need not be fuzzers at all; they can be software components that are jointly exercised by one input. By treating kernel and firmware coverage as a single interestingness domain, it prevents discarding seeds that only advance firmware-side exploration. This directly targets interface-mediated systems such as Linux/OpenSBI and Linux/OP-TEE (Ichikawa, 26 Mar 2026).

A fifth family uses LLMs or multiple agents as the collaborating entities. SmartFuzz formalizes collaborative fuzzing as a Continuous Reflection Process over complete transaction sequences and a Reactive Collaborative Chain over dependent subtasks. FunFuzz uses isolated LLM-driven “islands,” each with distinct semantic instructions and local coverage accounting, plus periodic migration of elites every 3 hours. Although these systems operate in very different domains—smart contracts versus compiler fuzzing—they share the same principle: isolation preserves diversity, while controlled exchange prevents stagnation (Chen et al., 15 Nov 2025, Béjar et al., 4 May 2026).

5. Empirical performance and evaluation methodology

Evaluation in collaborative fuzzing is methodologically contentious because resource accounting and synchronization policy can dominate results. BandFuzz explicitly criticizes prior collaborative frameworks for requiring extra cores and therefore confounding coordination gains with added resources. Its own evaluation uses 24-hour campaigns, 10 repetitions, and counts BandFuzz as one fuzzer in comparisons. On 21 FuzzBench targets, it reports an average score of 95.26 versus AFL++ 94.46 and a median score of 98.31 versus AFL++ 97.41, with BandFuzz top on 18/21 targets. Against autofz-8 on 25 FTS programs, BandFuzz-8 improved average branch coverage by 16.0%; against full autofz with 11 fuzzers, BandFuzz-8 exceeded average branch coverage by 4.8% despite fewer engines (Shi et al., 14 Jul 2025).

Earlier ensemble results emphasized the benefit of seed synchronization over unsynchronized portfolios. EnFuzz reports that, in 24-hour experiments, its four-base-fuzzer ensemble discovered 26.8%, 117%, 38.8% and 39.5% more unique crashes than AFL, AFLFast, AFLGo and FairFuzz, while also executing 9.16%, 39.2%, 19.9% and 20.0% more paths and covering 5.96%, 12.0%, 21.4% and 11.1% more branches. The paper also reports that a control ensemble without synchronization performed far worse, indicating that cross-pollination rather than mere co-location drove the gains (Chen et al., 2018).

autofz shifts the emphasis from coverage growth to adaptive runtime composition. It reports outperforming the best-performing individual fuzzer in 11 out of 12 available benchmarks and beating the best collaborative fuzzing approaches in 19 out of 20 benchmarks. On average, it found 152% more bugs than individual fuzzers and 415% more bugs than collaborative fuzzing. AFL-EDGE, in the homogeneous-parallel setting, reports reducing redundant mutation by roughly 57–60% and improving edge coverage by 9.49% to 10.20%, depending on the number of instances (Fu et al., 2023, Wang et al., 2021).

Distributed and hybrid systems use different metrics because their design goals differ. UltraFuzz reports average branch-coverage speedups versus AFL-single from 0.99x at 8 resource units to 1.06x at 128 units, path-coverage speedups from 1.03x to 1.19x, and coordination overhead averaging 1.26% at 128 units. It also reports 24 total vulnerabilities, of which UltraFuzz found 20. Sydr-Fuzz emphasizes SDL outcomes as well as coverage, reporting 85 previously unknown defects in 22 open-source projects, with 13 found by security predicates; in FuzzBench-style evaluation it reached higher final coverage than libFuzzer on 9/14 applications and led AFL++ on 9/14 applications (Zhou et al., 2020, Vishnyakov et al., 2022).

Domain-specific studies adopt domain-specific success criteria. SmartFuzz reports detecting 150/154 true vulnerabilities on D1 within 30 minutes, outperforming Mythril, SmarTest, Smartian, ILF, and RLF, and achieving 105/108 true positives on D2 with only 3 false negatives. It further reports that disabling reflection caused a 90.3% drop, from 150 to 11 true positives. MTCFuzz compares multi-target against single-target mode under otherwise identical conditions and reports full coverage of all RISC-V OpenSBI Base Extension switch branches in 55/100 campaigns versus 34/100, with average coverage rate 6.24 versus 5.89. FunFuzz, in 24-hour compiler campaigns, reports that five islands achieve 329,905 GCC lines and 634,091 Clang lines on C, exceeding Fuzz4All in both cases, and finds more unique compiler-internal failures than the prior LLM-driven baselines (Chen et al., 15 Nov 2025, Ichikawa, 26 Mar 2026, Béjar et al., 4 May 2026).

6. Limitations, misconceptions, and open research directions

A persistent misconception is that collaborative fuzzing is synonymous with “more fuzzers on more cores.” Multiple papers argue against this equivalence. BandFuzz treats added computational resources as a central threat to validity for prior frameworks, while EnFuzz distinguishes collaboration from a portfolio that simply aggregates final results. AFL-EDGE shows that even identical fuzzers can collaborate if task ownership is made mutually exclusive, and autofz argues that equal static allocation can be suboptimal even when seed synchronization is present (Shi et al., 14 Jul 2025, Chen et al., 2018, Wang et al., 2021, Fu et al., 2023).

Another limitation concerns feedback impoverishment. Coverage remains the dominant signal, yet several papers note that coverage alone may not reflect bug-finding ability. BandFuzz therefore complements FuzzBench branch coverage with mutation analysis and reports the highest average mutation score of 98. SmartFuzz explicitly criticizes coverage-first smart-contract fuzzers for wasting effort on non-vulnerable regions. Sydr-Fuzz adds security predicates, verification, deduplication, clustering, and severity classification because raw crashes or coverage are not sufficient SDL outputs (Shi et al., 14 Jul 2025, Chen et al., 15 Nov 2025, Vishnyakov et al., 2022).

Collaboration also risks homogenization or overhead. FunFuzz reports that global coverage counters can help short runs but homogenize long campaigns, so its default is per-island coverage accounting with soft migration. EnFuzz warns about seed floods from generators. UltraFuzz notes that database and bitmap operations may become bottlenecks at large scale, even though per-round scheduling cost is small. MTCFuzz shows that unified cross-component tracing incurs substantial runtime overhead because fprintf in trace recording dominates execution time. These results suggest that the main engineering challenge is not whether to share information, but how selectively and at what cadence (Béjar et al., 4 May 2026, Chen et al., 2018, Zhou et al., 2020, Ichikawa, 26 Mar 2026).

Several open directions recur across the literature. BandFuzz proposes richer reward features such as basic-block centrality or sanitizer distance, alternative bandit variants such as continuous-reward Thompson Sampling or EXP3, and integration of hybrid or symbolic-assisted fuzzers. Sydr-Fuzz points to AArch64 support, improved debug-info parsing, and new security predicates. MTCFuzz identifies automated interface discovery and weighted multi-objective scheduling as open problems. SmartFuzz argues that the CRP and RCC abstractions are domain-agnostic, provided the environment can supply structured feedback. A plausible implication is that future collaborative fuzzers will increasingly combine selective synchronization, richer reward signals, and heterogeneous engines that include symbolic, domain-specific, and LLM-based components rather than relying solely on coverage-guided greybox variants (Shi et al., 14 Jul 2025, Vishnyakov et al., 2022, Ichikawa, 26 Mar 2026, Chen et al., 15 Nov 2025).