Pith. sign in

REVIEW 4 major objections 5 minor 3 cited by

Directed Greybox Fuzzing via Large Language Model

T0 review · 4 major / 5 minor · reviewed 2026-08-15 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read HGFuzzer turns directed fuzzing's two bottlenecks, path explosion and random mutation, into LLM code-generation tasks, and reports triggering 17 of 20 real-world vulnerabilities with a speedup of at least 24.8x.

desk verdict HGFuzzer is a real system with a plausible pipeline, but its headline speedup is not credible because the evaluation leaks target descriptions to the LLM and the authors admit training-data contamination. read the letter →

arxiv 2505.03425 v1 pith:CO4AFG6K submitted 2025-05-06 cs.CR

Hanxiang Xu , Yanjie Zhao , Haoyu Wang This is my paper · ORCID
classification cs.CR
keywords FuzzingDirectedGreyboxLargeLanguageModelVulnerabilityOpen-sourceLibraryTestHarnessReachableInputGenerationCustomMutator
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Directed greybox fuzzing tries to steer a fuzzer toward a specific target, such as a known vulnerable function, but wastes effort exploring irrelevant paths and mutating inputs blindly. This paper claims that a large language model can remove both inefficiencies: the LLM reads the call chain leading to the target, writes a small harness that fixes the path, generates a seed input that satisfies the path conditions, and writes a custom mutator aimed at the vulnerability's trigger conditions. The resulting system, HGFuzzer, triggered 17 of 20 known vulnerabilities in a benchmark of open-source C/C++ libraries, 11 of them within the first minute, and achieved at least a 24.8x speedup over three directed fuzzers. It also reported 9 previously unknown vulnerabilities in two libraries, each assigned a CVE ID. If the approach generalizes, it would make directed fuzzing dramatically cheaper for patch testing, crash reproduction, and vulnerability discovery.

What carries the argument

The load-bearing mechanism is the transformation of path-constraint solving into LLM-guided code generation along a chosen call chain. Given a target, HGFuzzer selects the shortest call chain that begins at main or at a declared external function, and asks the LLM to produce three artifacts: a harness that constrains execution to that chain, a Python script that generates a seed satisfying all branch conditions along the chain (verified with afl-cov), and a custom mutator written against the AFL++ custom-mutator API that biases inputs toward the vulnerability's trigger conditions. The harness removes irrelevant path exploration, the seed removes the need for random path discovery, and the mutator removes blind mutation; together they convert directed fuzzing from a search problem into a guided generation problem.

What would settle it

Run HGFuzzer on a target that postdates the LLM's knowledge cutoff, such as a vulnerability in a library release made after the model's training date or in a proprietary library never published online, and compare time-to-trigger with AFLGo; if the speedup vanishes, memorization rather than the framework carried the result.

Watch

Extended reading notes

Core claim

The central discovery is that the two bottlenecks of directed greybox fuzzing, path explosion during exploration and randomness during exploitation, can be recast as code-generation problems that an LLM can solve. Given a target function, HGFuzzer uses static analysis to extract the shortest call chain reaching it, then asks the LLM to infer the execution conditions at each call and to produce three artifacts: an executable harness that pins the path to that chain, a Python script that synthesizes a seed satisfying every condition, and a custom C/C++ mutator aimed at the vulnerability's root cause. On 20 real-world CVEs across nine open-source C/C++ libraries, HGFuzzer triggered 17 of them, versus 5 or 6 for the three directed-fuzzer baselines, with 11 triggered in the first minute and a minimum speedup of 24.8x. It additionally reported 9 previously unknown vulnerabilities, all assigned CVE IDs, and raised the target-function hit rate from the best baseline's 37.22% to 64.75%.

Load-bearing premise

The paper's own caveat in Section 5, that the benchmark libraries are likely in the LLM's training data, makes the results hinge on the assumption that the model's reasoning, not its memory of known CVEs, produces the speedups.

Editorial extensions

If this is right

  • HGFuzzer's preparation phase drops block-distance computation and symbolic execution: the paper reports static analysis as call-chain querying that completes in roughly 6-7 seconds per target in its benchmark.
  • Given only a target location, such as a recent CVE root cause or a reviewer-identified suspicious function, the same pipeline discovered 9 previously unknown vulnerabilities in two open-source libraries, all assigned CVE IDs.
  • The ablation study shows that removing the reachable-input generator or the custom mutator lowers success from 17/20 to 13-14/20 and stretches time-to-trigger from minutes to hours, so both components are necessary for the reported speedup.
  • Because every stage is prompt-driven, using a stronger LLM or adding a cross-check on inferred constraints should directly improve harness quality and reduce failures from misinterpreted branch conditions, as the paper notes in its discussion.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • A direct consequence of the paper's own training-data caveat is that the 24.8x speedup is likely an upper bound on what the pipeline would achieve on code outside the LLM's training distribution; the first decisive test is to run HGFuzzer on a library released after the model's knowledge cutoff.
  • Because HGFuzzer fixes on a single shortest call chain, vulnerabilities reachable through multiple calling contexts may be missed or fuzzed along a non-triggering path; enumerating several chains and running the pipeline per chain is a natural extension the paper leaves implicit.
  • The LLM-generated custom mutator is effectively a small, vulnerability-specific grammar; combining it with grammar-aware mutation or format-aware parsers could transfer the benefit to binary-heavy input formats without regenerating seeds each time.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 5 minor

Summary. The paper proposes HGFuzzer, a directed greybox fuzzing framework that uses LLMs to generate target-specific harnesses, reachable seed inputs, and custom mutators for C/C++ libraries. The pipeline consists of static call-chain analysis, LLM-based execution-condition inference, harness generation with RAG-based compilation repair, Python-script-based reachable input generation, and LLM-generated custom mutators integrated into AFL++. The evaluation compares HGFuzzer against AFLGo, Beacon, SelectFuzz, and AFL++ on 20 known CVEs from nine open-source libraries, reporting that HGFuzzer triggers 17 of 20 vulnerabilities, 11 within the first minute, with at least a 24.8x speedup over baselines. The paper also reports discovering nine previously unknown vulnerabilities with assigned CVE IDs. The central claim is that HGFuzzer substantially improves directed greybox fuzzing efficiency by using LLMs to reduce exploration and exploitation randomness.

Significance. If the empirical claims were well supported, HGFuzzer would be a meaningful contribution to directed greybox fuzzing and to the growing line of work on LLM-assisted fuzzing. The decomposition of the problem into harness generation, reachable-seed generation, and target-specific mutator generation is sensible, and the paper makes an effort to ablate these components. The fact that the reported new vulnerabilities received CVE IDs is concrete evidence of some practical bug-finding capability. However, the evaluation does not provide a level playing field between HGFuzzer and the baselines, and the paper explicitly acknowledges that the benchmark libraries are likely in the LLM's training data. As a result, the headline speedup and success-rate numbers are consistent with query-specific memorization and oracle-style vulnerability descriptions rather than with a generalizable method. The contribution is therefore not currently established at the level claimed.

major comments (4)
  1. [§3.3, §3.5, Table 1] The comparison with AFLGo, Beacon, and SelectFuzz is not apples-to-apples. Section 3.3 states that the harness prompt includes a 'Target Description' that 'may come from prior vulnerability reports (e.g., CVE records)', and Section 3.5's mutator prompt explicitly asks the LLM to 'analyze the root cause of the vulnerability' from this description. The DGF baselines receive only a target location and must infer the bug-triggering conditions by fuzzing. HGFuzzer thus receives information that directly encodes the vulnerability to be triggered. The 24.8x speedup and the 17/20 success rate in Table 1 are therefore explained by this information asymmetry, not by the framework's call-chain analysis, reachable-input generation, or custom mutators alone. A fair evaluation would either remove CVE descriptions and root-cause hints from all HGFuzzer prompts or give the baselines equivalent semantic information.
  2. [§5, 'Expanding Applicability'] Section 5 concedes that the benchmark open-source libraries 'are also likely included in the training data of the selected LLM.' This is a direct threat to the central claim: Claude-3.5-Sonnet may have memorized the vulnerable source code, the CVE records, and even public proof-of-concept inputs. Under that hypothesis, the generated harnesses, reachable seeds, and mutators are acts of retrieval or near-retrieval rather than evidence that the proposed pipeline solves the path-constraint and mutation-design problems. The paper does not include any experiment on a post-training-cutoff library, a closed-source target, or a sufficiently transformed benchmark to rule out memorization. The acknowledgment in Section 5 is framed as a limitation, but it undermines the generalizability of the headline results and requires new evidence before the central claim can be accepted.
  3. [§4.3, Table 3] The ablation study does not address the information-asymmetry problem. All three variations (Without Input, Without Mutator, and Harness-only) still receive the target description and the root-cause-oriented prompts defined in Sections 3.3 and 3.5. The ablation therefore shows only how the components contribute when the LLM is given oracle-style vulnerability knowledge; it does not show that the speedup over baselines survives when that knowledge is removed. To make RQ3 informative, the authors would need to ablate the target description itself, for example by replacing it with only the target function and call chain.
  4. [§4.4, Table 4] The claim that HGFuzzer 'discovered 9 previously unknown vulnerabilities' should be interpreted with the evaluation design in mind. The targets for these experiments were selected either from root-cause locations of recent CVEs in the CVE database or from locations identified by manual expert review. This is a plausible way to search for related bugs, but it is not an end-to-end discovery of vulnerabilities from code alone. The nine CVEs also come from only two libraries (libming and lcms2), and most are memory leaks, so the breadth of the finding is limited. The result is still useful evidence of practical bug-finding ability, but it does not support the stronger reading that HGFuzzer independently discovers new vulnerabilities.
minor comments (5)
  1. [Table 1] The legend contains the typo 'Imiediately Exploit'; it should be 'Immediately Exploit', and the abbreviation 'I.E.' should be written as something less confusable with the punctuation 'i.e.'.
  2. [Table 2] The row header 'A VG' appears to be an unintended spacing of 'AVG' or 'Average'; please correct it.
  3. [§5] The phrase 'all-chain analysis' in the discussion of hallucinations should be 'call-chain analysis'.
  4. [§3.3, Figure 5] The prompt template uses a placeholder {target_info} and the text says this information 'may come from prior vulnerability reports,' but the paper never states how many of the 20 benchmark CVEs had such a description available and whether the same description was provided to the baselines in any form. Clarifying this would help the reader evaluate the fairness of the comparison.
  5. [Formatting] The paper appears to use an unmodified ACM template placeholder ('Conference acronym ’XX', 2018 dates) and does not provide an artifact link; please update the camera-ready format and, ideally, release the code and benchmark scripts to support reproducibility.

Circularity Check

2 steps flagged · score 7.0 of 10

The known-CVE evaluation feeds the CVE description into HGFuzzer's prompts, so the reported speedup is an oracle-aided result rather than a fair comparison.

  1. self definitional [Section 3.3, Target Harness Generation (Figure 5 prompt template)]
    "The target description provides an overall summary of the fuzzing objective, which may come from prior vulnerability reports (e.g., CVE records) or expert knowledge indicating potential weaknesses in the target function. This description helps guide the LLM in generating a relevant and effective harness."

    For the 20 benchmark CVEs, the target description supplied to the LLM is the CVE record that the evaluation then counts as a successful trigger. The baselines receive only a target location and must discover the trigger conditions by fuzzing. The reported 17/20 triggering rate and 11-within-the-first-minute results are therefore not predictions from program structure; the answer (the vulnerability and its nature) is already present in the prompt, so the comparison measures oracle-aided generation rather than directed fuzzing.

  2. self definitional [Section 3.5, Target-Specific Mutator Generation]
    "The generation of the custom mutator is based on a carefully designed prompt, which incorporates the target description, the target function's source code, and the reachable input script. ... The LLM first analyzes the target function's source code and the provided description of the target, same as mentioned in Section 3.3. This analysis focuses on identifying the root cause of the vulnerability and the specific program states that must be reached to trigger it."

    The custom mutator is explicitly engineered from the root cause of the known CVE, so the mutations that lead to the crash are derived from the same vulnerability description that defines success in the evaluation. The TTE and 24.8x speedup claims therefore reduce, at least in part, to inserting the answer into the prompt. The RQ3 ablation cannot remove this leakage because every ablation variant still receives the target description.

full rationale

The paper does not rely on a self-citation chain or an imported uniqueness theorem; the static-analysis/code-generation pipeline is a genuine engineering contribution. The central circularity is in the evaluation design: HGFuzzer's prompts for known-CVE benchmarks include the CVE/target description (Sections 3.3 and 3.5), and the measured outcome is triggering exactly those CVEs. This is a self-definitional loop: the target-description input defines the vulnerability that is later reported as the successful prediction. The paper itself concedes in Section 5 that 'These libraries are also likely included in the training data of the selected LLM,' which compounds the leak even if the explicit description were removed. The RQ3 ablation does not control for this because all variants retain the target description. Consequently, the headline speedup over AFLGo, Beacon, and SelectFuzz is not demonstrated on a level playing field. Score 7 reflects significant, partially circular evaluation: the central empirical claim is heavily dependent on leaked target information, though the framework still requires independent work to produce compilable harnesses, verified reachable seeds, and working fuzz execution.

Assumptions & free parameters 1 free parameters · 4 assumptions · 0 invented entities

The framework's central mechanism is LLM inference, which is treated as an unverified oracle. The evaluation assumes the benchmark source code and CVEs are not memorized, an assumption the paper itself calls into question in Section 5. No new physical or mathematical entities are introduced.

free parameters (1)
  • Similarity threshold s and chunk count k in RAG retrieval (Algorithm 2)
    Hand-picked retrieval parameters in compilation error resolution; no sensitivity analysis is reported.
assumptions (4)
  • domain assumption The LLM correctly infers execution conditions and generates compilable, semantically valid harnesses and seed-producing scripts (Sections 3.2-3.4).
    No formal correctness guarantee is provided for LLM outputs; RAG repair and afl-cov verification mitigate but do not eliminate this assumption.
  • ad hoc to paper The benchmark libraries and CVE information used to construct target descriptions are not memorized by the LLM in a way that trivially solves the task (Section 5 discussion of training data).
    The evaluation design implicitly assumes the LLM does not rely on memorized answers; the paper itself questions this in the Discussion.
  • domain assumption The selected shortest call chain starting from main or an external library function is a feasible and representative path to the target (Algorithm 1).
    Algorithm 1 prioritizes shortest chains, but no feasibility check is applied before LLM analysis.
  • domain assumption Crashes observed under the generated harness correspond to real vulnerabilities in the library rather than harness artifacts.
    The paper validates with sanitizers and CVE assignment, but a harness can introduce false positives if it misuses APIs.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Directed Greybox Fuzzing via Large Language Model." pith.science (2026). https://pith.science/paper/CO4AFG6K

@misc{pith2026250503425,
  author       = {Pith},
  title        = {Pith review of: Directed Greybox Fuzzing via Large Language Model},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/CO4AFG6K}},
  note         = {Machine review of arXiv:2505.03425}
}
read the original abstract

Directed greybox fuzzing (DGF) focuses on efficiently reaching specific program locations or triggering particular behaviors, making it essential for tasks like vulnerability detection and crash reproduction. However, existing methods often suffer from path explosion and randomness in input mutation, leading to inefficiencies in exploring and exploiting target paths. In this paper, we propose HGFuzzer, an automatic framework that leverages the large language model (LLM) to address these challenges. HGFuzzer transforms path constraint problems into targeted code generation tasks, systematically generating test harnesses and reachable inputs to reduce unnecessary exploration paths significantly. Additionally, we implement custom mutators designed specifically for target functions, minimizing randomness and improving the precision of directed fuzzing. We evaluated HGFuzzer on 20 real-world vulnerabilities, successfully triggering 17, including 11 within the first minute, achieving a speedup of at least 24.8x compared to state-of-the-art directed fuzzers. Furthermore, HGFuzzer discovered 9 previously unknown vulnerabilities, all of which were assigned CVE IDs, demonstrating the effectiveness of our approach in identifying real-world vulnerabilities.

Figures

Figures reproduced from arXiv: 2505.03425 by the authors.

Figure 1
Figure 1. A motivating example from CVE-2017-2897, where [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. A motivating example from CVE-2020-13790. [PITH_FULL_IMAGE:figures/full_fig_p003_2.png] view at source ↗
Figure 3
Figure 3. Overview of HGFuzzer. chain 𝐶 ∈ 𝑆 with 𝐹𝑛 = main, HGFuzzer identifies the chain with the smallest length |𝐶| as the available call chain. If no such chain exists, HGFuzzer searches 𝑆 for the call chain with the smallest length |𝐶| whose starting function 𝐹𝑛 is declared as an external function in the library’s header files. If such a chain is found, it is identified as the available call chain. Algorithm 1 Call Chain… view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: An example of the response from the LLM in exe [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Prompt template for target harness generation. [PITH_FULL_IMAGE:figures/full_fig_p005_5.png]
Figure 6
Figure 6. Figure 6: Prompt template for reachable input generation. [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Vulnerable function in CVE-2020-13790. To ensure the generated custom mutator is functional and ef￾fective, our approach incorporates an iterative refinement process. If the generated custom mutator fails to compile or causes run￾time errors, the LLM automatically refe…
Figure 8
Figure 8. Figure 8: Examples of identified vulnerabilities. ing function of libming 0.4.8. The issue arises from insufficient error handling during dynamic memory allocation. The function al￾locates a buffer using malloc (line 344) and resizes it with realloc (line 352) when the buffer si…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 3 Pith papers

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Knowdit: Agentic Smart Contract Vulnerability Detection with Auditing Knowledge Summarization

    cs.CR 2026-03 conditional novelty 6.0 of 10

    Knowdit links abstract DeFi semantics to vulnerability patterns in a knowledge graph and drives an agentic specify–harness–fuzz–reflect loop that finds all high-severity and most medium-severity bugs on held-out Code4...

  2. PBFuzz: Agentic Directed Fuzzing for PoV Generation

    cs.CR 2025-12 conditional novelty 6.0 of 10

    An agentic fuzzing system lets LLM agents infer vulnerability constraints, encode them as parameter generators, and solve them with property-based testing; it triggered 57 Magma CVEs, 17 missed by other fuzzers.

  3. Locus: Agentic Predicate Synthesis for Directed Fuzzing

    cs.CR 2025-08 conditional novelty 6.0 of 10

    Locus uses an LLM agent to synthesize and validate intermediate predicates that make directed fuzzing reach target bug states faster, reporting an average 41.6x speedup across eight fuzzers.

Reference graph

Works this paper leans on

67 extracted references · 29 canonical work pages · cited by 3 Pith papers

  1. [1]

    2018. afl-cov. https://github.com/mrash/afl-cov

    work page 2018

  2. [2]

    2025. AFL++. https://github.com/AFLplusplus/AFLplusplus

    work page 2025

  3. [3]

    CodeQL documentation

    2025. CodeQL documentation. https://codeql.github.com/docs/

    work page 2025

  4. [4]

    CVE Database

    2025. CVE Database. https://cve.mitre.org/

    work page 2025

  5. [5]

    LlamaIndex Documents

    2025. LlamaIndex Documents. https://docs.llamaindex.ai/en/stable/

    work page 2025

  6. [6]

    OSS-Fuzz

    2025. OSS-Fuzz. https://github.com/google/oss-fuzz/tree/master/projects

    work page 2025

  7. [7]

    Tree-Sitter documentation

    2025. Tree-Sitter documentation. https://tree-sitter.github.io/tree-sitter/

    work page 2025

  8. [8]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren- cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023)

    arXiv 2023

Show all 67 references
  1. [9]

    Anthropic. 2024. Claude 3.5 Sonnet. https://www.anthropic.com/news/claude- 3-5-sonnet

    2024

  2. [10]

    Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoud- hury. 2017. Directed Greybox Fuzzing. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (Dallas, Texas, USA) (CCS ’17). Association for Computing Machinery, New York, NY,...

    2017

  3. [11]

    Chen Chen, Baojiang Cui, Jinxin Ma, Runpu Wu, Jianchao Guo, and Wenqian Liu. 2018. A systematic review of fuzzing techniques. Computers & Security 75 (2018), 118–137. doi:10.1016/j.cose.2018.02.002

    2018 doi

  4. [12]

    Hongxu Chen, Yinxing Xue, Yuekang Li, Bihuan Chen, Xiaofei Xie, Xiuheng Wu, and Yang Liu. 2018. Hawkeye: Towards a Desired Directed Grey-box Fuzzer. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (Toronto, Canada)(CCS ’18). Association...

    2018

  5. [13]

    Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large Language Models Are Zero-Shot Fuzzers: Fuzzing Deep- Learning Libraries via Large Language Models. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing an...

    2023

  6. [14]

    Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, and Lingming Zhang. 2023. Large language models are zero-shot fuzzers: Fuzzing deep-learning libraries via large language models. In Proceedings of the 32nd ACM SIGSOFT international symposium on software testing and...

    2023

  7. [15]

    Yinlin Deng, Chunqiu Steven Xia, Chenyuan Yang, Shizhuo Dylan Zhang, Shu- jing Yang, and Lingming Zhang. 2024. Large language models are edge-case generators: Crafting unusual programs for fuzzing deep learning libraries. InPro- ceedings of the 46th IEEE/ACM International Conf...

    2024

  8. [16]

    Zhengjie Du, Yuekang Li, Yang Liu, and Bing Mao. 2022. Windranger: A Directed Greybox Fuzzer driven by Deviation Basic Blocks. In 2022 IEEE/ACM 44th In- ternational Conference on Software Engineering (ICSE) . 2440–2451. doi:10.1145/ 3510003.3510197

    2022

  9. [17]

    Jueon Eom, Seyeon Jeong, and Taekyoung Kwon. 2024. Fuzzing JavaScript Inter- preters with Coverage-Guided Reinforcement Learning for LLM-Based Mutation. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (Vienna, Austria) (ISSTA 202...

    2024

  10. [18]

    James Finnie-Ansley, Paul Denny, Brett A Becker, Andrew Luxton-Reilly, and James Prather. 2022. The robots are coming: Exploring the implications of openai codex on introductory programming. In Proceedings of the 24th Australasian Computing Education Conference. 10–19

    2022

  11. [19]

    Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review. ACM Trans. Softw. Eng. Methodol. 33, 8, Article 220 (Dec. 2024), 79 pages. d...

    2024 doi

  12. [20]

    Jie Hu, Qian Zhang, and Heng Yin. 2023. Augmenting greybox fuzzing with generative ai. arXiv preprint arXiv:2306.06782 (2023)

    2023 arXiv

  13. [21]

    Heqing Huang, Yiyuan Guo, Qingkai Shi, Peisen Yao, Rongxin Wu, and Charles Zhang. 2022. BEACON: Directed Grey-Box Fuzzing with Provable Path Pruning. In 2022 IEEE Symposium on Security and Privacy (SP) . 36–50. doi:10.1109/SP46214. 2022.9833751

    2022

  14. [22]

    Heqing Huang, Peisen Yao, Hung-Chun Chiu, Yiyuan Guo, and Charles Zhang

  15. [24]

    Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, and Ting Liu. 2025. A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions. ACM Trans. Inf. S...

    2025 doi

  16. [25]

    Linghan Huang, Peizhou Zhao, Huaming Chen, and Lei Ma. 2024. Large Language Models Based Fuzzing Techniques: A Survey. arXiv:2402.00350 [cs.SE] https: //arxiv.org/abs/2402.00350

    2024 arXiv

  17. [26]

    Zhenlan Ji, Pingchuan Ma, Zongjie Li, and Shuai Wang. 2023. Benchmarking and Explaining Large Language Model-based Code Generation: A Causality-Centric Approach. arXiv:2310.06680 [cs.SE] https://arxiv.org/abs/2310.06680

    2023 arXiv

  18. [27]

    Yu Jiang, Jie Liang, Fuchen Ma, Yuanliang Chen, Chijin Zhou, Yuheng Shen, Zhiyong Wu, Jingzhou Fu, Mingzhe Wang, Shanshan Li, and Quan Zhang. 2024. When Fuzzing Meets LLMs: Challenges and Opportunities. In Companion Pro- ceedings of the 32nd ACM International Conference on the...

    2024

  19. [28]

    Zongze Jiang, Ming Wen, Jialun Cao, Xuanhua Shi, and Hai Jin. 2024. Towards Understanding the Effectiveness of Large Language Models on Directed Test Input Generation. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (Sacramento, C...

    2024 doi

  20. [29]

    George Klees, Andrew Ruef, Benji Cooper, Shiyi Wei, and Michael Hicks. 2018. Evaluating Fuzz Testing. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (Toronto, Canada) (CCS ’18). Association for Computing Machinery, New York, NY, USA, 2...

    2018 doi

  21. [30]

    Gwangmu Lee, Woochul Shim, and Byoungyoung Lee. 2021. Constraint-guided Directed Greybox Fuzzing. In 30th USENIX Security Symposium (USENIX Secu- rity 21). USENIX Association, 3559–3576. https://www.usenix.org/conference/ usenixsecurity21/presentation/lee-gwangmu

    2021

  22. [31]

    Tsz-On Li, Wenxi Zong, Yibo Wang, Haoye Tian, Ying Wang, Shing-Chi Che- ung, and Jeff Kramer. 2023. Nuances are the Key: Unlocking ChatGPT to Find Failure-Inducing Tests with Differential Prompting. In 2023 38th IEEE/ACM In- ternational Conference on Automated Software Enginee...

    2023

  23. [32]

    Yuwei Li, Shouling Ji, Chenyang Lyu, Yuan Chen, Jianhai Chen, Qinchen Gu, Chunming Wu, and Raheem Beyah. 2022. V-Fuzz: Vulnerability Prediction- Assisted Evolutionary Fuzzing for Binary Programs. IEEE Transactions on Cyber- netics 52, 5 (2022), 3745–3756. doi:10.1109/TCYB.2020.3013675

    2022

  24. [33]

    Hongliang Liang, Lin Jiang, Lu Ai, and Jinyi Wei. 2020. Sequence directed hybrid fuzzing. In 2020 IEEE 27th International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 127–137

    2020

  25. [34]

    Hongliang Liang, Xiaoxiao Pei, Xiaodong Jia, Wuwei Shen, and Jian Zhang. 2018. Fuzzing: State of the Art. IEEE Transactions on Reliability 67, 3 (2018), 1199–1218. doi:10.1109/TR.2018.2834476

    2018

  26. [35]

    Peihong Lin, Pengfei Wang, Xu Zhou, Wei Xie, Gen Zhang, and Kai Lu. 2024. DeepGo: Predictive Directed Greybox Fuzzing. In Proceedings of the Network and Distributed System Security Symposium

    2024

  27. [36]

    Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, and Lingming Zhang. 2023. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation. arXiv:2305.01210 [cs.SE] https://arxiv. org/abs/2305.01210

    2023 arXiv

  28. [37]

    Yuwei Liu, Yanhao Wang, Xiangkun Jia, Zheng Zhang, and Purui Su. 2024. AFGen: Whole-Function Fuzzing for Applications and Libraries. In 2024 IEEE Symposium on Security and Privacy (SP) . 1901–1919. doi:10.1109/SP54263.2024.00011

    2024

  29. [38]

    Zhe Liu, Chunyang Chen, Junjie Wang, Mengzhuo Chen, Boyu Wu, Xing Che, Dandan Wang, and Qing Wang. 2023. Testing the Limits: Unusual Text In- puts Generation for Mobile App Crash Detection with Large Language Model. arXiv:2310.15657 [cs.SE] https://arxiv.org/abs/2310.15657

    2023 arXiv

  30. [39]

    Changhua Luo, Wei Meng, and Penghui Li. 2023. SelectFuzz: Efficient Directed Fuzzing with Selective Path Exploration. In 2023 IEEE Symposium on Security and Privacy (SP). 2693–2707. doi:10.1109/SP46215.2023.10179296 Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Hanxi...

    2023

  31. [40]

    Yunlong Lyu, Yuxuan Xie, Peng Chen, and Hao Chen. 2024. Prompt Fuzzing for Fuzz Driver Generation. In Proceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security (Salt Lake City, UT, USA) (CCS ’24). Association for Computing Machinery, New York, NY...

    2024

  32. [41]

    Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J

    Valentin J.M. Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J. Schwartz, and Maverick Woo. 2021. The Art, Science, and Engineering of Fuzzing: A Survey. IEEE Transactions on Software Engineering 47, 11 (2021), 2312–2331. doi:10.1109/TSE.2019.2946563

    2021

  33. [42]

    Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large Language Model guided Protocol Fuzzing. Proceedings 2024 Network and Distributed System Security Symposium (2024). https://api.semanticscholar.org/ CorpusID:265296188

    2024

  34. [43]

    Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large language model guided protocol fuzzing. In Proceedings of the 31st Annual Network and Distributed System Security Symposium (NDSS)

    2024

  35. [44]

    Manh-Dung Nguyen, Sébastien Bardin, Richard Bonichon, Roland Groz, and Matthieu Lemerre. 2020. Binary-level Directed Fuzzing for Use-After-Free Vulnerabilities. In 23rd International Symposium on Research in Attacks, In- trusions and Defenses (RAID 2020) . USENIX Association, ...

    2020

  36. [45]

    Sebastian Österlund, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida. 2020. ParmeSan: Sanitizer-guided Greybox Fuzzing. In29th USENIX Security Symposium (USENIX Security 20) . USENIX Association, 2289–2306. https://www.usenix.org/ conference/usenixsecurity20/presentation/osterlund

    2020

  37. [46]

    Hammond Pearce, Baleegh Ahmad, Benjamin Tan, Brendan Dolan-Gavitt, and Ramesh Karri. 2021. Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions. arXiv:2108.09293 [cs.CR] https://arxiv.org/abs/ 2108.09293

    2021 arXiv

  38. [47]

    Ruizhong Qiu, Weiliang Will Zeng, Hanghang Tong, James Ezick, and Christopher Lott. 2024. How Efficient is LLM-Generated Code? A Rigorous & High-Standard Benchmark. arXiv:2406.06647 [cs.SE] https://arxiv.org/abs/2406.06647

    2024 arXiv

  39. [48]

    Wenxuan Shi, Yunhang Zhang, Xinyu Xing, and Jun Xu. 2024. Har- nessing Large Language Models for Seed Generation in Greybox Fuzzing. arXiv:2411.18143 [cs.CR] https://arxiv.org/abs/2411.18143

    2024 arXiv

  40. [49]

    Haijun Wang, Xiaofei Xie, Yi Li, Cheng Wen, Yuekang Li, Yang Liu, Shengchao Qin, Hongxu Chen, and Yulei Sui. 2020. Typestate-guided fuzzer for discovering use-after-free vulnerabilities. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering (Seou...

    2020 doi

  41. [50]

    Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2019. Superion: Grammar- aware greybox fuzzing. In 2019 IEEE/ACM 41st International Conference on Soft- ware Engineering (ICSE). IEEE, 724–735

    2019

  42. [51]

    Pengfei Wang, Xu Zhou, Tai Yue, Peihong Lin, Yingying Liu, and Kai Lu. 2023. The progress, challenges, and perspectives of directed greybox fuzzing. Software Testing, Verification and Reliability 34, 2 (Dec. 2023). doi:10.1002/stvr.1869

    2023 doi

  43. [52]

    Yanhao Wang, Xiangkun Jia, Yuwei Liu, Kyle Zeng, Tiffany Bao, Dinghao Wu, and Purui Su. 2020. Not All Coverage Measurements Are Equal: Fuzzing by Coverage Accounting for Input Prioritization. Proceedings 2020 Network and Distributed System Security Symposium (2020). https://ap...

    2020

  44. [53]

    Yi Xiang, Xuhong Zhang, Peiyu Liu, Shouling Ji, Hong Liang, Jiacheng Xu, and Wenhai Wang. 2024. Critical Code Guided Directed Greybox Fuzzing for Com- mits. In 33rd USENIX Security Symposium (USENIX Security 24) . USENIX As- sociation, Philadelphia, PA, 2459–2474. https://www....

    2024

  45. [54]

    Hanxiang Xu, Wei Ma, Ting Zhou, Yanjie Zhao, Kai Chen, Qiang Hu, Yang Liu, and Haoyu Wang. 2024. CKGFuzzer: LLM-Based Fuzz Driver Generation Enhanced By Code Knowledge Graph. arXiv:2411.11532 [cs.SE] https://arxiv.org/abs/2411. 11532

    2024 arXiv

  46. [55]

    Hanxiang Xu, Shenao Wang, Ningke Li, Kailong Wang, Yanjie Zhao, Kai Chen, Ting Yu, Yang Liu, and Haoyu Wang. 2024. Large Language Models for Cyber Security: A Systematic Literature Review. arXiv:2405.04760 [cs.CR] https://arxiv. org/abs/2405.04760

    2024

  47. [56]

    Yijiang Xu, Hongrui Jia, Liguo Chen, Xin Wang, Zhengran Zeng, Yidong Wang, Qing Gao, Jindong Wang, Wei Ye, Shikun Zhang, and Zhonghai Wu. 2024. ISC4DGF: Enhancing Directed Grey-box Fuzzing with LLM-Driven Initial Seed Corpus Generation. arXiv:2409.14329 [cs.SE] https://arxiv.o...

    2024 arXiv

  48. [57]

    Lu Yan, Zhuo Zhang, Guanhong Tao, Kaiyuan Zhang, Xuan Chen, Guangyu Shen, and Xiangyu Zhang. 2024. Parafuzz: An interpretability-driven technique for detecting poisoned samples in nlp. Advances in Neural Information Processing Systems 36 (2024)

    2024

  49. [58]

    Chenyuan Yang, Yinlin Deng, Runyu Lu, Jiayi Yao, Jiawei Liu, Reyhaneh Jab- barvand, and Lingming Zhang. 2023. WhiteFox: White-Box Compiler Fuzzing Empowered by Large Language Models. arXiv preprint arXiv:2310.15991 (2023)

    2023 arXiv

  50. [59]

    Wei You, Peiyuan Zong, Kai Chen, XiaoFeng Wang, Xiaojing Liao, Pan Bian, and Bin Liang. 2017. SemFuzz: Semantics-based Automatic Generation of Proof-of- Concept Exploits. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (Dallas, Texas, U...

    2017 doi

  51. [60]

    Cen Zhang, Mingqiang Bai, Yaowen Zheng, Yeting Li, Wei Ma, Xiaofei Xie, Yuekang Li, Limin Sun, and Yang Liu. 2023. Understanding large language model based fuzz driver generation. arXiv e-prints (2023), arXiv–2307

    2023

  52. [61]

    Jia-Ming Zhang, Zhan-Qi Cui, Xiang Chen, Huan-Huan Wu, Li-Wei Zheng, and Jian-Bin Liu. 2022. DeltaFuzz: historical version information guided fuzz testing. Journal of Computer Science and Technology 37, 1 (2022), 29–49

    2022

  53. [62]

    Yujian Zhang, Yaokun Liu, Jinyu Xu, and Yanhao Wang. 2024. Predecessor-aware Directed Greybox Fuzzing . In 2024 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, Los Alamitos, CA, USA, 1884–1900. doi:10.1109/SP54263. 2024.00040

    2024

  54. [63]

    Yuyue Zhao, Yangyang Li, Tengfei Yang, and Haiyong Xie. 2020. Suzzer: A Vulnerability-Guided Fuzzer Based on Deep Learning. InInternational Conference on Information Security and Cryptology

    2020

  55. [64]

    Zhuotong Zhou, Yongzhuo Yang, Susheng Wu, Yiheng Huang, Bihuan Chen, and Xin Peng. 2024. Magneto: A Step-Wise Approach to Exploit Vulnerabilities in Dependent Libraries via LLM-Empowered Directed Fuzzing. In 2024 39th IEEE/ACM International Conference on Automated Software Eng...

    2024

  56. [65]

    Xiaogang Zhu and Marcel Böhme. 2021. Regression greybox fuzzing. In Pro- ceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security. 2169–2182

    2021

  57. [66]

    Xiaogang Zhu, Sheng Wen, Seyit Camtepe, and Yang Xiang. 2022. Fuzzing: A Survey for Roadmap. ACM Comput. Surv.54, 11s, Article 230 (Sept. 2022), 36 pages. doi:10.1145/3512345

    2022 doi

  58. [67]

    Peiyuan Zong, Tao Lv, Dawei Wang, Zizhuang Deng, Ruigang Liang, and Kai Chen. 2020. FuzzGuard: filtering out unreachable inputs in directed grey-box fuzzing through deep learning. In Proceedings of the 29th USENIX Conference on Security Symposium (SEC’20). USENIX Association, ...

    2020

  59. [2024]

    2024 IEEE Sympo- sium on Security and Privacy (SP) (2024), 1849–1864

    Titan : Efficient Multi-target Directed Greybox Fuzzing. 2024 IEEE Sympo- sium on Security and Privacy (SP) (2024), 1849–1864. https://api.semanticscholar. org/CorpusID:268386913

    2024

Pith tools

Reviewed August 15, 2026 · model on record in the stance chip above.