MultiFuzz: Retrieval-Grounded Protocol Fuzzing
- MultiFuzz is a dense retrieval-based multi-agent system that improves network protocol fuzzing by grounding decisions in RFC-derived semantic context.
- It decomposes fuzzing tasks across specialized agents for grammar extraction, seed enrichment, and plateau recovery, ensuring both syntactic and semantic correctness.
- Experimental results on RTSP demonstrate improved branch coverage, state transitions, and state exploration compared to AFLNet, ChatAFL, and NSFuzz.
MultiFuzz denotes, in the exact arXiv sense, a dense retrieval-based multi-agent system for network protocol fuzzing introduced in the paper "MultiFuzz: A Dense Retrieval-based Multi-Agent System for Network Protocol Fuzzing" (Maklad et al., 19 Aug 2025). It is designed to improve protocol fuzzing by grounding LLM-driven decisions in retrieved RFC-derived semantic context, decomposing fuzzing into specialized agent roles, and using structured tool-assisted reasoning to guide grammar extraction, seed enrichment, and coverage-plateau recovery. The name also sits within a broader cluster of similarly named fuzzing systems—most notably MTFuzz’s multi-task neural-network guidance for graybox fuzzing (She et al., 2020) and MULTIFUZZ in firmware-fuzzing comparisons (Shen et al., 16 May 2026)—but these are distinct lines of work.
1. Terminology and referential scope
The exact title MultiFuzz refers to the 2025 protocol-fuzzing framework built on dense retrieval, RAG, and multi-agent orchestration (Maklad et al., 19 Aug 2025). The surrounding literature contains several near-homonymous systems whose shared prefix reflects different technical ideas rather than a single unified framework.
| Name | Scope | Distinguishing idea |
|---|---|---|
| MultiFuzz | Network protocol fuzzing | Dense retrieval-based multi-agent system |
| MTFuzz | Graybox program fuzzing | Multi-task neural network with compact embedding |
| MULTIFUZZ | Firmware fuzzing context | Multi-stream input model discussed via FIDO comparison |
| MTCFuzz | Cooperative OS/firmware fuzzing | Unified multi-target coverage feedback |
MTFuzz is explicitly described as the paper’s specific name and as a strong match for the query “MultiFuzz,” because it centers on fuzzing with a multi-task neural network (She et al., 2020). By contrast, MulCovFuzz is stated to have no direct relation to MultiFuzz beyond similarity in naming, its contribution being specifically a multi-component coverage-guided greybox fuzzer for 5G protocol testing (Wang et al., 25 Feb 2026). This suggests that “MultiFuzz” functions less as a single canonical research lineage than as a recurrent label for fuzzing systems that exploit multiple sources of guidance, whether tasks, agents, streams, targets, or coverage domains.
2. Problem formulation in the exact MultiFuzz system
The protocol-fuzzing MultiFuzz paper starts from the observation that AFL-based systems such as AFLNet and NSFuzz often have weak semantic understanding of protocol grammars and difficulty handling stateful protocols that require valid multi-message sessions and careful state transitions (Maklad et al., 19 Aug 2025). AFLNet improves over plain AFL by using response codes to infer state transitions, and NSFuzz further uses program variables associated with state changes, but both are still described as relying heavily on feedback-driven mutation rather than protocol semantics.
The immediate predecessor in this line is ChatAFL. ChatAFL introduces LLM guidance for protocol fuzzing and improves state exploration, but MultiFuzz identifies four limitations: unreliable outputs, LLM hallucinations, an implicit assumption that the LLM already knows the protocol specification, and limited ability to maintain consistent protocol-grounded reasoning across fuzzing subtasks (Maklad et al., 19 Aug 2025). MultiFuzz is therefore defined not merely as “LLM-guided fuzzing,” but as a retrieval-grounded architecture in which fuzzing decisions are conditioned on protocol documentation at inference time.
This design choice is important because the target setting is not stateless parsing. The evaluation target is RTSP implemented in the Live555 media streaming server, a stateful protocol environment in which deeper protocol states depend on syntactically valid messages, semantically coherent sequencing, and state-aware transitions (Maklad et al., 19 Aug 2025). The paper’s central claim is that wider and deeper protocol-state exploration requires the fuzzer to operate over protocol knowledge rather than over byte-level mutation alone.
3. Retrieval pipeline and multi-agent architecture
MultiFuzz is built on top of ChatAFL, which itself sits on AFLNet-style infrastructure, but it adds a RAG-based semantic knowledge layer and a set of specialized agent crews (Maklad et al., 19 Aug 2025). Its high-level pipeline is: RFC preprocessing, propositional transformation, agentic chunking, embedding and indexing in a vector DB, dense retrieval at inference time, and crew-based multi-agent fuzzing tasks.
The RFC preprocessing stage is formalized in several steps. RFCs are first segmented into paragraphs,
and a semantic classifier retains only protocol-relevant paragraphs:
The retained paragraphs are then transformed into atomic, context-independent propositions using gpt-4o-mini and a JSON schema:
For RTSP, this process produced 445 unique propositions. Those propositions are next grouped into semantically coherent chunks, each with a proposition list, summary, and title, using similarity-based assignment with a threshold :
The resulting chunk objects are embedded with OpenAI text-embedding-ada-002 and indexed in a Chroma-based vector database. At runtime, a Dense Retrieval Agent queries this vector database through a Custom RAG Tool for approximate nearest-neighbor search, thereby supplying protocol-grounded context to the fuzzing agents (Maklad et al., 19 Aug 2025). The paper frames this as a semantic grounding mechanism: retrieved RFC chunks replace reliance on the LLM’s parametric memory.
The agent system is organized into three specialized crews. The Grammar Extraction Crew contains a Grammar Extraction Agent and Grammar Formatting Agent. The Seed Enrichment Crew contains a Seeds Enricher Agent. The Coverage Plateau Surpassing Crew contains an Analysis Agent, Vulnerabilities Agent, and Coverage Surpassing Agent. All three crews share the same Dense Retrieval Agent and collaborate through chain-of-thought / ReAct-style reasoning, with tools for formatting, parsing, CVE retrieval, and packet structuring (Maklad et al., 19 Aug 2025). A common misconception is that MultiFuzz is simply a single LLM front-end for protocol mutation; the architecture is explicitly modular and role-specialized.
4. End-to-end fuzzing workflow
MultiFuzz uses retrieved RFC context to drive three core fuzzing functions: grammar extraction, seed enrichment, and coverage-plateau surpassing (Maklad et al., 19 Aug 2025).
In grammar extraction, dense retrieval first fetches relevant RTSP specification context. The Grammar Extraction Agent then produces JSON-formatted request templates containing protocol method names such as PLAY and DESCRIBE, headers with <<VALUE>> placeholders, and CRLF line terminators. The Grammar Formatting Agent converts this raw output into a numbered text form consumable by ChatAFL’s parser. The purpose is to improve syntactic correctness and reduce malformed grammars.
In seed enrichment, the Seeds Enricher Agent interprets the protocol FSM, uses retrieved context to identify where to insert missing client requests, inserts two desired client requests into the seed sequence, ensures server responses are excluded, and outputs enriched packets in a parser-friendly structure (Maklad et al., 19 Aug 2025). The paper characterizes the result as state-aware sequences, not merely valid packets. This is operationally significant because stateful protocol fuzzing depends on coherent multi-message sessions.
In coverage plateau surpassing, the Analysis Agent examines communication history together with retrieved context; the Vulnerabilities Agent can optionally retrieve relevant CVEs from NVD, especially Live555 vulnerabilities; and the Coverage Surpassing Agent generates a valid RTSP packet intended to trigger a new transition. The paper’s example is a PAUSE request intended to move the server from Playing to Ready state (Maklad et al., 19 Aug 2025). This phase is designed to escape stagnation after ordinary mutation ceases to discover new states or paths.
Constraint handling is split into syntactic constraints and semantic constraints. Syntactic constraints are preserved through grammar extraction, header formatting, CRLF termination, and packet parsing tools. Semantic constraints are preserved by grounding outputs in RFC propositions and by FSM-aware seed insertion (Maklad et al., 19 Aug 2025). This separation is central to the system’s rationale: the framework is intended to reduce both malformed traffic and hallucinated protocol behavior.
5. Experimental evaluation and reported outcomes
The evaluation is conducted on RTSP in the Live555 media streaming server, using ProFuzzBench, Dockerized benchmarking, Ubuntu 24.04.02 LTS, an Intel Core i5-11300H, and 16 GB RAM (Maklad et al., 19 Aug 2025). The paper reports 24-hour fuzzing sessions, repeated multiple times, with averages over runs. The baselines are NSFuzz, AFLNet, and ChatAFL. Reported metrics are branch coverage, number of states explored, number of state transitions, unique crashes, and total paths explored.
| Metric | MultiFuzz | Baseline comparison |
|---|---|---|
| Average branch coverage | 2940 | 2912.67 (ChatAFL), 2860 (AFLNet), 2807 (NSFuzz) |
| Average state transitions | 163.33 | 159.67, 84.0, 90.33 |
| Average states explored | 14.67 | 14.33, 10.0, 11.7 |
The paper reports +0.9% over ChatAFL, +2.8% over AFLNet, and +4.7% over NSFuzz in average branch coverage (Maklad et al., 19 Aug 2025). For state transitions, the reported improvements are +2.3% over ChatAFL, +94.4% over AFLNet, and +80.8% over NSFuzz. For states explored, the improvements are +2.4%, +46.7%, and +25.4%, respectively. The strongest empirical gains are therefore not in branch coverage alone but in the protocol-state metrics that reflect deeper FSM traversal.
The paper also states that MultiFuzz is more consistent, less variable than ChatAFL in coverage outcomes, more reliable due to retrieval grounding, and less prone to hallucinated protocol behavior (Maklad et al., 19 Aug 2025). These claims are qualitative, but they align with the architecture’s primary design premise: protocol-grounded retrieval is intended to stabilize LLM behavior across fuzzing subtasks. A plausible implication is that the paper treats reliability not as an auxiliary property but as a first-order fuzzing objective in stateful protocol domains.
The implementation uses Llama-family models via Groq Cloud, including llama3.3-70b-versatile, deepseek-r1-distill-llama-70b, llama3-70b-8192, llama-4-scout-17b-16e-instruct, and llama-3.1-8b-instant, with different models assigned to different agent tasks (Maklad et al., 19 Aug 2025). This model heterogeneity reinforces the system’s role-specialized design.
6. Relation to adjacent “multi-” fuzzing paradigms
Although the exact paper titled MultiFuzz is about retrieval-grounded protocol fuzzing, the broader literature contains several technically distinct “multi-” fuzzing paradigms.
MTFuzz is a multi-task neural-network-based graybox fuzzer that learns a compact input embedding from three related coverage tasks—edge coverage, approach-sensitive edge coverage, and context-sensitive edge coverage—and then uses gradient-based saliency to mutate the most influential input bytes (She et al., 2020). Its encoder compresses inputs into a 512-dimensional compact feature vector, its mutation process focuses on high-saliency bytes, and it reports 11 previously unseen bugs together with an average of 2× more edge coverage than five state-of-the-art fuzzers on 10 real-world programs. The connection to MultiFuzz is nominal and conceptual rather than architectural: both systems use multiple signals to guide fuzzing, but one is neural and coverage-predictive, whereas the other is retrieval-grounded and agentic.
In firmware fuzzing, FIDO explicitly compares against ad-hoc input delivery methods used in MULTIFUZZ and reports that FIDO increases median code coverage over those delivery methods by up to 54% (Shen et al., 16 May 2026). The FIDO paper characterizes MULTIFUZZ as addressing the multi-stream nature of firmware input, while FIDO addresses the separate problem of when and how much input to deliver. Here “MULTIFUZZ” refers to a firmware-input-stream model rather than to dense retrieval or protocol-document reasoning.
A third nearby paradigm is MTCFuzz, which performs multi-target coverage-based greybox fuzzing for cooperative OS/firmware systems by collecting and combining coverage from multiple cooperating components through QEMU-based tracing (Ichikawa, 26 Mar 2026). Its core notion of “multi” is coverage fusion across software boundaries, not multi-agent reasoning or RFC retrieval. Likewise, MulCovFuzz is a multi-component coverage-guided greybox fuzzer for 5G protocol testing, but it is explicitly stated to have no direct relation to MultiFuzz beyond name similarity (Wang et al., 25 Feb 2026).
Taken together, these works indicate that “MultiFuzz” has no stable generic technical meaning across the literature. This suggests a family of research motifs—multi-task learning, multi-stream input handling, multi-target coverage fusion, and multi-agent orchestration—rather than a single methodological template.
7. Limitations, assumptions, and prospective directions
The exact MultiFuzz paper implies several assumptions: the protocol must have available RFC documentation or equivalent specification text; that knowledge must be amenable to filtering, chunking, and embedding; the target must benefit from structured stateful reasoning; and the retrieval context must be sufficiently relevant to guide LLM output (Maklad et al., 19 Aug 2025). These assumptions are integral to the framework, not peripheral implementation details.
Its reported limitations are also concrete. Evaluation is only given for RTSP / Live555. The pipeline appears to require a fairly involved preprocessing and tooling setup. Performance depends on retrieval quality and model choice. Multi-agent orchestration introduces complexity and coordination overhead. The system is still built on top of ChatAFL/AFLNet infrastructure rather than replacing low-level fuzzing mechanics (Maklad et al., 19 Aug 2025). These points constrain how broadly the reported results can be generalized.
The paper suggests future work in tighter integration with reverse engineering tools, improved use of symbolic analyzers, integration with traffic parsers, fine-tuning agent behaviors using domain-specific interaction data, and extension beyond RTSP to other protocol domains (Maklad et al., 19 Aug 2025). In that sense, MultiFuzz is best understood as a retrieval-grounded protocol-fuzzing framework whose main claim is methodological: protocol fuzzing becomes more reliable and more state-aware when semantic context is externalized into retrieval and distributed across specialized agents, rather than being left to a single model’s internal prior.