pith. sign in

arxiv: 2604.04102 · v1 · submitted 2026-04-05 · 💻 cs.CR · cs.SE

Triggering and Detecting Exploitable Library Vulnerability from the Client by Directed Greybox Fuzzing

Pith reviewed 2026-05-13 16:52 UTC · model grok-4.3

classification 💻 cs.CR cs.SE
keywords directed greybox fuzzinglibrary vulnerabilityclient-side exploitationabstract path mappingrisk-based mutationfuzz testingvulnerability detectionexploitability
0
0 comments X

The pith

LiveFuzz extends directed greybox fuzzing with target tuples to trigger exploitable library vulnerabilities from client programs without proof-of-concepts.

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

The paper introduces LiveFuzz to detect when third-party library vulnerabilities can be reached and triggered through client code. Existing fuzzing methods need unavailable proof-of-concept examples, so LiveFuzz supplies a target tuple that marks the vulnerable library location and guides the search across the client-library boundary. It adds an Abstract Path Mapping step that projects full execution traces to avoid favoring short paths, plus risk-based adaptive mutation that limits wasteful changes. On a dataset of 61 real cases, LiveFuzz reaches more target paths and exposes vulnerabilities faster than prior directed greybox tools, uniquely triggering three of them.

Core claim

LiveFuzz extends directed greybox fuzzing to cross-program scenarios by supplying a target tuple that identifies the vulnerable library code. The Abstract Path Mapping mechanism projects execution paths from client entry points to the target, removing the bias toward shorter paths, while risk-based adaptive mutation focuses mutations according to estimated risk. This combination triggers and detects exploitable library vulnerabilities from client programs without any proof-of-concept, yielding more reachable target paths and faster exposure times than baselines on 61 cases.

What carries the argument

Target tuple plus Abstract Path Mapping, which projects client and library execution paths to direct fuzzing across program boundaries.

If this is right

  • LiveFuzz reaches more target-reachable paths than standard directed greybox fuzzing baselines.
  • It reduces the average time needed to expose vulnerabilities during testing.
  • Three vulnerabilities in the dataset are triggered only by LiveFuzz and missed by all compared tools.
  • Library vulnerabilities can be assessed for client-side exploitability even when no proof-of-concept code exists.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • Security scanners could generate target tuples automatically from vulnerability databases to enable routine client-side checks.
  • The same path-projection idea could apply to fuzzing interactions between plugins and host applications or between services in distributed systems.
  • Routine use would lower dependence on manual creation of proof-of-concept exploits for library security reviews.

Load-bearing premise

The target tuple supplied to LiveFuzz correctly identifies the vulnerable code location inside the library when only client-side entry points are available.

What would settle it

If LiveFuzz is run on the 61-case dataset with correct target tuples yet fails to increase reachable paths or uniquely trigger the three reported vulnerabilities compared with baselines, the central effectiveness claim is falsified.

Figures

Figures reproduced from arXiv: 2604.04102 by Menghan Wu, Meng Luo, Shaohua Wang, Xing Hu, Xin Xia, Yukai Zhao.

Figure 1
Figure 1. Figure 1: Example is a library vulnerability that is exploitable with [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: The Overall of LiveFuzz. Module A is Section 3.1, Module B is Section 3.2, and Module C is Section 3.3.2. 2.2 Fuzzing Fuzzing [44] is a widely used technique in software testing [40]. Generally, a fuzzer generates test cases through mutation or other techniques to test programs and saves valuable test cases as seeds for subsequent mutations. Building on this, Böhme et al. propose directed greybox fuzzing [… view at source ↗
Figure 3
Figure 3. Figure 3: The Details of the Dataset [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: The Static Analysis Time (s) for Different Cases. [PITH_FULL_IMAGE:figures/full_fig_p008_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Extracting information from the vulnerability de [PITH_FULL_IMAGE:figures/full_fig_p009_5.png] view at source ↗
read the original abstract

Developers utilize third-party libraries to improve productivity, which also introduces potential security risks. Existing approaches generate tests for public functions to trigger library vulnerabilities from client programs, yet they depend on proof-of-concepts (PoCs), which are often unavailable. In this paper, we propose a new approach, LiveFuzz, based on directed greybox fuzzing (DGF) to detect the exploitability of library vulnerabilities from client programs without PoCs. LiveFuzz exploits a target tuple to extend existing DGF techniques to cross-program scenarios. Based on the target tuple, LiveFuzz introduces a novel Abstract Path Mapping mechanism to project execution paths, mitigating the preference for shorter paths. LiveFuzz also proposes a risk-based adaptive mutation to mitigate excessive mutation. To evaluate LiveFuzz, we construct a new dataset including 61 cases of library vulnerabilities exploited from client programs. Results show that LiveFuzz increases the number of target-reachable paths compared with all baselines and improves the average speed of vulnerability exposure. Three vulnerabilities are triggered exclusively by LiveFuzz.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 1 minor

Summary. The paper proposes LiveFuzz, a directed greybox fuzzing technique for triggering and detecting exploitable library vulnerabilities from client programs without proof-of-concepts. It extends DGF via a target tuple for cross-program scenarios, introduces Abstract Path Mapping to handle path projection and mitigate short-path bias, and uses risk-based adaptive mutation. Evaluation on a constructed dataset of 61 library vulnerability cases shows LiveFuzz increases target-reachable paths over baselines, improves average vulnerability exposure speed, and exclusively triggers three vulnerabilities.

Significance. If the central claims hold under realistic target-tuple construction, the work would provide a practical advance in automated detection of library-client vulnerability chains, addressing a gap where PoCs are unavailable. The new 61-case dataset is a useful contribution for future benchmarking in cross-program fuzzing.

major comments (2)
  1. [Abstract] Abstract and approach section: The central claim that LiveFuzz operates without PoCs rests on the target tuple accurately directing cross-program DGF from client entry points alone. However, the description does not specify a mechanism for deriving the tuple (e.g., vulnerable function or basic block inside the library) when only client-side information is available; if tuple construction implicitly requires the exact vulnerable location, the no-PoC premise does not hold and reported gains may not generalize.
  2. [Evaluation] Evaluation section: The reported improvements (increased reachable paths and faster exposure on 61 cases, plus three exclusive triggers) are presented without details on target-tuple construction rules per case, data exclusion criteria, or statistical tests against baselines; this makes it impossible to assess whether the gains are robust or dependent on oracle-like target knowledge.
minor comments (1)
  1. [Approach] The Abstract Path Mapping mechanism is described at a high level; a concrete example or pseudocode would clarify how path projection avoids short-path preference in cross-program settings.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive comments, which help clarify key aspects of target-tuple construction and evaluation robustness. We address each major comment below and will revise the manuscript to incorporate additional details on tuple derivation and statistical analysis.

read point-by-point responses
  1. Referee: [Abstract] Abstract and approach section: The central claim that LiveFuzz operates without PoCs rests on the target tuple accurately directing cross-program DGF from client entry points alone. However, the description does not specify a mechanism for deriving the tuple (e.g., vulnerable function or basic block inside the library) when only client-side information is available; if tuple construction implicitly requires the exact vulnerable location, the no-PoC premise does not hold and reported gains may not generalize.

    Authors: The target tuple is defined as a pair consisting of a client entry point (obtainable via static call-graph analysis of the client program) and a library target location (e.g., the vulnerable function or basic block). Such locations can be sourced from public vulnerability databases (CVEs, NVD) or lightweight static analysis of the library binary without any PoC or exploit code. The no-PoC premise holds because the fuzzing process itself does not require an existing exploit; the tuple merely provides directional guidance. We will add a dedicated paragraph in the approach section and a table in the evaluation appendix enumerating, for each of the 61 cases, the exact sources used to construct the tuple (e.g., CVE-reported function names). This revision will demonstrate that the technique generalizes beyond oracle knowledge. revision: yes

  2. Referee: [Evaluation] Evaluation section: The reported improvements (increased reachable paths and faster exposure on 61 cases, plus three exclusive triggers) are presented without details on target-tuple construction rules per case, data exclusion criteria, or statistical tests against baselines; this makes it impossible to assess whether the gains are robust or dependent on oracle-like target knowledge.

    Authors: We agree that additional transparency is required. In the revised manuscript we will (1) include an appendix listing the precise target-tuple construction rule applied to every case (primarily CVE function names cross-referenced with client call sites), (2) state the exclusion criteria (cases were retained only when the library was dynamically linked and the target location was reachable via at least one public API), and (3) add Wilcoxon signed-rank tests with effect sizes for the reachable-path and time-to-exposure metrics. These additions will allow readers to verify that the reported gains do not rely on unrealistically precise oracle information. revision: yes

Circularity Check

0 steps flagged

No significant circularity; empirical claims rest on independent dataset and standard DGF extensions

full rationale

The paper introduces LiveFuzz by extending directed greybox fuzzing with a provided target tuple, Abstract Path Mapping for path projection, and risk-based adaptive mutation. Evaluation uses a separately constructed dataset of 61 library vulnerability cases from client programs, reporting higher target-reachable paths, faster exposure, and three unique triggers versus baselines. No equations, self-definitional reductions, fitted inputs renamed as predictions, or load-bearing self-citations appear in the derivation chain. The target tuple is treated as an explicit input rather than derived circularly, and results are not forced by construction from prior author work.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The approach assumes a correctly supplied target tuple that marks the vulnerable site across client and library boundaries; no free parameters are explicitly fitted in the abstract, and no new entities are postulated.

axioms (1)
  • domain assumption A target tuple can be defined that identifies the vulnerable code location inside the library from client-side execution traces.
    Invoked when extending DGF to cross-program scenarios; the entire guidance mechanism rests on this tuple being accurate.

pith-pipeline@v0.9.0 · 5497 in / 1338 out tokens · 49249 ms · 2026-05-13T16:52:44.244111+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

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

  1. FIKA: Expanding Dependency Reachability with Executability Guarantees

    cs.SE 2026-04 unverdicted novelty 6.0

    FIKA dynamically executes generated tests to prove executability of 2363 dependency call sites across eight Java projects, raising average coverage from 54% to 74% and strengthening Semgrep vulnerability reachability results.

Reference graph

Works this paper leans on

69 extracted references · 69 canonical work pages · cited by 1 Pith paper

  1. [1]

    2011. LDD. https://web.archive.org/web/20220506230318/https://linux.die.net/ man/1/ldd. Last accessed Mar. 2025

  2. [2]

    2017. libtiff. https://gitlab.com/libtiff/libtiff. Last accessed Mar. 2025

  3. [3]

    fuzzing-corpus

    2019. fuzzing-corpus. https://github.com/strongcourage/fuzzing-corpus. Last accessed Mar. 2025

  4. [4]

    Google Security Blog: Understanding the Impact of Apache Log4j Vul- nerability

    2021. Google Security Blog: Understanding the Impact of Apache Log4j Vul- nerability. https://security.googleblog.com/2021/12/understanding-impact-of- apache-log4j.html. Last accessed Mar. 2025

  5. [5]

    Official Common Platform Enumeration (CPE) Dictionary

    2022. Official Common Platform Enumeration (CPE) Dictionary. https://nvd.nist. gov/products/cpe. Last accessed Mar. 2025

  6. [6]

    GitHub REST API documentation

    2025. GitHub REST API documentation. https://docs.github.com/en/rest/. Last accessed Mar. 2025

  7. [7]

    NATIONAL VULNERABILITY DATABASE

    2025. NATIONAL VULNERABILITY DATABASE. https://nvd.nist.gov/. Last accessed Mar. 2025

  8. [8]

    Hervé Abdi. 2010. Coefficient of variation.Encyclopedia of research design1, 5 (2010), 169–171

  9. [10]

    Jinsheng Ba, Marcel Böhme, Zahra Mirzamomen, and Abhik Roychoudhury. 2022. Stateful greybox fuzzing. In31st USENIX Security Symposium (USENIX Security 22). 3255–3272

  10. [11]

    Masudul Hasan Masud Bhuiyan, Adithya Srinivas Parthasarathy, Nikos Vasilakis, Michael Pradel, and Cristian-Alexandru Staicu. 2023. SecBench. js: An executable security benchmark suite for server-side JavaScript. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 1059–1070

  11. [12]

    Christopher Bogart, Christian Kästner, James Herbsleb, and Ferdian Thung. 2016. How to break an API: cost negotiation and community values in three software ecosystems. InProceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering. 109–120

  12. [13]

    Marcel Böhme, Van-Thuan Pham, Manh-Dung Nguyen, and Abhik Roychoudhury

  13. [14]

    InProceedings of the 2017 ACM SIGSAC conference on computer and communications security

    Directed greybox fuzzing. InProceedings of the 2017 ACM SIGSAC conference on computer and communications security. 2329–2344

  14. [15]

    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. 2095–2108

  15. [16]

    Zirui Chen, Xing Hu, Xin Xia, Yi Gao, Tongtong Xu, David Lo, and Xiaohu Yang

  16. [17]

    InProceedings of the IEEE/ACM 46th International Conference on Software Engineering

    Exploiting Library Vulnerability via Migration Based Automating Test Generation. InProceedings of the IEEE/ACM 46th International Conference on Software Engineering. 1–12

  17. [18]

    Alexandre Decan, Tom Mens, and Eleni Constantinou. 2018. On the impact of security vulnerabilities in the npm package dependency network. InProceedings of the 15th international conference on mining software repositories. 181–191

  18. [19]

    Peng Deng, Lei Zhang, Yuchuan Meng, Zhemin Yang, Yuan Zhang, and Min Yang. [n. d.]. CHAINFUZZ: Exploiting Upstream Vulnerabilities in Open-Source Supply Chains. ([n. d.])

  19. [20]

    Zhengjie Du, Yuekang Li, Yang Liu, and Bing Mao. 2022. Windranger: A di- rected greybox fuzzer driven by deviation basic blocks. InProceedings of the 44th International Conference on Software Engineering. 2440–2451

  20. [21]

    William Enck and Laurie Williams. 2022. Top five challenges in software supply chain security: Observations from 30 industry and government organizations. IEEE Security & Privacy20, 2 (2022), 96–100

  21. [22]

    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. 1656–1668

  22. [23]

    Karine Even-Mendoza, Arindam Sharma, Alastair F Donaldson, and Cristian Cadar. 2023. GrayC: Greybox fuzzing of compilers and analysers for C. In Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1219–1231

  23. [24]

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020. {AFL++}: Combining incremental steps of fuzzing research. In14th USENIX Workshop on Offensive Technologies (WOOT 20)

  24. [25]

    Darius Foo, Jason Yeo, Hao Xiao, and Asankhaya Sharma. 2019. The dynamics of software composition analysis.arXiv preprint arXiv:1909.00973(2019)

  25. [26]

    Peter E Hart, Nils J Nilsson, and Bertram Raphael. 1968. A formal basis for the heuristic determination of minimum cost paths.IEEE transactions on Systems Science and Cybernetics4, 2 (1968), 100–107

  26. [27]

    Raphael Hiesgen, Marcin Nawrocki, Thomas C Schmidt, and Matthias Wählisch

  27. [28]

    The race to the vulnerable: Measuring the log4j shell incident.arXiv preprint arXiv:2205.02544(2022)

  28. [29]

    Allen D Householder, Jeff Chrabaszcz, Trent Novelly, David Warren, and Jonathan M Spring. 2020. Historical analysis of exploit availability timelines. In 13th USENIX Workshop on Cyber Security Experimentation and Test (CSET 20). Conference’17, July 2017, Washington, DC, USA Yukai Zhao, Menghan Wu, Xing Hu, Shaohua Wang, Meng Luo, and Xin Xia

  29. [30]

    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). IEEE, 36–50

  30. [31]

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

  31. [32]

    InProceedings of the 2024 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA

    Titan: Efficient Multi-target Directed Greybox Fuzzing. InProceedings of the 2024 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA. 20–22

  32. [33]

    Hong Jin Kang, Truong Giang Nguyen, Bach Le, Corina S Păsăreanu, and David Lo. 2022. Test mimicry to assess the exploitability of library vulnerabilities. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis. 276–288

  33. [34]

    Tae Eun Kim, Jaeseung Choi, Kihong Heo, and Sang Kil Cha. 2023. {DAFL}: Directed Grey-box Fuzzing guided by Data Dependency. In32nd USENIX Security Symposium (USENIX Security 23). 4931–4948

  34. [35]

    Tae Eun Kim, Jaeseung Choi, Seongjae Im, Kihong Heo, and Sang Kil Cha. 2024. Evaluating directed fuzzers: Are we heading in the right direction?Proceedings of the ACM on Software Engineering1, FSE (2024), 316–337

  35. [36]

    Isabella Laybourn, Vasudev Vikram, Rafaello Sanna, Ao Li, and Rohan Padhye

  36. [37]

    Guiding greybox fuzzing with mutation testing. (2022)

  37. [38]

    Gwangmu Lee, Woochul Shim, and Byoungyoung Lee. 2021. Constraint-guided directed greybox fuzzing. In30th USENIX Security Symposium (USENIX Security 21). 3559–3576

  38. [39]

    Myungho Lee, Sooyoung Cha, and Hakjoo Oh. 2023. Learning seed-adaptive mutation strategies for greybox fuzzing. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 384–396

  39. [40]

    Penghui Li, Wei Meng, and Chao Zhang. 2024. SDFuzz: Target States Driven Directed Fuzzing. InProceedings of the 33rd USENIX Security Symposium (Security). Philadelphia, PA, USA

  40. [41]

    Hongliang Liang, Yini Zhang, Yue Yu, Zhuosi Xie, and Lin Jiang. 2019. Sequence coverage directed greybox fuzzing. In2019 IEEE/ACM 27th International Confer- ence on Program Comprehension (ICPC). IEEE Computer Society, 249–259

  41. [42]

    Jie Liang, Yu Jiang, Mingzhe Wang, Xun Jiao, Yuanliang Chen, Houbing Song, and Kim-Kwang Raymond Choo. 2019. Deepfuzzer: Accelerated deep greybox fuzzing.IEEE Transactions on Dependable and Secure Computing18, 6 (2019), 2675–2688

  42. [43]

    Changhua Luo, Wei Meng, and Penghui Li. 2023. Selectfuzz: Efficient directed fuzzing with selective path exploration. In2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2693–2707

  43. [44]

    Chenyang Lyu, Shouling Ji, Chao Zhang, Yuwei Li, Wei-Han Lee, Yu Song, and Raheem Beyah. 2019. {MOPT}: Optimized mutation scheduling for fuzzers. In 28th USENIX security symposium (USENIX security 19). 1949–1966

  44. [45]

    Valentin JM Manès, HyungSeok Han, Choongwoo Han, Sang Kil Cha, Manuel Egele, Edward J Schwartz, and Maverick Woo. 2019. The art, science, and engi- neering of fuzzing: A survey.IEEE Transactions on Software Engineering47, 11 (2019), 2312–2331

  45. [46]

    Patrick E McKnight and Julius Najab. 2010. Mann-Whitney U Test.The Corsini encyclopedia of psychology(2010), 1–1

  46. [49]

    Ruijie Meng, Zhen Dong, Jialin Li, Ivan Beschastnikh, and Abhik Roychoudhury

  47. [50]

    InProceedings of the 44th International Conference on Software Engineering

    Linear-time temporal logic guided greybox fuzzing. InProceedings of the 44th International Conference on Software Engineering. 1343–1355

  48. [51]

    Barton P Miller, Lars Fredriksen, and Bryan So. 1990. An empirical study of the reliability of UNIX utilities.Commun. ACM33, 12 (1990), 32–44

  49. [52]

    Samim Mirhosseini and Chris Parnin. 2017. Can automated pull requests en- courage software developers to upgrade out-of-date dependencies?. In2017 32nd IEEE/ACM international conference on automated software engineering (ASE). IEEE, 84–94

  50. [53]

    Aniruddhan Murali, Noble Mathews, Mahmoud Alfadel, Meiyappan Nagappan, and Meng Xu. 2024. Fuzzslice: Pruning false positives in static analysis warnings through function-level fuzzing. InProceedings of the 46th IEEE/ACM International Conference on Software Engineering. 1–13

  51. [54]

    Manh-Dung Nguyen, Sébastien Bardin, Richard Bonichon, Roland Groz, and Matthieu Lemerre. 2020. Binary-level directed fuzzing for {use-after-free} vul- nerabilities. In23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020). 47–62

  52. [55]

    Sebastian Österlund, Kaveh Razavi, Herbert Bos, and Cristiano Giuffrida. 2020. {ParmeSan}: Sanitizer-guided greybox fuzzing. In29th USENIX Security Sympo- sium (USENIX Security 20). 2289–2306

  53. [56]

    Jiaqi Peng, Feng Li, Bingchang Liu, Lili Xu, Binghong Liu, Kai Chen, and Wei Huo. 2019. 1dvul: Discovering 1-day vulnerabilities through binary patches. In 2019 49th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN). IEEE, 605–616

  54. [57]

    Serena Elisa Ponta, Henrik Plate, and Antonino Sabetta. 2020. Detection, assess- ment and mitigation of vulnerabilities in open source dependencies.Empirical Software Engineering25, 5 (2020), 3175–3215

  55. [58]

    Bonan Ruan, Jiahao Liu, Weibo Zhao, and Zhenkai Liang. 2024. VulZoo: A Comprehensive Vulnerability Intelligence Dataset. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 2334– 2337

  56. [59]

    Kostya Serebryany. 2017. {OSS-Fuzz}-Google’s continuous fuzzing service for open source software. (2017)

  57. [60]

    Deniz Simsek, Aryaz Eghbali, and Michael Pradel. 2025. PoCGen: Generating Proof-of-Concept Exploits for Vulnerabilities in Npm Packages.arXiv preprint arXiv:2506.04962(2025)

  58. [61]

    Prashast Srivastava, Stefan Nagy, Matthew Hicks, Antonio Bianchi, and Mathias Payer. 2022. One fuzz doesn’t fit all: Optimizing directed fuzzing via target- tailored program state restriction. InProceedings of the 38th Annual Computer Security Applications Conference. 388–399

  59. [62]

    Yulei Sui and Jingling Xue. 2016. SVF: interprocedural static value-flow analysis in LLVM. InProceedings of the 25th international conference on compiler construction. 265–266

  60. [63]

    Yulei Sui, Ding Ye, and Jingling Xue. 2014. Detecting memory leaks statically with full-sparse value-flow analysis.IEEE Transactions on Software Engineering 40, 2 (2014), 107–122

  61. [64]

    Wei Tang, Zhengzi Xu, Chengwei Liu, Jiahui Wu, Shouguo Yang, Yi Li, Ping Luo, and Yang Liu. 2022. Towards understanding third-party library dependency in c/c++ ecosystem. InProceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering. 1–12

  62. [65]

    Ying Wang, Bihuan Chen, Kaifeng Huang, Bowen Shi, Congying Xu, Xin Peng, Yijian Wu, and Yang Liu. 2020. An empirical study of usages, updates and risks of third-party libraries in java projects. In2020 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 35–45

  63. [66]

    Tingke Wen, Yuwei Li, Lu Zhang, Huimin Ma, and Zulie Pan. 2024. An Empirical Study on the Distance Metric in Guiding Directed Grey-box Fuzzing. In2024 IEEE 35th International Symposium on Software Reliability Engineering (ISSRE). IEEE, 307–318

  64. [67]

    Jiahui Wu, Zhengzi Xu, Wei Tang, Lyuye Zhang, Yueming Wu, Chengyue Liu, Kairan Sun, Lida Zhao, and Yang Liu. 2023. Ossfp: Precise and scalable c/c++ third-party library detection using fingerprinting functions. In2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). IEEE, 270–282

  65. [68]

    Hanxiang Xu, Yanjie Zhao, and Haoyu Wang. 2025. Directed Greybox Fuzzing via Large Language Model.arXiv preprint arXiv:2505.03425(2025)

  66. [69]

    Xian Zhan, Tianming Liu, Lingling Fan, Li Li, Sen Chen, Xiapu Luo, and Yang Liu. 2021. Research on third-party libraries in android apps: A taxonomy and systematic literature review.IEEE Transactions on Software Engineering48, 10 (2021), 4181–4213

  67. [70]

    Yujian Zhang, Yaokun Liu, Jinyu Xu, and Yanhao Wang. 2023. Predecessor-aware Directed Greybox Fuzzing. In2024 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society, 40–40

  68. [71]

    Lida Zhao, Sen Chen, Zhengzi Xu, Chengwei Liu, Lyuye Zhang, Jiahui Wu, Jun Sun, and Yang Liu. 2023. Software composition analysis for vulnerability detection: An empirical study on Java projects. InProceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering. 960–972

  69. [72]

    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. InProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering. 1633–1644