PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair
Fuente:
arXiv
Saved in:
| Main Authors: | , , , , , , , , , , , , , |
|---|---|
| Format: | Preprint |
| Published: |
2026
|
| Subjects: | |
| Online Access: | |
| Tags: |
Add Tag
No Tags, Be the first to tag this record!
|
| _version_ | 1866908785868537856 |
|---|---|
| author | Kim, Wonyoung Min, Seunggi Gwon, Minjae Baik, Dowoo Lee, Haein Heo, Hyeon Lee, Minjae Baek, Min Woo Jin, Yonghwi Park, Younggi Choi, Yunjae Kim, Taesoo Park, Sangdon Yun, Insu |
| author_facet | Kim, Wonyoung Min, Seunggi Gwon, Minjae Baik, Dowoo Lee, Haein Heo, Hyeon Lee, Minjae Baek, Min Woo Jin, Yonghwi Park, Younggi Choi, Yunjae Kim, Taesoo Park, Sangdon Yun, Insu |
| contents | 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\%. |
| format | Preprint |
| id |
arxiv_https___arxiv_org_abs_2601_17471 |
| institution | arXiv |
| publishDate | 2026 |
| record_format | arxiv |
| spellingShingle | PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair Kim, Wonyoung Min, Seunggi Gwon, Minjae Baik, Dowoo Lee, Haein Heo, Hyeon Lee, Minjae Baek, Min Woo Jin, Yonghwi Park, Younggi Choi, Yunjae Kim, Taesoo Park, Sangdon Yun, Insu Cryptography and Security 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\%. |
| title | PatchIsland: Orchestration of LLM Agents for Continuous Vulnerability Repair |
| topic | Cryptography and Security |
| url | https://arxiv.org/abs/2601.17471 |