Pith. sign in

REVIEW 3 major objections 5 minor 68 references

From Documentation to Zero-day Vulnerabilities: LLM-Driven Fuzzing of JavaScript Engines in PDF Readers

T0 review · 3 major / 5 minor · reviewed 2026-08-10 · deepseek-v4-flash

Pith's one-line read PDFuzzer claims that complex, value-coupled JavaScript call sequences produced from LLM-inferred API relationships and SMT solving find far more vulnerabilities in PDF readers than prior fuzzers.

desk verdict A serious, well-evidenced fuzzing paper whose 31 zero-days and coverage gains are credible, but the headline comparison overstates what is shown because competing fuzzers run only as generators under one shared wrapper. read the letter →

arxiv 2608.06641 v1 pith:5YJAYKU7 submitted 2026-08-06 cs.CR cs.SE

classification cs.CRcs.SE
keywords fuzzingPDFreadersJavaScriptenginesLLM-driventestgenerationAPIrelationshipinferenceSMTconstraintsolvingzero-dayvulnerabilitydiscoveryclosed-sourcesoftwaretesting
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

This paper argues that existing fuzzers for JavaScript engines inside PDF readers leave vulnerabilities undiscovered because they generate mostly standalone API calls and only recognize a narrow, type-based dependency between calls. PDFuzzer is a fuzzer that uses an LLM to turn API manuals and execution traces into full specifications for both documented and undocumented APIs, infers three kinds of relationships between API calls (producer-consumer, value-constraint, and implicit shared-state), and uses an SMT solver to produce concrete call sequences that satisfy those relationships. The authors report that this approach reaches up to 48% higher code coverage than prior fuzzers on Adobe Acrobat Reader, Foxit PDF Reader, and PDF-XChange Editor, and that over a two-week campaign it found 31 zero-day vulnerabilities while the best baseline found 6. The contribution is the claim that complex, value-coupled sequences, not individual calls, are what expose serious bugs in these closed-source engines.

What carries the argument

The central mechanism is a two-tier relationship model plus a four-stage generation pipeline. The two tiers are candidate relationships (co-occurrence only) and strong symbolic relationships, which carry SMT-LIB2 constraints and an optional ordering requirement. Strong symbolic relationships are classified as producer-consumer (a return value feeds another call's parameter), value-constraint (parameters must satisfy equality, set membership, range, or ordering constraints), or implicit (calls interact through shared reader state). PDFuzzer's pipeline extracts documented API specifications with a regex parser, recovers undocumented API signatures via differential analysis and enriches them with an LLM, builds a per-parameter context-free grammar for each API, uses retrieval-augmented generation plus a two-stage LLM pass to infer relationships, then instantiates calls and uses Z3 to solve the symbolic constraints into concrete sequences. The paper's key design choice is to keep LLM semantic reasoning separate from SMT constraint solving, and to generate grammars parameter-by-parameter so fine-grained value constraints are not flattened out of long API specifications.

What would settle it

Take the 31 minimized crash-triggering test cases and re-run each under PDFuzzer with Z3 constraint solving disabled but the same API call sequences; if most crashes survive, value-constraint solving is not the decisive ingredient. Separately, probe a sample of Foxit and PDF-XChange APIs to see whether the parameter constraints from Adobe's manual match the values those engines actually accept; a large mismatch would invalidate the cross-engine reference-specification assumption.

Watch

Extended reading notes

Core claim

On the paper's own terms, the discovery is that value-constraint and implicit relationships between JavaScript API calls can be extracted automatically and turned into executable test cases, and that doing so changes fuzzing outcomes. Of the 1,019 strong symbolic relationships PDFuzzer inferred, 87% were value-constraint, 6.2% implicit, and only 6.8% producer-consumer, which is why the paper judges producer-consumer-only tools insufficient. The paper demonstrates this with the Foxit use-after-free test case in which app.popUpMenuEx's cName and search.query's cQuery must be the same string, a coupling that name-similarity and return-value matching both miss. PDFuzzer's claim is that with this relationship model, 31 zero-day vulnerabilities can be found in three mainstream readers, 11 with potential for arbitrary code execution, and 26 already fixed by vendors at the time of writing.

Load-bearing premise

The load-bearing premise is that Adobe's JavaScript API manual accurately describes the JavaScript engines in Foxit PDF Reader and PDF-XChange Editor; if those engines diverge from Adobe's semantics, the inferred grammars and constraints would generate invalid sequences for two of the three targets.

Editorial extensions

If this is right

  • Fuzzers for other closed-source, scriptable applications should shift from isolated-call generation to relationship-aware sequence generation; the paper's ablation attributes up to 15.5% coverage gain to value-constraint and implicit relationships beyond producer-consumer-only settings.
  • Undocumented APIs become fuzzable targets rather than gaps: combining trace-derived signatures with LLM specification inference yields up to 28% higher coverage than type-only inference.
  • Parameter-level grammar generation is load-bearing; the paper reports that function-level grammars lose enumerated value sets and cost 5-18% coverage.
  • The method generalizes beyond JavaScript: the authors extract 2,925 VBA APIs from Microsoft Word's documentation and generate grammars for all of them, pointing toward fuzzing Office macros with the same pipeline.
  • Coverage is stable across LLMs: swapping GPT-4o for o3-mini or Claude-3.7-Sonnet changes coverage by under 1% on Adobe Acrobat Reader, so the approach does not depend on one particular model.

Reading between the lines

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

  • An untested consequence is that most of the benefit may come from simple equalities: since 75.2% of value-constraint relationships are direct equalities, a lightweight generator that reuses concrete strings across similarly named parameters could capture a large share of the reported gains without an LLM or SMT solver.
  • The 64% instantiation success rate for implicit relationships suggests shared-state preconditions are the bottleneck; explicitly modeling event and state machines inside the reader could raise that rate and yield further coverage gains.
  • The 93-98% LLM accuracy figures rest on 60 sampled outputs per stage, so they are estimates with wide uncertainty; a follow-up that degrades relationship-inference accuracy artificially would show how much of the 31-vulnerability count depends on inference quality.
  • The poor output quality of the general-purpose LLM fuzzer (mostly C, Java, or plain text) indicates that generic LLM fuzzing without domain-specific specification extraction is ill-suited to this target, but it also implies improvements to generic harnesses could one day close the gap.
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

3 major / 5 minor

Summary. The paper presents PDFuzzer, a fuzzer for the JavaScript engines embedded in PDF readers. PDFuzzer extracts API specifications from Adobe's JavaScript API manual and from execution traces, uses LLMs to generate parameter-level context-free grammars and to infer three classes of inter-API relationships (producer-consumer, value-constraint, and implicit), and then uses the Z3 SMT solver to generate concrete API-call sequences that satisfy the inferred constraints. The generated JavaScript is embedded into PDF documents and executed against Adobe Acrobat Reader, Foxit PDF Reader, and PDF-XChange Editor. The evaluation reports up to 48% higher basic-block coverage than prior tools, 31 zero-day vulnerabilities over a two-week campaign, and ablations showing that specification inference, parameter-level grammars, strong symbolic relationships, and PDF-object integration each contribute to coverage.

Significance. If the results hold, this is a useful contribution to API-level fuzzing: it automates specification extraction from natural-language documentation, models relationship types beyond producer-consumer dependencies, and demonstrates concrete security impact with 31 reported vulnerabilities, including CVEs and vendor bounties. The paper's strengths include a broad evaluation across three commercial targets, a two-week vulnerability campaign, a component-wise ablation study, spot-check evaluations of LLM accuracy (93-98%), and a public artifact link. The main caveat is that the comparison against prior fuzzers is scoped to test-case generation under a common wrapper rather than to the released full fuzzing systems, so the headline claims need to be tempered or supplemented.

major comments (3)
  1. [§5.2, Figure 2, Table 1] The evaluation compares only test-case generators, not the released fuzzing systems. Section 5.2 states that TypeOracle's public wrapper is used uniformly for all methods and that the evaluation does not compare online fuzzing loops. Cooper and Favocado, however, ship with their own mutation, corpus, and scheduling logic, which is discarded here. The abstract and Section 1 claim that PDFuzzer 'significantly outperforms state-of-the-art PDF fuzzers' and report '31 vs at most 6' vulnerabilities; these claims are not established for the full tools. Please either add a comparison that runs Cooper, Favocado, and TypeOracle with their native loops, or revise the contribution and headline claims to state explicitly that the comparison is among test-case generators under a common execution harness.
  2. [§6.1, Figure 2] Coverage results are reported only as means over five runs, without standard deviations, confidence intervals, or per-run data points. The claim that PDFuzzer 'significantly outperforms' baselines by 15-48% is therefore not statistically supported, and some of the smaller gaps in Figure 2 (for example between PDFuzzer and TypeOracle+Favocado on Adobe) could be within run-to-run variation. Please report the variance or provide the per-run coverage values.
  3. [§4.3] The pipeline uses Adobe's JavaScript API manual as the reference specification for Foxit PDF Reader and PDF-XChange Editor, with the justification that both implement Adobe's de facto standard. This assumption is load-bearing for two of the three targets: if those engines diverge in parameter semantics, value-constraint, or implicit relationships, the inferred grammars and constraints would produce invalid sequences and the coverage and vulnerability results for Foxit and XChange would be affected. The empirical finds in Foxit partially mitigate this concern, but the paper should validate API compatibility more directly, for example by checking a random sample of inferred invocations against each engine's runtime behavior or by documenting known divergences.
minor comments (5)
  1. [Abstract] The phrase 'requiresequencesof API calls' is missing spaces; similar formatting spacing issues occur throughout (e.g., 'PDFuzzercan', 'PDFuzzeris', 'TypeOracle’srandom'). A copyediting pass would improve readability.
  2. [§3.2] The sentence 'the constraints can be broader that equality' should read 'broader than equality'.
  3. [§5.2] The phrase 'Because our targets are closed-sourced' should be 'closed-source'.
  4. [Figure 2] The coverage plots would be more informative with error bars or shaded confidence bands, especially since coverage is reported as a mean over five runs, and with a consistent legend across all six panels.
  5. [Table 1] The table uses '...' to denote omitted rows in several places. Please ensure the published version contains the complete table with all 31 entries, or clearly indicate the truncation.

Circularity Check

0 steps flagged · score 1.0 of 10

No circular derivation: the reported coverage and vulnerability results are empirical outputs of an LLM-plus-SMT generation pipeline, not consequences of fitted parameters or self-referential definitions; self-citations to TypeOracle are transparent component/baseline reuse and are not load-bearing circular evidence.

full rationale

The paper's central claims are empirical: PDFuzzer achieves up to 48% higher coverage and finds 31 zero-day vulnerabilities. These outcomes are measured after test-case generation and execution, not derived from equations or from fitted parameters that are then renamed as predictions. The LLM-inferred specifications, grammars, and SMT constraints are constructed before execution from documentation and execution traces; nothing in the pipeline is fitted to the vulnerability or coverage outcomes. The main self-overlap is TypeOracle [24], used both as a component for undocumented API signature extraction (Section 4.3, Stage 1) and as a baseline (Section 5.2). This is transparently disclosed, and the ablation table explicitly compares against TypeOracle, TypeOracle+Cooper, and TypeOracle+Favocado, so the comparison does not reduce PDFuzzer's advantage to a self-citation chain. The one minor self-citation in Section 4.3 ('Adobe's JavaScript API has become the de facto standard for PDF JavaScript engines, and Foxit and PDF-XChange both implement it, as noted in prior work [24]') is not load-bearing because the paper independently demonstrates the premise by finding real vulnerabilities in Foxit and PDF-XChange using Adobe-derived specifications. Section 5.2's decision to compare only test-case generators under a uniform TypeOracle wrapper is a scoping limitation for the headline 'outperforms state-of-the-art fuzzers,' but it is an evaluation-fairness concern, not circularity: the generator outputs are not defined in terms of the measured coverage or crash outcomes. No step in the derivation chain reduces by construction to its own inputs.

Assumptions & free parameters 2 free parameters · 5 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities; 'value-constraint relationship' and 'implicit relationship' are taxonomical concepts, not postulated objects. The central claim rests on the five domain assumptions above; none is machine-checked, and none is independently falsifiable outside the reported experiments. The two configurable hyperparameters listed are the most consequential hand-set numbers in the generation pipeline.

free parameters (2)
  • max_sequence_length = 2000 API calls
    Configurable upper bound on generated call-sequence length, set by hand in Section 4.6 based on empirical execution-time concerns; it directly affects the space of sequences explored.
  • targeted_mutation_fraction = 15% of generated test cases
    Share of test cases receiving malformed-input mutation in Section 4.6 Stage 4; chosen by hand and influences robustness-triggered crashes.
assumptions (5)
  • domain assumption Adobe JavaScript API manual is a valid reference specification for Foxit and PDF-XChange
    Section 4.3 states Adobe's API is the de facto standard and that Foxit and PDF-XChange implement it; if their APIs diverge, the inferred grammars and relationships for two of the three targets are invalid.
  • domain assumption LLM-inferred specifications, grammars, and relationships are sufficiently accurate for valid test generation
    The pipeline trusts LLM outputs (93-98% spot-check accuracy in Section 6.6) to produce syntactically and semantically valid API invocations; errors propagate into test quality.
  • domain assumption TypeOracle differential analysis yields correct raw signatures for undocumented APIs
    Section 4.3 Stage 1 relies on TypeOracle's operand-variation analysis to recover object/method names and parameter types; incorrect signatures would mislead the LLM specification inference.
  • domain assumption DynamoRIO basic-block coverage is a valid, comparable measure of exercised code under the uniform wrapper
    Section 5.2 uses DynamoRIO dynamic instrumentation on closed-source readers; the assumption is that this metric captures meaningful code exploration and is equally fair across all tested generators.
  • domain assumption Normalized call-stack signatures group crashes into distinct vulnerabilities
    Section 6.2 deduplicates the 57 crashing inputs into 31 unique vulnerabilities by comparing normalized call-stack signatures; if the signature similarity threshold is coarse, distinct bugs could be merged or split.

how reviews work

0 comments
Cite this review

Pith. "Pith review of From Documentation to Zero-day Vulnerabilities: LLM-Driven Fuzzing of JavaScript Engines in PDF Readers." pith.science (2026). https://pith.science/paper/5YJAYKU7

@misc{pith2026260806641,
  author       = {Pith},
  title        = {Pith review of: From Documentation to Zero-day Vulnerabilities: LLM-Driven Fuzzing of JavaScript Engines in PDF Readers},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/5YJAYKU7}},
  note         = {Machine review of arXiv:2608.06641}
}
read the original abstract

Existing fuzzers for PDF readers rely on simple test cases that involve only individual API calls, leading to limited coverage and potentially missing vulnerabilities that require sequences of API calls. To address these limitations, we propose PDFuzzer, a novel PDF engine fuzzer that automatically generates complex and meaningful API call sequences. PDFuzzer first uses a Large Language Model (LLM) to construct context-free grammars and infer the relationships between individual API calls from specifications extracted from JavaScript API manuals and execution traces. Based on the grammars and relationships, PDFuzzer employs a constraint solver to generate concrete API call sequences for fuzzing. Our experiments show that PDFuzzer significantly outperforms state-of-the-art PDF fuzzers (TypeOracle, Favocado, and Cooper) and LLM-based fuzzers (Fuzz4All, naive LLM) on three mainstream PDF readers: Adobe Acrobat Reader, Foxit PDF Reader, and PDF-XChange Editor. PDFuzzer achieves up to 48% higher coverage than existing tools and identifies 31 zero-day vulnerabilities in these readers, from information leakage to arbitrary code execution. Our ablation study validates the necessity of each component, including LLMs, which achieve high accuracy across all pipeline stages (93-98%). We disclosed all vulnerabilities to the vendors via a coordinated vulnerability disclosure process and received bug bounties.

Figures

Figures reproduced from arXiv: 2608.06641 by the authors.

Figure 1
Figure 1. Overview of PDFuzzer. Documented APIs are extracted by the API Manual Parser; undocumented APIs are recovered by Specification Inference from execution traces. Both Doc spec and Undoc spec feed Grammar Generation and Relationship Inference in parallel. Their outputs (per-parameter CFGs and symbolic constraints) drive the Test Case Generator, which additionally consumes Sample PDFs for native-object templates. The re… view at source ↗
Figure 2
Figure 2. (Top row) PDFuzzer vs. traditional tools. (Bottom row) PDFuzzer vs. LLM-based tools. inputs in two steps. First, for each test case, we performed statement￾level reduction by iteratively deleting JavaScript statements and keeping the smallest subset that still reproduces the crash. Second, we deduplicated the minimized crashes by comparing normalized call-stack signatures, following TypeOracle [24] and Cooper [63]. … view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

68 extracted references · 65 canonical work pages

  1. [1]

    CVE-2008-2992

    2008. CVE-2008-2992. https://www.coresecurity.com/core-labs/advisories/adobe- reader-buffer-overflow/

  2. [2]

    CVE-2017-10951

    2017. CVE-2017-10951. https://www.zerodayinitiative.com/blog/2017/8/17/ busting-myths-in-foxit-reader/

  3. [3]

    Adobe. 2025. Doc and Doc.Media APIs — Acrobat-PDFL SDK: JavaScript Refer- ence

  4. [4]

    Adobe. 2025. JavaScript APIs — Acrobat-PDFL SDK: JavaScript Reference

  5. [5]

    José Antonio Zamudio Amaya. 2024. Shaping Test Inputs in Grammar-Based Fuzzing. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA, Maria Christakis and Michael Pradel (Eds.). ACM, 1901–1905

  6. [6]

    Anthropic. 2025. Anthropic Claude 3.7 Sonnet Model

  7. [7]

    Cornelius Aschermann, Tommaso Frassetto, Thorsten Holz, Patrick Jauernig, Ahmad-Reza Sadeghi, and Daniel Teuchert. 2019. NAUTILUS: Fishing for Deep Bugs with Grammars. In26th Annual Network and Distributed System Security Symposium, NDSS

  8. [8]

    Asmita, Yaroslav Oliinyk, Michael Scott, Ryan Tsang, Chongzhou Fang, and Houman Homayoun. 2024. Fuzzing BusyBox: Leveraging LLM and Crash Reuse for Embedded Bug Unearthing. In33rd USENIX Security Symposium, USENIX Security, Davide Balzarotti and Wenyuan Xu (Eds.). USENIX Association

Show all 68 references
  1. [9]

    Vaggelis Atlidakis, Patrice Godefroid, and Marina Polishchuk. 2019. RESTler: stateful REST API fuzzing. InProceedings of the 41st International Conference on Software Engineering, ICSE, Joanne M. Atlee, Tevfik Bultan, and Jon Whittle (Eds.). IEEE / ACM, 748–758

  2. [10]

    2025.The SMT-LIB Standard: Version 2.7

    Clark Barrett, Pascal Fontaine, and Cesare Tinelli. 2025.The SMT-LIB Standard: Version 2.7. Technical Report. Department of Computer Science, The University of Iowa. Available atwww.SMT-LIB.org

  3. [11]

    Weiteng Chen, Yu Hao, Zheng Zhang, Xiaochen Zou, Dhilung Kirat, Shachee Mishra, Douglas Lee Schales, Jiyong Jang, and Zhiyun Qian. 2024. SyzGen++: Dependency Inference for Augmenting Kernel Driver Fuzzing. InIEEE Symposium on Security and Privacy, SP. IEEE, 4661–4677

  4. [12]

    Weiteng Chen, Yu Wang, Zheng Zhang, and Zhiyun Qian. 2021. SyzGen: Auto- mated Generation of Syscall Specification of Closed-Source macOS Drivers. In CCS ’21: 2021 ACM SIGSAC Conference on Computer and Communications Security, Yongdae Kim, Jong Kim, Giovanni Vigna, and Elaine ...

  5. [13]

    Jake Corina, Aravind Machiry, Christopher Salls, Yan Shoshitaishvili, Shuang Hao, Christopher Kruegel, and Giovanni Vigna. 2017. DIFUZE: Interface Aware Fuzzing for Kernel Drivers. InProceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS, Bh...

  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. InProceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and...

  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. In Proceedings of the 46th IEEE/ACM International Confe...

  8. [16]

    Sung Ta Dinh, Haehyun Cho, Kyle Martin, Adam Oest, Kyle Zeng, Alexandros Kapravelos, Gail-Joon Ahn, Tiffany Bao, Ruoyu Wang, Adam Doupé, and Yan Shoshitaishvili. 2021. Favocado: Fuzzing the Binding Code of JavaScript Engines Using Semantically Correct Test Cases. In28th Annual...

  9. [17]

    DynamoRIO. 2025. DynamoRIO. https://dynamorio.org/

  10. [18]

    Jueon Eom, Seyeon Jeong, and Taekyoung Kwon. 2024. Fuzzing JavaScript Inter- preters with Coverage-Guided Reinforcement Learning for LLM-Based Mutation. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA, Maria Christakis and ...

  11. [19]

    Marius Fleischer, Dipanjan Das, Priyanka Bose, Weiheng Bai, Kangjie Lu, Mathias Payer, Christopher Kruegel, and Giovanni Vigna. 2023. ACTOR: Action-Guided Kernel Fuzzing. In32nd USENIX Security Symposium, USENIX Security, Joseph A. Calandrino and Carmela Troncoso (Eds.). USENI...

  12. [20]

    Patrice Godefroid, Bo-Yuan Huang, and Marina Polishchuk. 2020. Intelligent REST API data fuzzing. InESEC/FSE ’20: 28th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, Prem Devanbu, Myra B. Cohen, and Thomas Zimmerman...

  13. [21]

    Harrison Green and Thanassis Avgerinos. 2022. GraphFuzz: Library API Fuzzing with Lifetime-aware Dataflow Graphs. In44th IEEE/ACM 44th International Con- ference on Software Engineering, ICSE. ACM, 1070–1081

  14. [22]

    Samuel Groß, Simon Koch, Lukas Bernhard, Thorsten Holz, and Martin Johns

  15. [23]

    Xiaodong Gu, Hongyu Zhang, Dongmei Zhang, and Sunghun Kim. 2016. Deep API learning. InProceedings of the 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering, FSE, Thomas Zimmermann, Jane Cleland- Huang, and Zhendong Su (Eds.). ACM, 631–642

  16. [24]

    Suyue Guo, Xinyu Wan, Wei You, Bin Liang, Wenchang Shi, Yiwei Zhang, Jianjun Huang, and Jian Zhang. 2023. Operand-Variation-Oriented Differential Analy- sis for Fuzzing Binding Calls in PDF Readers. In45th IEEE/ACM International Conference on Software Engineering, ICSE. IEEE, 95–107

  17. [25]

    Xiaofeng Guo, Xin Peng, Hanzhang Wang, Wanxue Li, Huai Jiang, Dan Ding, Tao Xie, and Liangfei Su. 2020. Graph-based trace analysis for microservice archi- tecture understanding and problem diagnosis. InESEC/FSE ’20: 28th ACM Joint European Software Engineering Conference and S...

  18. [26]

    HyungSeok Han and Sang Kil Cha. 2017. IMF: Inferred Model-based Fuzzer. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, CCS, Bhavani Thuraisingham, David Evans, Tal Malkin, and Dongyan Xu (Eds.). ACM, 2345–2358

  19. [27]

    HyungSeok Han, DongHyeon Oh, and Sang Kil Cha. 2019. CodeAlchemist: Semantics-Aware Code Generation to Find Vulnerabilities in JavaScript Engines. In26th Annual Network and Distributed System Security Symposium, NDSS

  20. [28]

    Yu Hao, Guoren Li, Xiaochen Zou, Weiteng Chen, Shitong Zhu, Zhiyun Qian, and Ardalan Amiri Sani. 2023. SyzDescribe: Principled, Automated, Static Generation of Syscall Descriptions for Kernel Drivers. In44th IEEE Symposium on Security and Privacy, SP. IEEE, 3262–3278

  21. [29]

    Yu Hao, Hang Zhang, Guoren Li, Xingyun Du, Zhiyun Qian, and Ardalan Amiri Sani. 2022. Demystifying the Dependency Challenge in Kernel Fuzzing. In44th IEEE/ACM 44th International Conference on Software Engineering, ICSE. ACM, 659–671

  22. [30]

    Renáta Hodován, Ákos Kiss, and Tibor Gyimóthy. 2018. Grammarinator: a grammar-based open source fuzzer. InProceedings of the 9th ACM SIGSOFT International Workshop on Automating TEST Case Design, Selection, and Evaluation, A-TEST@SIGSOFT FSE, Wishnu Prasetya, Tanja E. J. Vos, ...

  23. [31]

    Christian Holler, Kim Herzig, and Andreas Zeller. 2012. Fuzzing with Code Fragments. InProceedings of the 21th USENIX Security Symposium, Tadayoshi Kohno (Ed.)

  24. [32]

    Ispoglou, Daniel Austin, Vishwath Mohan, and Mathias Payer

    Kyriakos K. Ispoglou, Daniel Austin, Vishwath Mohan, and Mathias Payer. 2020. FuzzGen: Automatic Fuzzer Generation. In29th USENIX Security Symposium, USENIX Security, Srdjan Capkun and Franziska Roesner (Eds.). USENIX Associa- tion, 2271–2287

  25. [33]

    Le and David Lo

    Tien-Duy B. Le and David Lo. 2018. Deep specification mining. InProceedings of the 27th ACM SIGSOFT International Symposium on Software Testing and Analysis, ISSTA, Frank Tip and Eric Bodden (Eds.). ACM, 106–117

  26. [34]

    Jiayi Lin, Qingyu Zhang, Junzhe Li, Chenxin Sun, Hao Zhou, Changhua Luo, and Chenxiong Qian. 2025. Automatic Library Fuzzing through API Relation Evolvement. In32nd Annual Network and Distributed System Security Symposium, NDSS. The Internet Society

  27. [35]

    Yuwei Liu, Yanhao Wang, Xiangkun Jia, Zheng Zhang, and Purui Su. 2024. AFGen: Whole-Function Fuzzing for Applications and Libraries. InIEEE Symposium on Security and Privacy, SP. IEEE, 1901–1919

  28. [36]

    Chenyang Lyu, Jiacheng Xu, Shouling Ji, Xuhong Zhang, Qinying Wang, Binbin Zhao, Gaoning Pan, Wei Cao, Peng Cheng, and Raheem Beyah. 2023. MINER: A Hybrid Data-Driven Approach for REST API Fuzzing. In32nd USENIX Security Symposium, USENIX Security, Joseph A. Calandrino and Car...

  29. [37]

    Yunlong Lyu, Yuxuan Xie, Peng Chen, and Hao Chen. 2024. Prompt Fuzzing for Fuzz Driver Generation. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communications Security (CCS ’24). Association for Computing Machinery, 3793–3807

  30. [38]

    Xiaoyue Ma, Lannan Luo, and Qiang Zeng. 2024. From One Thousand Pages of Specification to Unveiling Hidden Bugs: Large Language Model Assisted Fuzzing of Matter IoT Devices. In33rd USENIX Security Symposium, USENIX Security, Davide Balzarotti and Wenyuan Xu (Eds.). USENIX Association

  31. [39]

    Ruijie Meng, Martin Mirchev, Marcel Böhme, and Abhik Roychoudhury. 2024. Large Language Model guided Protocol Fuzzing. In31st Annual Network and Distributed System Security Symposium, NDSS. The Internet Society

  32. [40]

    Microsoft. 2025. Windows Error Reporting. https://learn.microsoft.com/en- us/windows/win32/wer/windows-error-reporting

  33. [41]

    Microsoft Research. 2025. Z3 Solver

  34. [42]

    Hoan Anh Nguyen, Hung Dang Phan, Syeda Khairunnesa Samantha, Son Nguyen, Aashish Yadavally, Shaohua Wang, Hridesh Rajan, and Tien N. Nguyen. 2022. A Hybrid Approach for Inference between Behavioral Exception API Documenta- tion and Implementations, and Its Applications. In37th...

  35. [43]

    Mitchell Olsthoorn, Dimitri Michel Stallenberg, Arie van Deursen, and Annibale Panichella. 2022. SynTest-Solidity: Automated Test Case Generation and Fuzzing for Smart Contracts. In44th IEEE/ACM International Conference on Software Engineering: Companion Proceedings, ICSE Comp...

  36. [44]

    OpenAI. 2025. File search. https://platform.openai.com/docs/guides/tools-file- search

  37. [45]

    OpenAI. 2025. OpenAI GPT-4o Model

  38. [46]

    OpenAI. 2025. OpenAI o3-mini Model

  39. [47]

    Shankara Pailoor, Andrew Aday, and Suman Jana. 2018. MoonShine: Optimizing OS Fuzzer Seed Selection with Trace Distillation. In27th USENIX Security Sym- posium, USENIX Security, William Enck and Adrienne Porter Felt (Eds.). USENIX Association, 729–743

  40. [48]

    Christopher Salls, Chani Jindal, Jake Corina, Christopher Kruegel, and Giovanni Vigna. 2021. Token-Level Fuzzing. In30th USENIX Security Symposium, USENIX Security, Michael D. Bailey and Rachel Greenstadt (Eds.). USENIX Association, 2795–2809

  41. [49]

    Max Schäfer, Sarah Nadi, Aryaz Eghbali, and Frank Tip. 2024. An Empirical Evaluation of Using Large Language Models for Automated Unit Test Generation. IEEE Trans. Software Eng.50, 1 (2024), 85–105

  42. [50]

    Hao Sun, Yuheng Shen, Jianzhong Liu, Yiru Xu, and Yu Jiang. 2022. KSG: Aug- menting Kernel Fuzzing with System Call Specification Generation. InProceedings of the 2022 USENIX Annual Technical Conference, USENIX ATC, Jiri Schindler and Noa Zilberman (Eds.). USENIX Association, 351–366

  43. [51]

    Hao Sun, Yuheng Shen, Cong Wang, Jianzhong Liu, Yu Jiang, Ting Chen, and Aiguo Cui. 2021. HEALER: Relation Learning Guided Kernel Fuzzing. InSOSP ’21: ACM SIGOPS 28th Symposium on Operating Systems Principles, Robbert van Renesse and Nickolai Zeldovich (Eds.). ACM, 344–358

  44. [52]

    The MITRE Corporation. 2026. CVE-2024-28888. https://www.cve.org/ CVERecord?id=CVE-2024-28888/

  45. [53]

    The MITRE Corporation. 2026. CVE-2024-34099. https://www.cve.org/ CVERecord?id=CVE-2024-34099/

  46. [54]

    Liam Wachter, Julian Gremminger, Christian Wressnegger, Mathias Payer, and Flavio Toffalini. 2025. DUMPLING: Fine-grained Differential JavaScript Engine Fuzzing. In32nd Annual Network and Distributed System Security Symposium, NDSS. The Internet Society

  47. [55]

    Dawei Wang, Geng Zhou, Li Chen, Dan Li, and Yukai Miao. 2024. ProphetFuzz: Fully Automated Prediction and Fuzzing of High-Risk Option Combinations with Only Documentation via Large Language Model. InProceedings of the 2024 on ACM SIGSAC Conference on Computer and Communication...

  48. [56]

    Junjie Wang, Bihuan Chen, Lei Wei, and Yang Liu. 2019. Superion: grammar- aware greybox fuzzing. InProceedings of the 41st International Conference on Software Engineering, ICSE, Joanne M. Atlee, Tevfik Bultan, and Jon Whittle (Eds.). IEEE / ACM, 724–735

  49. [57]

    Jiming Wang, Yan Kang, Chenggang Wu, Yuhao Hu, Yue Sun, Jikai Ren, Yuan- ming Lai, Mengyao Xie, Charles Zhang, Tao Li, and Zhe Wang. 2024. OptFuzz: Optimization Path Guided Fuzzing for JavaScript JIT Compilers. In33rd USENIX Security Symposium, USENIX Security, Davide Balzarot...

  50. [58]

    Jincheng Wang, Le Yu, and Xiapu Luo. 2024. LLMIF: Augmented Large Language Model for Fuzzing IoT Devices. InIEEE Symposium on Security and Privacy, SP. IEEE, 881–896

  51. [59]

    Chi, Quoc V

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, and Denny Zhou. 2022. Chain-of-thought prompting elicits reasoning in large language models. InProceedings of the 36th International Conference on Neural Information Processin...

  52. [60]

    Chunqiu Steven Xia, Matteo Paltenghi, Jia Le Tian, Michael Pradel, and Lingming Zhang. 2024. Fuzz4All: Universal Fuzzing with Large Language Models. In Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, ICSE. ACM, 126:1–126:13

  53. [61]

    Danning Xie, Yitong Li, Mijung Kim, Hung Viet Pham, Lin Tan, Xiangyu Zhang, and Michael W. Godfrey. 2022. DocTer: documentation-guided fuzzing for testing deep learning API functions. InISSTA ’22: 31st ACM SIGSOFT International Sym- posium on Software Testing and Analysis, Suk...

  54. [62]

    Jiacheng Xu, Xuhong Zhang, Shouling Ji, Yuan Tian, Binbin Zhao, Qinying Wang, Peng Cheng, and Jiming Chen. 2024. MOCK: Optimizing Kernel Fuzzing Mutation with Context-aware Dependency. In31st Annual Network and Distributed System Security Symposium, NDSS. The Internet Society

  55. [63]

    Peng Xu, Yanhao Wang, Hong Hu, and Purui Su. 2022. COOPER: Testing the Binding Code of Scripting Languages with Cooperative Mutation. In29th Annual Network and Distributed System Security Symposium, NDSS. The Internet Society

  56. [64]

    Chenyuan Yang, Zijie Zhao, and Lingming Zhang. 2025. KernelGPT: Enhanced Kernel Fuzzing via Large Language Models. InProceedings of the 30th ACM CCS ’26, November 15–19, 2026, The Hague, Netherlands Suyue Guo et al. International Conference on Architectural Support for Program...

  57. [65]

    Hongxiang Zhang, Yuyang Rong, Yifeng He, and Hao Chen. 2024. LLAMAFUZZ: Large Language Model Enhanced Greybox Fuzzing.CoRRabs/2406.07714 (2024). arXiv:2406.07714

  58. [66]

    Kunpeng Zhang, Zongjie Li, Daoyuan Wu, Shuai Wang, and Xin Xia. 2025. Low- Cost and Comprehensive Non-textual Input Fuzzing with LLM-Synthesized Input Generators.CoRRabs/2501.19282 (2025). arXiv:2501.19282

  59. [67]

    Hao Zhong, Na Meng, Zexuan Li, and Li Jia. 2020. An empirical study on API parameter rules. InICSE ’20: 42nd International Conference on Software Engineering, Gregg Rothermel and Doo-Hwan Bae (Eds.). ACM, 899–911. A Ethical Considerations A.1 Identified Stakeholders and Impact...

  60. [2023]

    In30th Annual Network and Distributed System Security Symposium, NDSS

    FUZZILLI: Fuzzing for JavaScript JIT Compiler Vulnerabilities. In30th Annual Network and Distributed System Security Symposium, NDSS

Pith tools

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