Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair

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

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

Pith's one-line read A robustly orchestrated ensemble of LLM agents can continuously repair fuzzing-discovered vulnerabilities, achieving a 72.1% success rate in a live competition.

desk verdict PatchIsland has a genuinely strong externally validated AIxCC result, but the internal 84/92 benchmark table does not add up, so the paper needs major revision before it can be trusted. read the letter →

arxiv 2601.17471 v2 pith:AZ63O7XC submitted 2026-01-24 cs.CR

Wonyoung Kim , Seunggi Min , Minjae Gwon , Dowoo Baik , Haein Lee , Hyeon Heo , Minjae Lee , Min Woo Baek
show 6 more authors
Yonghwi Jin Younggi Park Yunjae Choi Taesoo Kim Sangdon Park Insu Yun
This is my paper · ORCID
classification cs.CR
keywords automatedvulnerabilityrepaircontinuousfuzzingLLMagentsensembleorchestrationcrashdeduplicationpatchvalidationzero-dayAIxCC
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

The paper argues that automated vulnerability repair must move from static single-run benchmarks into continuous fuzzing pipelines, where crashes arrive at scale and systems must keep running for days. To do this it introduces PatchIsland, a coordinator-worker system that runs a diverse ensemble of LLM-based repair agents, deduplicates both crashes and patch candidates, and schedules agents to balance speed, cost, and provider rate limits. In an in-house evaluation on a 92-vulnerability benchmark drawn from the official competition dataset, PatchIsland produced plausible patches for 84 vulnerabilities, and in the fully autonomous competition final it produced 31 accepted patches for 43 confirmed vulnerabilities (72.1%). The authors further report that one of its patches for a real zero-day bug in the pdfbox library exactly matched the patch eventually merged by the project maintainer.

What carries the argument

The carrying mechanism is the ensemble of LLM agents: multiple independent patch generators with different workflows and models run in parallel, so a single agent's failure does not stall repair. Two supporting mechanisms make the ensemble practical: two-phase deduplication, which re-runs new crashes against existing patches to identify duplicates and merges new patches that subsume older ones; and FP2 orchestration, which runs high-preference agents first, keeps agents from the same LLM provider off different workers to avoid throttling, and takes the first plausible patch (FCFS). The Crete framework standardizes build, test, and fault-localization infrastructure across agents and caches ex

What would settle it

Manually review all 84 internally 'repaired' patches from the 92-vulnerability benchmark against the ground-truth patches and classify each as semantically correct or symptom-suppressing; if more than a handful are incorrect (as the paper's own postmortem found for 10 of 14 unintended-vulnerability patches), the core claim of a 91.3% repair rate collapses to a much lower correct-repair rate. For the competition result, re-run the same manual review on the 31 accepted patches and check each against the actual root cause.

Watch

Extended reading notes

Core claim

The central claim is that continuous vulnerability repair is feasible when multiple LLM agents are orchestrated into a robust, always-on system. PatchIsland embodies this: an ensemble of diverse agents explores different repair strategies and covers for each other's failures; a two-phase patch-based deduplication groups crashes by root cause and merges partial patches; and an FCFS/preference/provider-aware scheduler keeps the system efficient across providers. The paper's evidence is the 91.3% plausible-patch rate on 92 internal benchmark vulnerabilities and the 72.1% officially validated repair rate (31 of 43) in the competition final, including a patch identical to the maintainer's fix for

Load-bearing premise

The system's measured repair success rests on the assumption that a patch which compiles, prevents the proof-of-vulnerability from reproducing, and passes the included functional tests is a genuine repair; for vulnerabilities with sparse functional tests this assumption demonstrably fails, so the headline rates may overstate correct repairs.

Editorial extensions

If this is right

  • Plausible-patch repair becomes a drop-in stage between continuous fuzzing and the bug tracker.
  • Ensemble diversity plus simple scheduling makes the system resilient to agent-level failures and provider rate limits.
  • Patch-based deduplication can reduce redundant crash-triage and patch-submission effort in existing fuzzing pipelines.
  • The gap between plausible and semantically correct patches (10 of 14 on unintended vulnerabilities) underscores that functional tests and manual review remain essential.

Reading between the lines

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

  • The 84/92 internal result should be read as a plausible-patch rate; if the correctness rate observed on unintended vulnerabilities (4/14) applied more broadly, the true repair rate would be substantially lower.
  • The design suggests that AVR evaluation needs to incorporate semantic validation, either via human review or via richer test oracles, before claiming real-world repair capability.
  • The same ensemble-plus-deduplication pattern may transfer to other high-volume, noise-prone automation tasks, such as continuous issue triage or dependency-failure repair.
  • Cost and resource usage remain significant (the paper concedes higher cost than baselines), so practical deployment would require budget controls or cheaper fallback agents.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

Summary. PatchIsland is a continuous vulnerability repair (CVR) system that orchestrates multiple LLM agents in a fuzzing pipeline. It introduces an ensemble-of-agents design, two-phase patch-based deduplication, and an FP2 (FCFS, Preference-based, Provider-aware) orchestration layer. The paper evaluates the system internally on 92 AIxCC vulnerabilities, claiming 84/92 repaired and a 29.3% improvement over the Buttercup baseline, and reports results from the official AIxCC final competition, where PatchIsland generated 31 verified patches out of 43 vulnerabilities (72.1%). The authors also present a postmortem analysis of the competition, including a 0-day pdfbox patch identical to the maintainer's fix.

Significance. If the results hold, PatchIsland is a meaningful step toward practical, fully autonomous vulnerability repair in continuous fuzzing settings. The official AIxCC final result (31/43, manually validated by organizers) is a strong external validation, and the reported pdfbox 0-day patch matching the upstream fix demonstrates real-world impact. The paper's system-design contributions — ensemble orchestration, two-phase deduplication, and a reusable agent framework — are relevant to the security/systems community. However, the internal evaluation table contains serious arithmetic inconsistencies, and the absence of released artifacts prevents independent verification of the headline internal numbers.

major comments (4)
  1. [§6.1, Table 3] Table 3, the sole support for the abstract's '84 of 92' and the 'outperforms Buttercup by 29.3%' claim, is internally inconsistent. Summing the PatchIsland column across the 17 rows gives 57, not 84; the Buttercup column sums to 84; the RoboDuck column sums to 24, yet the text states RoboDuck and Buttercup patched 57 and 16. Many percentages are attached to the wrong fractions (e.g., Buttercup 10/11 shown as 63.6% instead of 90.9%; freerdp 5/5 shown as 40.0% instead of 100%). This appears to be a column/percentage swap, but as printed the table is not auditable. The authors must provide a corrected table and a per-PoV outcome matrix (or release logs) to support the headline internal result.
  2. [§6.1 vs §7] The manuscript conflates 'plausible patch' and 'correct patch' in its headline claims. The internal evaluation (Table 3, §6.1) counts a vulnerability as 'repaired' if the patch compiles, suppresses the PoV, and passes functional tests (§3.1), i.e., plausibility. The postmortem (§7) shows that for the 33 distinct intended vulnerabilities, only 27 were correct after manual review, and for unintended vulnerabilities 10 of 14 plausible patches were incorrect. The abstract and introduction should explicitly state that 84/92 is a plausible-patch count, not a correctness count. Moreover, §7's claim that 27/33 (actually 81.8%, not 82.8%) is 'consistent with our evaluation results' compares a correctness metric on a different set to a plausibility metric on the internal set; this needs clarification.
  3. [§6.2, Table 8] The relationship between the deployed FP2 system and the reported numbers is ambiguous. Table 8's rightmost 'PatchIsland' column reports 87/92 as a best-of-N upper bound, while §6.2 calls this number an upper bound. The text does not state explicitly whether the deployed FP2 orchestration achieved 84/92 (Table 3) or 87/92 (best-of-N). Because the headline contribution is the actual system rather than an oracle ensemble, the paper must clearly distinguish the best-of-N reference from the realized FP2 result and report the realized result with the corresponding per-vulnerability outcomes.
  4. [Reproducibility] No code, logs, or per-PoV outcome matrices are released. Given the inconsistencies in Table 3 and the importance of the internal comparison to the paper's claims, I consider the absence of these artifacts a load-bearing issue. The authors should release at least the per-vulnerability outcome table for all systems (as in Table 8 but extended to baselines), the exact agent configurations, and the FP2 scheduling decisions for each task, so that the internal evaluation can be verified independently.
minor comments (5)
  1. [§7] 'success rate of 82.8% (27 / 33)' should be 81.8% (27/33 = 0.8181...).
  2. [§10] Typo in the first sentence: 'presetned' should be 'presented'.
  3. [§6.1, Table 6] The 'Number of Vulnerabilities' column in Table 6 is ambiguous: it appears to be the number of vulnerabilities for which each team generated a PoV, not the total number of official confirmed vulnerabilities. Please define this column and explain why denominators differ across teams.
  4. [§2.2] The discussion of full vs delta mode is clear generally, but Table 2 lists several projects with zero vulnerabilities (e.g., Dicoogle, dcm4che). It would help to state explicitly that the selected 92 vulnerabilities are only those with an intended PoV in the released dataset, and that some projects had no such vulnerabilities.
  5. [§4.2, Algorithm 1] The correctness of the patch-side deduplication loop (Lines 9–12) is not immediately obvious, particularly the condition 'if not ResolvedByPatch(patch, crash)' before merging. A brief explanation or example would improve readability.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the central results are empirical and anchored to the externally validated AIxCC final; internal benchmark tuning is a validity issue, not a circular derivation.

full rationale

No equation-level or definitional circularity: PatchIsland is an empirical systems paper. Its headline 84/92 internal result is a measured count of plausible patches on the AIxCC 92-PoV dataset, and the official AIxCC final result (31/43, externally validated with manual patch review by organizers) provides an independent anchor. There is no fitted parameter later renamed as a prediction; the k=5 repetition count and agent-preference order were chosen from preliminary runs on the same benchmark, which is an evaluation-protocol/overfitting concern rather than a circular derivation. The only self-reference is citation [41] for implementation details of in-house agents, but it is not load-bearing: the paper's results rest on the external competition and on its own logs, not on the technical report. The paper itself flags that plausible-patch correctness is fragile (Sec. 7, Fig. 8), and Table 3's printed sums are internally inconsistent, but these are validity/reproducibility concerns, not circularity.

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

The central claim is empirical, so there are no mathematical free parameters or invented physical entities. The system has hand-tuned design parameters (k, agent ranking) and depends on several domain assumptions about patch validation, deduplication, and benchmark representativeness. The paper's own limitations section identifies the most important caveats.

free parameters (2)
  • k (number of repeated executions per agent) = 5
    Chosen from a preliminary convergence study on the same 92-PoV evaluation set; used for the best-of-N ensemble reporting in §6.2.
  • Agent preference order for FP2 = static ranking; Prism/MultiRetrieval top, ClaudeLike/Vincent lower
    Determined from development observations of which agents produce correct patches; no held-out validation; used in §4.3.
assumptions (4)
  • domain assumption A patch that prevents PoV reproduction and passes functional tests is a meaningful measure of repair effectiveness
    Used to define 'success' throughout §6; the paper itself notes in §7 that plausible patches can be incorrect, especially without functional tests (10/14 for unintended vulnerabilities).
  • domain assumption A correct patch for a root cause also resolves duplicate crashes sharing that root cause
    Foundation of two-phase patch-based deduplication (§4.2); if false, unique crashes get dropped.
  • domain assumption AIxCC Challenge Projects and their synthetic vulnerabilities are representative of real-world continuous-fuzzing workloads
    Dataset used to generalize to OSS-Fuzz-like settings (§6.1, Table 2).
  • domain assumption LLM agents fail independently enough that an ensemble improves operational robustness
    Core design premise (§3.2); supported by qualitative competition postmortem (§7.4), but not quantitatively tested.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair." pith.science (2026). https://pith.science/paper/AZ63O7XC

@misc{pith2026260117471,
  author       = {Pith},
  title        = {Pith review of: PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/AZ63O7XC}},
  note         = {Machine review of arXiv:2601.17471}
}
read the original abstract

Continuous fuzzing platforms such as OSS-Fuzz uncover large numbers of vulnerabilities, yet the subsequent repair process remains largely manual. Unfortunately, existing Automated Vulnerability Repair (AVR) techniques -- including recent LLM-based systems -- are not directly applicable to continuous fuzzing. This is because these systems are designed and evaluated on a static, single-run benchmark setting, making them ill-suited for the diverse, noisy, and failure-prone environments in continuous fuzzing. To address these issues, we introduce PatchIsland, a system for Continuous Vulnerability Repair (CVR) that tightly integrates with continuous fuzzing pipelines. PatchIsland employs an ensemble of diverse LLM agents. By leveraging multiple LLM agents, PatchIsland can cover a wider range of settings (e.g., different projects, bug types, and programming languages) and also improve operational robustness. In addition, PatchIsland utilizes a two-phase patch-based deduplication to mitigate duplicate crashes and patches, which can be problematic in continuous fuzzing. In our internal evaluation, PatchIsland repaired 84 of 92 vulnerabilities, demonstrating strong repair capability. In the official AIxCC competition, the system operated with no human intervention in a fully autonomous environment and successfully patched 31 out of 43 vulnerabilities, achieving a repair rate of 72.1\%.

Figures

Figures reproduced from arXiv: 2601.17471 by the authors.

Figure 1
Figure 1. Workflow of patch generation. PatchIsland operates between the continuous fuzzing pipeline and the bug tracker, receiving crash reports and delivering generated patches to developers. The Coordinator delegates patch generation to distributed Workers. FCFS Queue Sequential Handling Queue Worker Agent 2 (Processing) Coordinator Agent 4 (Skipped) Worker Agent 3 (Success) Sequential Handling Queue Agent 1 (Failed) Patch… view at source ↗
Figure 2
Figure 2. FP2 orchestration strategy with Ensemble Phase 2: Patch-side deduplication. PatchIsland also handles duplicates for patches. To be effective, PatchIsland needs to avoid submitting multiple patches for the same issue. Unfortunately, as mentioned before, we can only automatically determine a patch’s plausibility, not its correctness. As a result, PatchIsland can gen￾erate multiple plausible patches but incorrect ones.… view at source ↗
Figure 4
Figure 4. Effect of repeated executions for a non [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗
Figures from the paper (5 more)
Figure 5
Figure 5. Figure 5: Time and cost comparison of patch generation across scheduling strategies (Sequential (S), Parallel (P), and FP [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: PoV deduplication based on successful patch gener [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 8
Figure 8. Figure 8: An example of an inadequate patch that suppresses [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 7
Figure 7. Figure 7: A patch generated by PatchIsland for a vulnerabil￾ity in shadowsocks-libev. The json_parse_ex() function con￾tains three distinct bugs across different case branches, all of which are fixed simultaneously by this patch. 7.3 Case Studies In this section, we present two …
Figure 9
Figure 9. Figure 9: The patch generated by PatchIsland to fix infinite recursion in PDPageTree. This diff matches the developer’s commit, excluding one blank line. it fails and causes the initialization to stop. Due to this failure, PatchIsland could not generate patches for three vulnera…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

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

  1. SoK: DARPA's AI Cyber Challenge (AIxCC): Competition Design, Architectures, and Lessons Learned

    cs.CR 2026-02 conditional novelty 7.0 of 10

    Reliability and accuracy, not novel techniques, decided DARPA's 2025 AI cyber contest; LLM-based reasoning found 22 vulnerabilities that dedicated fuzzing missed, while auto-generated patches still fail semantic corre...

Reference graph

Works this paper leans on

51 extracted references · 2 canonical work pages · cited by 1 Pith paper

  1. [1]

    Seattle, WA

    2025.Proceedings of the 34th USENIX Security Symposium (Security). Seattle, WA

    2025

  2. [2]

    Aider-AI. [n. d.]. aider: AI pair programming in your terminal. https://github. com/Aider-AI/aider Accessed: Nov. 6, 2025

    2025

  3. [3]

    Aldeida Aleti and Matias Martinez. 2021. E-APR: Mapping the effectiveness of automated program repair techniques.Empirical Softw. Engg.26, 5 (Sept. 2021), 30 pages. doi:10.1007/s10664-021-09989-x

    work page doi:10.1007/s10664-021-09989-x 2021

  4. [4]

    Apache. 2025. https://github.com/apache/pdfbox/commit/ e58a1c92e97f9a207aaa5df5777d1ee6edb1104c Accessed: 2025-12-10

    2025

  5. [5]

    Stokes, John C

    Kevin Bartz, Jack W. Stokes, John C. Platt, Ryan Kivett, David Grant, Silviu Calinoiu, and Gretchen Loihle. 2008. Finding similar failures using callstack similarity. InProceedings of the Third Conference on Tackling Computer Systems Problems with Machine Learning Techniques(San Diego, California)(SysML’08). USENIX Association, USA, 1

    2008

  6. [6]

    Tim Blazytko, Moritz Schlögel, Cornelius Aschermann, Ali Abbasi, Joel Frank, Simon Wörner, and Thorsten Holz. 2020. AURORA: Statistical Crash Analysis for Automated Root Cause Explanation. InProceedings of the 29th USENIX Security Symposium (Security). Boston, MA

    2020

  7. [7]

    Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2025. RepairAgent: An Autonomous, LLM-Based Agent for Program Repair. InProceedings of the 47th International Conference on Software Engineering (ICSE). Ottawa, Canada

    2025

  8. [8]

    Max Brunsfeld. [n. d.]. Tree-sitter. https://tree-sitter.github.io/tree-sitter/ Ac- cessed: 2025-12-10

    2025

Show all 51 references
  1. [9]

    ccache. [n. d.]. Ccache - a fast C/C++ compiler cache. https://ccache.dev/ Accessed: 2025-12-10

    2025

  2. [10]

    Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott G...

    2021 arXiv

  3. [11]

    Wanli Chen, Yuanliang Chen, Fuchen Ma, Ruikang Peng, Qi Xu, Yu Jiang, Qiang Fu, and Heyuan Shi. 2025. PeachCI: Scalable Continuous Integration of Generation-Based Protocol Fuzzing. InProceedings of the 33rd ACM Interna- tional Conference on the Foundations of Software Engineer...

    2025

  4. [12]

    clangd. [n. d.]. clangd. https://clangd.llvm.org. Accessed: 2025-12-10

    2025

  5. [13]

    Viktor Csuvik, Dániel Horváth, Márk Lajkó, and László Vidács. 2024. GenProgJS: A Baseline System for Test-Based Automated Repair of JavaScript Programs.IEEE Transactions on Software Engineering01 (2024), 1–19

    2024

  6. [14]

    Universal Ctags. 2025. ctags. https://github.com/universal-ctags/ctags Accessed: 2025-07-27

    2025

  7. [15]

    Weidong Cui, Xinyang Ge, Baris Kasikci, Ben Niu, Upamanyu Sharma, Ruoyu Wang, and Insu Yun. 2018. REPT: Reverse Debugging of Failures in Deployed Software. InProceedings of the 13th USENIX Symposium on Operating Systems Design and Implementation (OSDI). Carlsbad, CA

    2018

  8. [16]

    Kemerlis

    Weidong Cui, Marcus Peinado, Sang Kil Cha, Yanick Fratantonio, and Vasileios P. Kemerlis. 2016. RETracer: Triaging Crashes by Reverse Execution from Partial Memory Dumps. InProceedings of the 38th International Conference on Software Engineering (ICSE). Texas, USA

    2016

  9. [17]

    Yingnong Dang, Rongxin Wu, Hongyu Zhang, Dongmei Zhang, and Peter Nobel

  10. [18]

    DARPA. 2024. AI Cyber Challenge (AIxCC). https://aicyberchallenge.com/ Accessed: 2025-11-07

    2024

  11. [19]

    DARPA. 2025. Final Competition Procedures and Scoring Guide. https: //aicyberchallenge.com/final-competition-procedures-and-scoring-guide/ Ac- cessed: 2025-11-07

    2025

  12. [20]

    eclipse-jdtls. [n. d.]. Eclipse JDT Language Server. https://github.com/eclipse- jdtls/eclipse.jdt.ls. Accessed: 2025-12-10

    2025

  13. [21]

    Zhiwei Fei, Jidong Ge, Chuanyi Li, Tianqi Wang, Yuning Li, Haodong Zhang, LiGuo Huang, and Bin Luo. 2025. Patch correctness assessment: A survey.ACM Transactions on Software Engineering and Methodology34, 2 (2025), 1–50

    2025

  14. [22]

    Andrea Fioraldi, Dominik Maier, Heiko Eißfeldt, and Marc Heuse. 2020. AFL++ : Combining Incremental Steps of Fuzzing Research. InProceedings of the 14th USENIX Workshop on Offensive Technologies (WOOT). Boston, MA

    2020

  15. [23]

    Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roy- choudhury

    Xiang Gao, Bo Wang, Gregory J. Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roy- choudhury. 2021. Beyond Tests: Program Vulnerability Repair via Crash Con- straint Extraction. InProceedings of the ACM Transactions on Software Engineering and Methodology (TOSEM). New York, NY, USA

    2021

  16. [24]

    Google. [n. d.]. ClusterFuzz. https://google.github.io/clusterfuzz/ Accessed: 2025-12-01

    2025

  17. [25]

    Google. [n. d.]. honggfuzz: General-purpose, easy-to-use fuzzer with interesting analysis options. https://github.com/google/honggfuzz Accessed: 2025-12-01

    2025

  18. [26]

    Google. 2025. OSS-Fuzz: Continuous Fuzzing for Open Source Software. https: //google.github.io/oss-fuzz/ Accessed: 2025-12-01

    2025

  19. [27]

    Patrick Herter, Vincent Ahlrichs, Ridvan Açilan, and Julian Horsch. 2026. GP- Trace: Effective Crash Deduplication Using LLM Embeddings. InProceedings of 12 the 48th International Conference on Software Engineering (ICSE). Rio, Brazil

    2026

  20. [28]

    Yiwei Hu, Zhen Li, Kedie Shu, Shenghua Guan, Deqing Zou, Shouhuai Xu, Bin Yuan, and Hai Jin. 2025. SoK: automated vulnerability repair: methods, tools, and assessments, See [1]

    2025

  21. [29]

    Zhen Huang, David Lie, Gang Tan, and Trent Jaeger. 2019. Using Safety Properties to Generate Vulnerability Patches. InProceedings of the 40th IEEE Symposium on Security and Privacy (Oakland). San Francisco, CA

    2019

  22. [30]

    2025.Intel 64 and IA-32 Architectures Software Developer’s Man- ual

    Intel Corporation. 2025.Intel 64 and IA-32 Architectures Software Developer’s Man- ual. https://www.intel.com/content/www/us/en/developer/articles/technical/ intel-sdm.html

    2025

  23. [31]

    Zhiyuan Jiang, Xiyue Jiang, Ahmad Hazimeh, Chaojing Tang, Chao Zhang, and Mathias Payer. 2021. Igor: Crash Deduplication Through Root-Cause Clustering. InProceedings of the 28th ACM Conference on Computer and Communications Security (CCS). Virtual

    2021

  24. [32]

    Youngjoon Kim, Sunguk Shin, Hyoungshick Kim, and Jiwon Yoon. 2025. Logs in, patches out: automated vulnerability repair via tree-of-thought LLM analysis, See [1]

    2025

  25. [33]

    Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2012. GenProg: A Generic Method for Automatic Software Repair.IEEE Transactions on Software Engineering(2012)

    2012

  26. [34]

    Kui Liu, Li Li, Anil Koyuncu, Dongsun Kim, Zhe Liu, Jacques Klein, and Tegawendé F Bissyandé. 2021. A critical review on the evaluation of automated program repair systems.Journal of Systems and Software171 (2021), 110817

    2021

  27. [35]

    Tarek Mahmud, Bin Duan, Corina Pasareanu, and Guowei Yang. 2025. Enhancing LLM Code Generation with Ensembles: A Similarity-Based Selection Approach. arXiv:2503.15838 [cs.SE] https://arxiv.org/abs/2503.15838

    2025 arXiv

  28. [36]

    Yu Nong, Haoran Yang, Long Cheng, Hongxin Hu, and Haipeng Cai. 2025. AP- PATCH: automated adaptive prompting large language models for real-world software vulnerability patching, See [1]

    2025

  29. [37]

    Oracle. [n. d.]. jstack - Stack Trace. https://docs.oracle.com/javase/7/docs/ technotes/tools/share/jstack.html

  30. [38]

    Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan Dolan-Gavitt. 2023. Examining zero-shot vulnerability repair with large language models. In2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2339–2356

    2023

  31. [39]

    Zichao Qi, Fan Long, Sara Achour, and Martin Rinard. 2015. An analysis of patch plausibility and correctness for generate-and-validate patch generation systems. InProceedings of the 2015 international symposium on software testing and analysis. 24–36

    2015

  32. [40]

    Arindam Sharma, Cristian Cadar, and Jonathan Metzman. 2024. Effective Fuzzing within CI/CD Pipelines (Registered Report). InProceedings of the 3rd ACM Inter- national Fuzzing Workshop(Vienna, Austria)(FUZZING 2024). Association for Computing Machinery, New York, NY, USA, 52–60...

    2024

  33. [41]

    Team-Atlanta. 2025. Technical Report. https://arxiv.org/abs/2509.14589

    2025

  34. [42]

    The MITRE Corporation. [n. d.]. CWE-193: Off-by-one Error. https://cwe.mitre. org/data/definitions/193.html Accessed: 2025-12-01

    2025

  35. [43]

    Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. De- mystifying LLM-Based Software Engineering Agents.Proc. ACM Softw. Eng.2, FSE, Article FSE037 (June 2025), 24 pages. doi:10.1145/3715754

    2025 doi

  36. [44]

    Chunqiu Steven Xia and Lingming Zhang. 2022. Less training, more repairing please: revisiting automated program repair via zero-shot learning. InProceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering(...

    2022

  37. [45]

    John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik R Narasimhan, and Ofir Press. 2024. SWE-agent: Agent-Computer Inter- faces Enable Automated Software Engineering. InThe Thirty-eighth Annual Con- ference on Neural Information Processing Systems....

    2024 arXiv

  38. [46]

    Kexun Zhang, Weiran Yao, Zuxin Liu, Yihao Feng, Zhiwei Liu, Rithesh Murthy, Tian Lan, Lei Li, Renze Lou, Jiacheng Xu, Bo Pang, Yingbo Zhou, Shelby Hei- necke, Silvio Savarese, Huan Wang, and Caiming Xiong. 2024. Diversity Em- powers Intelligence: Integrating Expertise of Softw...

    2024 arXiv

  39. [47]

    Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Au- toCodeRover: Autonomous Program Improvement. InProceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis(Vienna, Austria)(ISSTA 2024). Association for Computing Machine...

    2024

  40. [48]

    Yuntong Zhang, Jiawei Wang, Dominic Berzin, Martin Mirchev, Dongge Liu, Abhishek Arya, Oliver Chang, and Abhik Roychoudhury. 2024. Fixing Security Vulnerabilities with AI in OSS-Fuzz. arXiv:2411.03346 [cs.CR] https://arxiv.org/ abs/2411.03346

    2024 arXiv

  41. [49]

    Bis- syande, Bin Luo, and Vincent Ng

    Wenkang Zhong, Chuanyi Li, Kui Liu, Tongtong Xu, Jidong Ge, Tegawende F. Bis- syande, Bin Luo, and Vincent Ng. 2024. Practical Program Repair via Preference- based Ensemble Strategy. InProceedings of the 46th International Conference on Software Engineering (ICSE). Lisbon, Portugal

    2024

  42. [50]

    Albert Örwall. 2024. Moatless Tools. doi:10.5281/zenodo.15614422 License: MIT. 13 Table 7: Detailed list of CP vulnerabilities included in our appendix dataset. This table enumerates all 92 vulnerabilities selected from the AIxCC CP dataset that include an Intended Proof-of-Vu...

    2024 doi

  43. [2012]

    InProceedings of the 34th International Conference on Software Engineering (ICSE)

    ReBucket: a method for clustering duplicate crash reports based on call stack similarity. InProceedings of the 34th International Conference on Software Engineering (ICSE). Zurich, Switzerland

Pith tools

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