Pith. sign in

REVIEW 3 major objections 5 minor 50 references

Neuro-Symbolic Proof-of-Vulnerability Generation with Open-Weight Models

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

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

Pith's one-line read POVGEN claims that a three-stage neuro-symbolic pipeline—manifestation localization, anchored path exploration, and LLM-guided constraint solving with an SMT fallback—generates valid proofs of vulnerability for 78.98% of benchmarked…

desk verdict The ARVO numbers are credible; the 74.80% real-world claim lacks a defined success criterion and needs revision. read the letter →

arxiv 2608.04217 v1 pith:7ZQYK62E submitted 2026-08-04 cs.SE

Yu Nong , Haipeng Cai This is my paper · ORCID
classification cs.SE
keywords proof-of-vulnerabilitygenerationneuro-symbolicmanifestationlocalizationpath-sensitiveexplorationLLM-guidedconstraintsolvingopen-weightmodelsCVEreproductionpatchvalidation
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

Disclosed vulnerabilities usually arrive with a patch but not with a concrete input that triggers the flaw, so the vulnerability and its fix remain hard to validate. This paper argues that such inputs—proofs of vulnerability—can be generated automatically by a three-stage pipeline: localize where the vulnerability manifests, explore a small set of program paths that reach that point, and extract and solve the path constraints a triggering input must satisfy. The system, POVGEN, performs the constraint reasoning with two fine-tuned open-weight models backed by an SMT solver, keeping per-sample model cost near zero for the core constraint steps. On a 490-case sample of a recent memory-safety benchmark it succeeds on 78.98% of cases in patch-guided mode, versus up to 50.20% for fuzzing and 2.45% for symbolic execution, and on 250 real-world CVEs without public PoVs it reaches 74.80%. If the result holds, disclosed vulnerabilities can be turned into reproducible evidence, patch-validation tests, and regression tests at scale without relying on proprietary model APIs.

What carries the argument

The load-bearing mechanism is the pairing of three fine-tuned open-weight models with an SMT fallback: a Manifestation Localization Model (MLM) that predicts the line where the vulnerability manifests, a Constraints Extraction Model (CEM) that converts a candidate path into SMT constraints, and a Constraints Solving Model (CSM) that emits a Python script producing the triggering input. The exploration that feeds them is an anchored random walk on the interprocedural control-flow graph, biased by backward shortest-path distances toward the manifestation point (and the patch location when available), which turns whole-program search into a focused reachability problem over a few dozen candidate paths.

What would settle it

Run POVGEN on a fresh set of CVEs from projects not represented in its training data and see whether the success rate stays near 74.80%; if it drops sharply and the fallback solver rescues few of the failures, the generalization claim is not supported.

Watch

Extended reading notes

Core claim

POVGEN's central claim is that vulnerability-targeted input synthesis becomes tractable when the search is anchored at the site where the vulnerability actually manifests, rather than at the patch location, because patches often sit far from the triggering condition. Given a target program and optionally a patch, POVGEN first uses a fine-tuned localization model to mark the manifestation point, then runs anchored random walks over the interprocedural control-flow graph to collect a small set of candidate paths from program entry to that point, and finally converts each path into SMT constraints via a constraint-extraction model and into a concrete PoV via a constraint-solving model, with an SMT solver as fallback. The paper reports that this decomposition lets task-specialized open-weight models match frontier commercial LLMs on the core constraint-reasoning subtasks while running locally, and that the end-to-end system outperforms both fuzzing and symbolic-execution baselines on a common benchmark and succeeds on 74.80% of real-world CVEs without public PoVs. Applying the generated PoVs to patched versions of those CVEs surfaced six flawed patches, all later fixed, and five previously unreported vulnerabilities in newer project versions.

Load-bearing premise

The fine-tuned models that translate a candidate execution path into logical conditions, and then into a concrete input, were trained on benchmark programs with a few added synthetic patterns; the whole result depends on those models handling the conditions found in real-world vulnerabilities they never saw during training.

Editorial extensions

If this is right

  • If POVGEN's success rate holds on new data, every patched CVE can be checked by replaying a generated PoV against the patched build, which is exactly how the paper identified six flawed patches.
  • For CVEs without public PoVs, defenders and vendors can obtain a concrete triggering input without waiting for an exploit disclosure, making the PoV available as a regression test.
  • Because the core constraint models are pinned and run locally, vulnerability research no longer depends on the continued availability or pricing of proprietary models for this task.
  • The paper's modular design implies the same localization-exploration-constraint pipeline can be adapted to other vulnerability classes and languages, though the evaluation only covers C/C++ memory-safety.

Reading between the lines

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

  • Editorial inference: the generalization claim is only as strong as the training distribution; the constraint models were fine-tuned on benchmark suites plus four synthetic templates, so a fresh CVE whose path constraints do not resemble those motifs may fall through to the SMT fallback and fail if the constraints are not solver-friendly.
  • Editorial inference: the reported 74.80% real-world figure is measured on projects whose build environments and harnesses already exist; applying POVGEN to arbitrary new codebases would add non-trivial setup cost that the paper explicitly leaves out of scope.
  • Editorial inference: a sharper ablation would swap CSM for a deterministic input generator that ignores the constraints and retains only the SMT fallback; the paper's partial solver-only comparison suggests the solver alone is weaker, but the exact contribution of the solving model is not isolated end-to-end.
Share X Bluesky LinkedIn Reddit HN

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. POVGEN is a neuro-symbolic pipeline for generating Proof-of-Vulnerability (PoV) inputs for disclosed C/C++ memory-safety vulnerabilities. It combines (1) a fine-tuned open-weight LLM for vulnerability manifestation localization, (2) anchored random walks over the interprocedural CFG to extract candidate paths, and (3) fine-tuned constraint-extraction and constraint-solving models with an SMT fallback to produce concrete inputs. The paper reports 78.98% success on a 490-sample ARVO subset in patch-guided mode and 65.10% without patch, outperforming fuzzing baselines (up to 50.20%) and KLEE (2.45%). On 250 real-world CVEs without public PoVs, it reports 74.80% valid PoVs. The generated PoVs allegedly exposed six flawed patches and five previously unreported vulnerabilities.

Significance. If the results hold, POVGEN would be a substantial step toward automating PoV generation at scale with locally deployable models. The ARVO evaluation uses a strict, ground-truth-matched success criterion; the 490-sample sampling with confidence interval, disjointness checks against fine-tuning data, and extensive ablations (Tables IV–VI) are methodological strengths. The decomposition of the problem into localization, path exploration, and constraint reasoning, plus the SMT fallback, is a sensible and potentially generalizable design. However, the real-world claim (RQ5) lacks a defined success criterion, so the paper's headline external-validity result is not yet interpretable.

major comments (3)
  1. [§V-F (RQ5), Table VII] The success criterion for the 250 real-world CVEs without public PoVs is never defined. Section V-B defines success for ARVO as a sanitizer error whose vulnerability type and crash location match the ground-truth PoV, but RQ5 has no ground truth by construction. The manuscript does not state whether the generated input was run against both the vulnerable and patched builds, whether the crash type or site was required to align with the CVE or patch, or whether independent confirmation was used. Without this, the 74.80% figure cannot be distinguished from 'any sanitizer crash on the vulnerable binary' and is uninterpretable as a vulnerability-specific success rate. A concrete success criterion for this set must be specified, and the evaluation re-run or re-reported under it. The motivating example in Fig. 1 also shows that the manifestation point can be far from the patch, so requiring crash-site match to the patch would need careful justification against the paper's own definition of reproduction.
  2. [Abstract and §V-B/§V-F] The abstract states: 'On 250 real-world CVEs without public PoVs, it generates valid PoVs for 74.80% of cases and reproduces 65.1% when without patch information.' In the body, the 65.10% patch-free figure is reported only for the 490 ARVO vulnerabilities (Table I, 'Overall' row), while §V-F and Table VII report only the 74.80% value for the 250-CVE set. No patch-free experiment is reported for the real-world set. The abstract therefore either misattributes the ARVO result or announces an experiment that is absent from the evaluation. This must be corrected, and if the patch-free claim is meant for the CVE set, the experiment must be added.
  3. [§III-B1, Algorithm 1] The threshold MAX_ITER_MLM for slice expansion is set to three 'based on statistics from InterPVD [24] and ARVO [6]'. ARVO is one of the two evaluation datasets used in RQ1–RQ4. Choosing a pipeline hyperparameter from the evaluation distribution risks optimistic results, even if the effect is likely modest. The paper should either fix this threshold using only training or validation data, or report sensitivity of the main result to this parameter.
minor comments (5)
  1. [Throughout] There are numerous rendering artifacts and missing spaces, e.g., 'AProof-of-Vulnerability' in the abstract, 'viasemantic' and 'viaopen' in §I, and section headers such as 'V .' and 'F .'. A careful proofreading pass is needed.
  2. [Algorithm 3 and §IV] Algorithm 3 uses MAX_ITER_WALK, but its value is not specified; §IV says 'extract up to 200 candidate paths', so state explicitly whether MAX_ITER_WALK equals 200 or is a separate parameter.
  3. [Table V] The column header 'No S1 VulTrigger S1' is ambiguous; clarify that this setting replaces the fine-tuned MLM with VulTrigger as the localization step.
  4. [§V-C, Table IV] The 52-sample subset used for direct frontier-LLM comparison is selected by context-window fit; report how representative this subset is of the full 490-sample ARVO set (e.g., project size and CWE distribution) to allow assessment of selection bias.
  5. [§VI-B and Table VIII] The criteria for classifying a patch as 'incomplete' versus 'incorrect' are not defined; specify how the patched builds were obtained and how unrelated crashes were ruled out before labeling a patch as flawed.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: evaluation sets are disjoint from fine-tuning data, ARVO success is ground-truth validated, and no claim reduces to its inputs by construction.

full rationale

POVGEN's derivation chain is self-contained rather than circular. The fine-tuning data for the constraint models (CEM/CSM) are SV-COMP, Juliet, and four synthetic templates (§III-B2, §V-A), which contain no CVEs; the evaluation uses disjoint ARVO samples and 250 real-world CVEs with the 19 InterPVD-overlapping CVEs excluded (§V-A). End-to-end ARVO success is judged by matching the ground-truth sanitizer error type and crash location (§V-B), so the headline 78.98% is not defined as agreement with a fitted parameter. The SMT fallback (Algorithm 4, Lines 6-7) is an independent decision procedure and is ablated separately. The only load-bearing risk is interpretability, not circularity: RQ5 (Table VII) does not state the success criterion for CVEs lacking public PoVs, and the paper's internal-validity discussion (§VI-D) concedes that public CVEs may appear in pretraining corpora, offering base-model underperformance as a partial mitigation. Neither concern reduces a prediction to the model's training input by construction; both are external-validity questions. There are no load-bearing self-citations and no imported uniqueness theorem. Therefore no circular step is established.

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

The central claims rest on engineering hyperparameters and domain assumptions, not on new physical entities or derived constants. The main uncharged cost is the generalization assumption for the fine-tuned constraint models.

free parameters (5)
  • Slice expansion threshold (MAX_ITER_MLM) = 3
    Hand-chosen based on InterPVD/ARVO statistics; bounds MLM context and affects localization recall.
  • Maximum candidate paths extracted = 200
    Implementation cap in Step 2; success plateaus near 79% by about 50 paths, so 200 balances coverage and runtime but is a manually chosen bound.
  • Slicing depth for context functions = 3
    Set from prior empirical findings; affects slice completeness for localization.
  • Template placeholders {val} and {threshold} = random integers
    Random values in data augmentation; shape the constraint-solving training distribution.
  • Fine-tuning hyperparameters for MLM, CEM, CSM = not reported
    Learning rate, epochs, LoRA rank, and related settings are not reported, so the model artifacts cannot be exactly reproduced from the text alone.
assumptions (5)
  • domain assumption MLM's predicted manifestation point lies on a control-flow path that actually reaches the vulnerable behavior.
    Step 1 anchors all exploration; Table II shows patch-free recall drops to 62.65%, which the paper ties to the patch-free success drop.
  • domain assumption CEM-extracted SMT constraints faithfully represent path feasibility, so satisfying them yields inputs that reach the vulnerable state.
    Step 3 relies on these constraints; the SMT fallback only rescues constraints that are already correctly extracted.
  • domain assumption ARVO's pre-built environments and ground-truth PoVs faithfully reproduce the original OSS-Fuzz crashes.
    Success is measured by matching sanitizer error type and crash location against these ground-truth artifacts.
  • domain assumption The four synthetic templates plus SV-COMP and Juliet cover the control- and data-flow motifs needed for real-world C/C++ memory-safety constraint reasoning.
    CEM and CSM generalization rests on this distributional assumption; the paper motivates it in §III-B2.
  • standard math Z3 SMT solving is sound and complete for the generated constraint fragments (linear arithmetic, arrays, pointer offsets).
    The solver fallback assumes decidable, correctly encoded constraints.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Neuro-Symbolic Proof-of-Vulnerability Generation with Open-Weight Models." pith.science (2026). https://pith.science/paper/7ZQYK62E

@misc{pith2026260804217,
  author       = {Pith},
  title        = {Pith review of: Neuro-Symbolic Proof-of-Vulnerability Generation with Open-Weight Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/7ZQYK62E}},
  note         = {Machine review of arXiv:2608.04217}
}
read the original abstract

Software vulnerabilities are persistent, but validating them remains difficult: a Proof-of-Vulnerability (PoV) requires a concrete input that triggers the vulnerable behavior, yet public triggering inputs are often unavailable for disclosed vulnerabilities. Existing techniques make different tradeoffs in effectiveness, scalability, cost, and controllability, leaving room for complementary designs. To complement them, we present POVGEN, a low-cost neuro-symbolic framework that makes PoV generation cost-effective via semantic focusing and LLM-guided constraint reasoning using open-weight models. POVGEN first localizes vulnerability-relevant regions (utilizing patch information if available), then performs path-sensitive reachability analysis, and finally generates PoVs by extracting and solving constraints with LLM-guided reasoning backed by an SMT solver. POVGEN successfully generates PoVs for 78.98% of vulnerabilities in a recent benchmark, outperforming fuzzing (up to 50.20%) and symbolic execution (2.45%). On 250 real-world CVEs without public PoVs, it generates valid PoVs for 74.80% of cases and reproduces 65.1% when without patch information. The fine-tuned open-weight models match frontier commercial LLMs on key sub-tasks (i.e., the core constraint-reasoning steps) while running locally at no per-sample API cost. Applying the generated PoVs revealed six flawed patches in disclosed CVEs (all subsequently fixed) and five previously unreported vulnerabilities (of which four have been confirmed and fixed by the developers).

Figures

Figures reproduced from arXiv: 2608.04217 by the authors.

Figure 1
Figure 1. An example of patch (code diff at top) and sanitizer output (log at [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. An overview of POVGEN’s design, including its input, three main working phases (and steps), and output. Algorithm 1: Manifestation Localization Fine-Tuning Input: Df t: Localization fine-tuning samples Output: MLM: Manifestation Localization Model (MLM) 1 Function MLMFineTuning(Df t) 2 P rogs, P atches, MP s ← Df t 3 Slices ← []; 4 foreach (Pi, P ai) ∈ (P rogs, P atches) do 5 Si ← OnDemandSlicing(Pi, P ai); 6 Slices… view at source ↗
Figure 3
Figure 3. The templates used for data augmentation, where [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (2 more)
Figure 4
Figure 4. Figure 4: Distribution of #execution paths explored to generate success PoVs. #paths [PITH_FULL_IMAGE:figures/full_fig_p008_4.png]
Figure 6
Figure 6. Figure 6: Progression of success rate (y axis) achieved at increasing time cost in terms of hours spent (x axis). TABLE VII EFFECTIVENESS OF POVGEN ON REAL-WORLD CVES WITHOUT PUBLIC POVS (#SAMPLES IN PARENTHESES) CWE ID %Success CWE ID %Success CWE ID %Success CWE-119 (39) 66.67…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 45 canonical work pages

  1. [24]

    On the effectiveness of function-level vulnerability detectors for inter- procedural vulnerabilities,

    Z. Li, N. Wang, D. Zou, Y . Li, R. Zhang, S. Xu, C. Zhang, and H. Jin, “On the effectiveness of function-level vulnerability detectors for inter- procedural vulnerabilities,” inICSE, 2024

    work page 2024

  2. [6]

    ARVO: Atlas of reproducible vulnerabilities for open source software,

    X. Mei, P. S. Singaria, J. Del Castillo, H. Xi, T. Bao, R. Wang, Y . Shoshitaishvili, A. Doup´e, H. Pearce, B. Dolan-Gavittet al., “ARVO: Atlas of reproducible vulnerabilities for open source software,”arXiv preprint arXiv:2408.02153, 2024

    arXiv 2024

  3. [1]

    National vulnerability database (NVD) dashboard,

    NIST, “National vulnerability database (NVD) dashboard,” https:// nvd.nist.gov/general/nvd-dashboard, 2023

    work page 2023

  4. [2]

    Software vulnerability: Impact & ways to avoid it,

    Ericsson, “Software vulnerability: Impact & ways to avoid it,” https: //www.ericsson.com/en/security/vulnerability-management, 2023

    work page 2023

  5. [3]

    Examining zero-shot vulnerability repair with large language models,

    H. Pearce, B. Tan, B. Ahmad, R. Karri, and B. Dolan-Gavitt, “Examining zero-shot vulnerability repair with large language models,” inS&P, 2023

    work page 2023

  6. [4]

    Large language model for vulnerability detection and repair: Literature review and roadmap,

    X. Zhou, S. Cao, X. Sun, and D. Lo, “Large language model for vulnerability detection and repair: Literature review and roadmap,”arXiv preprint arXiv:2404.02525, 2024

    arXiv 2024

  7. [5]

    How effective are neural networks for fixing security vulnerabilities,

    Y . Wu, N. Jiang, H. V . Pham, T. Lutellier, J. Davis, L. Tan, P. Babkin, and S. Shah, “How effective are neural networks for fixing security vulnerabilities,” inISSTA, 2023

    work page 2023

  8. [7]

    A large-scale empirical study of security patches,

    F. Li and V . Paxson, “A large-scale empirical study of security patches,” inCCS, 2017

    work page 2017

Show all 50 references
  1. [8]

    Veribin: Adaptive verification of patches at the binary level

    H. Wu, J. Wu, R. Wu, A. Sharma, A. Machiry, and A. Bianchi, “Veribin: Adaptive verification of patches at the binary level.” inNDSS, 2025

    2025

  2. [9]

    The shrinking window for vulnerability exploitation: Why automated patching is critical,

    Jason Kikta, “The shrinking window for vulnerability exploitation: Why automated patching is critical,” https://www.automox.com/blog/why- automated-patching-is-critical, 2025

    2025

  3. [10]

    OSS-Fuzz-google’s continuous fuzzing service for open source software,

    K. Serebryany, “OSS-Fuzz-google’s continuous fuzzing service for open source software,” 2017

    2017

  4. [11]

    Driller: Augmenting fuzzing through selective symbolic execution,

    N. Stephens, J. Grosen, C. Salls, A. Dutcher, R. Wang, J. Corbetta, Y . Shoshitaishvili, C. Kruegel, and G. Vigna, “Driller: Augmenting fuzzing through selective symbolic execution,” inNDSS, 2017

    2017

  5. [12]

    KLEE: unassisted and auto- matic generation of high-coverage tests for complex systems programs

    C. Cadar, D. Dunbar, D. R. Engleret al., “KLEE: unassisted and auto- matic generation of high-coverage tests for complex systems programs.” inOSDI, 2008

    2008

  6. [13]

    PBAEG: combine-vulnerabilities aeg to defeat protection mechanisms,

    Y . Wang, Z. Li, and Y . Zhang, “PBAEG: combine-vulnerabilities aeg to defeat protection mechanisms,”Cybersecurity, 2025

    2025

  7. [14]

    FUGIO: Automatic exploit generation for PHP object injection vulnerabilities,

    S. Park, D. Kim, S. Jana, and S. Son, “FUGIO: Automatic exploit generation for PHP object injection vulnerabilities,” inUSENIX Security, 2022

    2022

  8. [15]

    Automated exploit generation for Node.js packages,

    F. Marques, M. Ferreira, A. Nascimento, M. E. Coimbra, N. Santos, L. Jia, and J. Fragoso Santos, “Automated exploit generation for Node.js packages,”PLDI, 2025

    2025

  9. [16]

    KOOBE: Towards facilitating exploit generation of kernel out-of-bounds write vulnerabilities,

    W. Chen, X. Zou, G. Li, and Z. Qian, “KOOBE: Towards facilitating exploit generation of kernel out-of-bounds write vulnerabilities,” in USENIX security, 2020

    2020

  10. [17]

    NA VEX: Precise and scalable exploit generation for dynamic web applications,

    A. Alhuzali, R. Gjomemo, B. Eshete, and V . Venkatakrishnan, “NA VEX: Precise and scalable exploit generation for dynamic web applications,” inUSENIX Security, 2018

    2018

  11. [18]

    PoCGen: Generating proof-of- concept exploits for vulnerabilities in npm packages,

    D. Simsek, A. Eghbali, and M. Pradel, “PoCGen: Generating proof-of- concept exploits for vulnerabilities in npm packages,”arXiv preprint arXiv:2506.04962, 2025

    2025 arXiv

  12. [19]

    Cottontail: Large language model-driven concolic execution for highly structured test input generation,

    H. Tu, S. Lee, Y . Li, P. Chen, L. Jiang, and M. B¨ohme, “Cottontail: Large language model-driven concolic execution for highly structured test input generation,” inProceedings of the IEEE Symposium on Security and Privacy (S&P). IEEE, 2026, pp. 1–19

    2026

  13. [20]

    Agentic concolic execution,

    Z. Luo, H. Zhao, D. Wolff, C. Cadar, and A. Roychoudhury, “Agentic concolic execution,” inProceedings of the IEEE Symposium on Security and Privacy (S&P), 2026, pp. 1–19

    2026

  14. [21]

    Large language model powered symbolic execution,

    Y . Li, R. Meng, and G. J. Duck, “Large language model powered symbolic execution,”OOPSLA, 2025

    2025

  15. [22]

    National Vul- nerability Database (NVD),

    National Institute of Standards and Technology (NIST), “National Vul- nerability Database (NVD),” https://nvd.nist.gov, 2025

    2025

  16. [23]

    The Exploit Database,

    OffSec, “The Exploit Database,” https://www.exploit-db.com/, 2025

    2025

  17. [25]

    Interprocedural slicing using dependence graphs,

    S. Horwitz, T. Reps, and D. Binkley, “Interprocedural slicing using dependence graphs,”TOPLAS, 1990

    1990

  18. [26]

    Program slicing in the era of large language models,

    K. K. Shahandashti, M. M. Mohajer, A. B. Belle, S. Wang, and H. Hemmati, “Program slicing in the era of large language models,” arXiv preprint arXiv:2409.12369, 2024

    2024 arXiv

  19. [27]

    A platform for robust analysis of c/c++ code,

    F. Yamaguchi, “A platform for robust analysis of c/c++ code,” https: //joern.readthedocs.io/en/latest/installation.html, 2022

    2022

  20. [28]

    SySeVR: A framework for using deep learning to detect software vulnerabilities,

    Z. Li, D. Zou, S. Xu, H. Jin, Y . Zhu, and Z. Chen, “SySeVR: A framework for using deep learning to detect software vulnerabilities,” TDSC, 2021

    2021

  21. [29]

    GLM-5.2: An open-weight large language model,

    Z.ai, “GLM-5.2: An open-weight large language model,” https:// huggingface.co/zai-org/GLM-5.2, 2026

    2026

  22. [30]

    A wrapper script to build whole-program llvm bitcode files,

    Tristan Ravitch, “A wrapper script to build whole-program llvm bitcode files,” https://github.com/travitch/whole-program-llvm, 2021

    2021

  23. [31]

    SVF: interprocedural static value-flow analysis in llvm,

    Y . Sui and J. Xue, “SVF: interprocedural static value-flow analysis in llvm,” inCC, 2016

    2016

  24. [32]

    Z3: An efficient smt solver,

    L. De Moura and N. Bjørner, “Z3: An efficient smt solver,” inTACAS, 2008

    2008

  25. [33]

    Unsloth,

    D. Han and M. Han, “Unsloth,” https://github.com/unslothai/unsloth, 2024

    2024

  26. [34]

    Software verification: 10th comparative evaluation (SV- COMP 2021),

    D. Beyer, “Software verification: 10th comparative evaluation (SV- COMP 2021),” inTACAS, 2021

    2021

  27. [35]

    P. E. Black,Juliet 1.3 test suite: Changes from 1.2. US Department of Commerce, National Institute of Standards and Technology, 2018

    2018

  28. [36]

    W. G. Cochran,Sampling Techniques, 3rd ed. Wiley, 1977

    1977

  29. [37]

    Continuous fuzzing with libfuzzer and addresssanitizer,

    K. Serebryany, “Continuous fuzzing with libfuzzer and addresssanitizer,” inSecDev, 2016

    2016

  30. [38]

    AFL++: Combining incremental steps of fuzzing research,

    A. Fioraldi, D. Maier, H. Eißfeldt, and M. Heuse, “AFL++: Combining incremental steps of fuzzing research,” inWOOT, 2020

    2020

  31. [39]

    Directed greybox fuzzing,

    M. B ¨ohme, V .-T. Pham, M.-D. Nguyen, and A. Roychoudhury, “Directed greybox fuzzing,” inCCS, 2017

    2017

  32. [40]

    SAGE: whitebox fuzzing for security testing,

    P. Godefroid, M. Y . Levin, and D. Molnar, “SAGE: whitebox fuzzing for security testing,”Communication of ACM, 2012

    2012

  33. [41]

    American fuzzy lop (AFL) fuzzer,

    M. Zalewski, “American fuzzy lop (AFL) fuzzer,” https: //lcamtuf.coredump.cx/afl, 2017

    2017

  34. [42]

    Automatic patch- based exploit generation is possible: Techniques and implications,

    D. Brumley, P. Poosankam, D. Song, and J. Zheng, “Automatic patch- based exploit generation is possible: Techniques and implications,” in S&P, 2008

    2008

  35. [43]

    Learning to fuzz from symbolic execution with application to smart contracts,

    J. He, M. Balunovi ´c, N. Ambroladze, P. Tsankov, and M. Vechev, “Learning to fuzz from symbolic execution with application to smart contracts,” inCCS, 2019

    2019

  36. [44]

    Symbolic execution with test cases generated by large language models,

    J. Xu, J. Xu, T. Chen, and X. Ma, “Symbolic execution with test cases generated by large language models,” in2024 IEEE 24th International Conference on Software Quality, Reliability and Security (QRS). IEEE, 2024, pp. 228–237

    2024

  37. [45]

    SymGPT: Auditing smart contracts via combining symbolic execution with large language models,

    S. Xia, M. He, S. Shao, T. Yu, Y . Zhang, and L. Song, “SymGPT: Auditing smart contracts via combining symbolic execution with large language models,”arXiv preprint arXiv:2502.07644, 2025

    2025

  38. [46]

    Faultline: Automated proof-of-vulnerability generation using llm agents,

    V . Nitin, B. Ray, and R. Z. Moghaddam, “Faultline: Automated proof-of-vulnerability generation using llm agents,”arXiv preprint arXiv:2507.15241, 2025

    2025 arXiv

  39. [47]

    PwnGPT: Automatic exploit generation based on large language models,

    W. Peng, L. Ye, X. Du, H. Zhang, D. Zhan, Y . Zhang, Y . Guo, and C. Zhang, “PwnGPT: Automatic exploit generation based on large language models,” inACL, 2025

    2025

  40. [48]

    PentestGPT: Evaluating and harnessing large language models for automated penetration testing,

    G. Deng, Y . Liu, V . Mayoral-Vilches, P. Liu, Y . Li, Y . Xu, T. Zhang, Y . Liu, M. Pinzger, and S. Rass, “PentestGPT: Evaluating and harnessing large language models for automated penetration testing,” inUSENIX Security, 2024

    2024

  41. [49]

    Gollum: Modular and greybox exploit generation for heap overflows in interpreters,

    S. Heelan, T. Melham, and D. Kroening, “Gollum: Modular and greybox exploit generation for heap overflows in interpreters,” inCCS, 2019

    2019

  42. [50]

    AAHEG: Automatic advanced heap exploit generation based on abstract syntax tree,

    Y . Wang, Y . Zhang, and Z. Li, “AAHEG: Automatic advanced heap exploit generation based on abstract syntax tree,”Symmetry, 2023. 11

    2023

Pith tools

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