Paper deep dive

AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair

Michael Fu, Qiyue Mei, Patanamon Thongtanunam, Kla Tantithamthavorn

Year: 2026Venue: arXiv preprintArea: cs.SEType: PreprintEmbeddings: 66

Intelligence

Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 91%

Last extracted: 8/3/2026, 3:00:24 AM

Summary

The paper introduces AgenticRepair, an agentic vulnerability repair framework that addresses gaps in existing approaches by engineering multi-faceted program context. It utilizes three specialized LLM subagents to extract code-structure, runtime-execution, and commit-history contexts, which are then embedded into the memory of a dedicated repair subagent for patch synthesis. Evaluated on SEC-Bench, AgenticRepair achieves a 73% success rate, significantly outperforming baselines.

Entities (8)

AgenticRepair · framework · 98%SEC-Bench · benchmark · 95%Code-Structure Context · context-type · 90%Commit-History Context · context-type · 90%CVE-2021-30027 · vulnerability · 90%Runtime-Execution Context · context-type · 90%AddressSanitizer · tool · 85%md4c · software-project · 85%

Relation Signals (7)

AgenticRepair → achievessuccessrate → 73%

confidence 95% · AgenticRepair achieves a 73% success rate

AgenticRepair → evaluatedon → SEC-Bench

confidence 95% · Evaluated on SEC-Bench comprising 300 real-world instances

CVE-2021-30027 → foundin → md4c

confidence 90% · CVE-2021-30027 in the md4c Markdown parser

AgenticRepair → outperforms → strongest baseline

confidence 90% · substantially outperforming the strongest baseline by 29%

AgenticRepair → uses → Commit-History Context

confidence 90% · AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts... commit-history context recovering how fragile code patterns were introduced

AgenticRepair → uses → Code-Structure Context

confidence 90% · AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts... code-structure context capturing cross-file data flows

AgenticRepair → uses → Runtime-Execution Context

confidence 90% · AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts... runtime-execution context revealing crash semantics

Cypher Suggestions (0)

No Cypher suggestions yet.

Abstract

Abstract:Automated vulnerability repair aims to reduce the time and effort required to patch security flaws from a vulnerability triage report. Recent agentic AI approaches have shown promising results in automated program repair. However, vulnerability repair demands richer program context than general bug repair - context that security engineers routinely assemble in practice but that existing agentic approaches do not engineer. We identify three critical gaps: code-structure context capturing cross-file data flows and memory operation patterns, runtime-execution context revealing crash semantics and memory origins, and commit-history context recovering how fragile code patterns were introduced. We present AgenticRepair, an agentic vulnerability repair framework that addresses the gaps through multi-faceted program context engineering. AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts, which are then embedded into the memory of a dedicated repair subagent for context-conditioned patch synthesis. Evaluated on SEC-Bench comprising 300 real-world instances with sanitizer-based patch verification, AgenticRepair achieves a 73% success rate, substantially outperforming the strongest baseline by 29%. Our ablation study confirms that the three context facets are mutually complementary, and that multi-agent scaffolding and base-model capacity each play an essential role. Collectively, these findings establish multi-faceted program context engineering as a promising design direction for agentic vulnerability repair.

PDF

Open source PDF →Open local PDF →

Trouble viewing inline? Open PDF directly →

Full Text

64,839 characters extracted from source content.

Expand or collapse full text

AgenticRepair: Multi-Faceted Program Context Engineering for Agentic Vulnerability Repair Michael Fu, Qiyue Mei, Patanamon Thongtanunam, Kla Tantithamthavorn Michael Fu, Qiyue Mei, and Patanamon Thongtanunam are with the School of Computing and Information Systems, The University of Melbourne, Melbourne, Australia. E-mail: michael.fu@unimelb.edu.au, qiyue.mei@student.unimelb.edu.au, patanamon.t@unimelb.edu.au Kla Tantithamthavorn is with the Faculty of Information Technology, Monash University, Melbourne, Australia. E-mail: chakkrit@monash.edu Abstract Automated vulnerability repair aims to reduce the time and effort required to patch security flaws from a vulnerability triage report. Recent agentic AI approaches have shown promising results in automated program repair. However, vulnerability repair demands richer program context than general bug repair — context that security engineers routinely assemble in practice but that existing agentic approaches do not engineer. We identify three critical gaps: code-structure context capturing cross-file data flows and memory operation patterns, runtime-execution context revealing crash semantics and memory origins, and commit-history context recovering how fragile code patterns were introduced. We present AgenticRepair, an agentic vulnerability repair framework that addresses the gaps through multi-faceted program context engineering. AgenticRepair orchestrates three specialized LLM subagents to engineer the contexts, which are then embedded into the memory of a dedicated repair subagent for context-conditioned patch synthesis. Evaluated on SEC-Bench comprising 300 real-world instances with sanitizer-based patch verification, AgenticRepair achieves a 73% success rate, substantially outperforming the strongest baseline by 29%. Our ablation study confirms that the three context facets are mutually complementary, and that multi-agent scaffolding and base-model capacity each play an essential role. Collectively, these findings establish multi-faceted program context engineering as a promising design direction for agentic vulnerability repair. Index Terms: Agentic vulnerability repair, automated vulnerability repair, program context engineering, program analysis, static and dynamic analysis. I Introduction Software vulnerabilities represent one of the most persistent and dangerous threats in modern software systems, frequently resulting in severe security incidents with widespread real-world impact. Unlike ordinary software bugs, security vulnerabilities often originate from subtle low-level interactions, cross-file data flows, and fragile historical code patterns that are exceptionally difficult to diagnose and repair correctly. As a result, patching these flaws remains a highly time-consuming and expertise-intensive task. In particular, a prior study reports that the median time from vulnerability disclosure to patch deployment often exceeds 70 days Roumani (2021). Automated vulnerability repair aims to substantially reduce the time and effort required for patching by enabling effective patch generation. Early learning-based approaches Chen et al. (2022); Fu et al. (2022, 2024a, 2024b); Zhou et al. (2024); Bhandari et al. (2025) fine-tuned smaller language models on individual vulnerable functions, but their limited context windows prevented effective handling of vulnerabilities across multiple files. More recent LLM-based methods Xia and Zhang (2024); Fu et al. (2023); Huang et al. (2025); Wen et al. (2025) leverage larger models with extended context windows, yet still lack full repository access and meaningful interaction with the development environment. In contrast, recent state-of-the-art agentic repair approaches Bouzenia et al. (2025); Rondon et al. (2025); Lee et al. (2025) orchestrate multiple LLM-driven subagents that can read, edit, and cross-reference files across the entire repository. This design makes them a potential solution for repairing vulnerabilities that span different files and folders. Figure 1: Comparison of the manual vulnerability remediation workflow (top) versus agentic repair approaches (bottom). Agentic repair approaches take the same triage report (vulnerability description + sanitizer output) already produced by security engineers, automate diagnosis and patch synthesis, and submit the verified patch directly for code review and merge. We define agentic repair as an autonomous framework that orchestrates multiple LLM-driven subagents capable of reading, editing, and reasoning over an entire codebase. As illustrated in Figure 1, agentic repair operates immediately after the standard vulnerability triage phase, where security engineers analyze failing executions from fuzzing or testing campaigns, produce a natural-language description of the vulnerability, and attach the corresponding sanitizer report. Taking these routinely generated triage artifacts as input, agentic repair automates the subsequent diagnosis and patch synthesis steps that are traditionally performed manually — including static analysis across repository folders, dynamic analysis via sanitizer execution, iterative code editing, and verification. The verified patch is then submitted for code review and merge. As shown in Figure 1, vulnerability repair in practice requires a richer program context than general bug repair: security engineers run static analysis tools and dynamic sanitizer instrumentation to build a structured understanding of the vulnerability, and draw on version history when editing code to understand how the affected region has evolved. However, existing agentic repair approaches Yang et al. (2024); Xia et al. (2024); Bouzenia et al. (2025); Zhang et al. (2024) — primarily designed for general program repair — rely on file navigation, code retrieval, and compiler or test feedback alone, providing no mechanism for assembling the security-relevant program context. This raises a key software engineering question: how should program context be engineered into an agentic repair framework to enable correct and safe vulnerability repair? We refer to this challenge as a program context engineering problem for agentic repair approaches. It is particularly acute for security vulnerabilities, whose root causes emerge from the interplay of runtime crash semantics Gao et al. (2021), cross-file static data flows Yamaguchi et al. (2014), and historically fragile code evolution patterns Bosu et al. (2014); Jiang et al. (2024) — facets that are well-studied in the software engineering literature, yet never jointly engineered as a unified repair context. To address this challenge, we present AgenticRepair, the first agentic vulnerability repair framework that operationalizes multi-faceted program context engineering. Given a vulnerability report comprising a natural-language description and a sanitizer trace, AgenticRepair orchestrates three context engineering subagents that operate in parallel to engineer the code-structure context, the runtime-execution context, and the commit-history context. The contexts are then synthesized into a unified multi-faceted program context and persistently embedded into an episodic memory window, providing the repair subagent with a structured, continuously accessible knowledge substrate that grounds its repair decision. The repair subagent leverages this engineered context to iteratively generate and verify minimal patches across the repository until the sanitizer reports no violation, confirming successful vulnerability elimination. To evaluate the effectiveness of AgenticRepair, we conducted experiments on SEC-Bench, a recent benchmark comprising 300 real-world vulnerable instances. AgenticRepair successfully repaired 220 vulnerabilities, achieving a state-of-the-art success rate of 73%. At the time of writing, this result ranks first on the SEC-Bench leaderboard Lee (2025), substantially outperforming the strongest existing baseline (34%). Notably, 90 (40%) of the successful repairs involve edits across multiple files, demonstrating AgenticRepair’s ability to handle complex cross-file security issues. Our ablation study further shows that our multi-faceted program context (i.e., program structure, runtime execution behavior, and commit history) is complementary, as removing any single facet results in only minor performance degradation. The study also highlights the importance of the multi-agent scaffold in distributing cognitive load across subagents, as well as the need for sufficiently capable base models to effectively reason over the engineered program context. Collectively, these results shed light on our research question, suggesting that deliberate, multi-faceted program context engineering is a key principle for advancing agentic vulnerability repair. Key Contributions. To the best of our knowledge, the contributions of this paper are as follows: • AgenticRepair, the first agentic vulnerability repair framework that explicitly integrates augmented contextual program insights—including code structure, runtime behavior, and repository history—into an automated repair pipeline. • We evaluate AgenticRepair on SEC-Bench, consisting of 300 real-world vulnerable instances, each hosted in an isolated Docker environment and verified using sanitizer checks to ensure the elimination of vulnerabilities. • We perform an extensive ablation study to analyze the key components of AgenticRepair, including the augmented contextual program insights, multi-agent scaffolding, and base model capacity. • We provide all experimental artifacts for review, including full execution logs, trajectories, and a ready-to-run implementation of AgenticRepair. The replication package is included in the online supplementary materials for the TSE submission and will be made publicly available. I Related work & Motivation I-A Learning-Based Vulnerability Repair Early learning-based automatic vulnerability repair approaches framed the task as sequence-to-sequence learning, taking a vulnerable function as input and generating the corresponding repair patch as output. Foundational works such as VRepair Chen et al. (2022) and VulRepair Fu et al. (2022) fine-tuned small transformer models (e.g., CodeT5). Later extensions, including VQM Fu et al. (2024a) (vision-transformer-inspired localization) and AIBughunter Fu et al. (2024b) (IDE integration), followed the same paradigm. Subsequent advances such as VulMaster Zhou et al. (2024) (Fusion-in-Decoder + AST + CWE knowledge) and PatchLM Bhandari et al. (2025) (multi-language CVE fine-tuning) further improved performance. Despite the improvements, all learning-based approaches share critical limitations: they operate under strict input-length windows, treat code as flat text sequences with limited structural awareness, and focus primarily on single-function scope. Consequently, they cannot handle cross-file or repository-level vulnerabilities that require interactions across modules, headers, and directories. I-B LLM-Based Vulnerability Repair Early large language model (LLM)–based approaches treat vulnerability repair as a zero- or few-shot generation task. For example, Xia et al. Xia and Zhang (2024) employed iterative dialogue with ChatGPT, while Fu et al. Fu et al. (2023) evaluated ChatGPT for vulnerability detection and repair. Subsequent work moved beyond prompt engineering by applying parameter-efficient fine-tuning and reinforcement learning to billion-parameter models. For instance, Huang et al. Huang et al. (2025) evaluated multiple fine-tuning methods, including LoRA, AdaLoRA, and IA3, on models such as CodeLlama and StarCoder, while Wen et al. Wen et al. (2025) proposed Vul-R2, a reasoning-enhanced approach that combines supervised fine-tuning with RL-based curriculum learning. Despite the advances, fine-tuning billion-parameter LLMs remains computationally expensive even with parameter-efficient techniques such as LoRA. In addition, most methods are restricted to function-level repair within a single file. Thus, they lack cross-file or cross-directory reasoning capabilities, which makes them ineffective for vulnerabilities that involve interactions across modules, headers, or multiple directories in a repository. I-C Agentic Vulnerability Repair Agentic vulnerability repair leverages autonomous LLM subagents that interact directly with a full codebase. The subagents can read and modify files, execute tests, search across directories, and iteratively refine patches based on execution feedback, enabling repository-level reasoning beyond single-function scope. Early agentic repairs were primarily designed for general program repair. Bouzenia et al. Bouzenia et al. (2025) introduced RepairAgent, which applies a ReAct (Reasoning–Action) loop with file-editing and test-execution tools to fix general software bugs. Similarly, Rondon et al. Rondon et al. (2025) evaluated a ReAct-style repair agent on real enterprise bugs, demonstrating the ability to generate plausible patches on internal codebases. Zhang et al. Zhang et al. (2024) proposed AutoCodeRover, which leverages AST-based code search and spectrum-based fault localization to navigate large repositories for bug repair. Xia et al. Xia et al. (2024) introduced Agentless, a two-phase approach that first localizes the fault through hierarchical file and function retrieval, then generates and ranks candidate patches using test feedback. In contrast, Lee et al. Lee et al. (2025) conducted one of the first studies specifically evaluating agentic repairs such as SWE-Agent Yang et al. (2024), OpenHands Wang et al. (2024), and Aider Aider (2026) on the vulnerability repair task. However, as Lee et al. Lee et al. (2025) observed, general-purpose agentic systems struggle when applied to vulnerability repair, where security-specific failure modes — memory safety violations, runtime crash behaviors, and exploit-triggering inputs — demand a richer, more structured program analysis context to accurately synthesize a correct patch. Figure 2: Motivating example mity (2021): CVE-2021-30027 in the md4c Markdown parser, a use-of-uninitialized-value vulnerability spanning two files and three independent issues. I-D Motivating Example Figure 2 illustrates CVE-2021-30027, a use-of-uninitialized-value memory-safety vulnerability in the md4c Markdown parser that spans two files and three independent issues. In src/md4c.c, the parser uses an unbounded macro CH(off) (Listing 1) that directly indexes into a buffer without checking its length. At the same time, a stack-allocated MD_LINE_ANALYSIS struct with two packed fields is never initialized (Listing 2). Because these two fields share the same memory location, writing to one field forces the CPU to first read the entire location. This read pulls in random leftover bytes from the other field, causing the program to use uninitialized memory and triggering the crash. The bytes causing the problem actually come from a different file, md2html/md2html.c. The driver in md2html/md2html.c allocates the buffer with plain malloc(), which leaves all unused bytes as random garbage (Listing 3). In contrast, using calloc() would have zeroed the entire buffer beforehand, making every byte safe to read. While existing agentic approaches perform well for general program repair, security vulnerabilities require richer program analysis and historical context that prior approaches do not consider. In particular, through this motivating example, we identified three limitations of existing agentic repair Zhang et al. (2024); Xia et al. (2024); Bouzenia et al. (2025); Rondon et al. (2025); Lee et al. (2025): • Limited Code-Structure Context: The packed-bitfield struct in MD_LINE_ANALYSIS (Listing 2) shares a single memory location between two fields. Writing to one field forces a read-modify-write operation that pulls in random leftover bytes from the adjacent field. Without deep structural insight into compiler-level data layouts, agents cannot detect or fix this subtle initialization issue. • Limited Runtime Execution Context: The crash originates from an unbounded CH(off) macro (Listing 1) reading past a buffer end, yet the uninitialized bytes actually come from a malloc() in the separate driver file md2html/md2html.c (Listing 3). Without runtime origin tracking that connects allocation sites across file boundaries, agents cannot locate the true source of the uninitialized memory. • Limited Repository History Context: The repository history reveals that the vulnerable strcspn() optimization was introduced in a prior commit, which fundamentally altered memory handling patterns and inadvertently created the conditions for uninitialized memory usage. Without this historical origin context, agents cannot trace how and when the vulnerability arose, nor understand the evolutionary root cause of the vulnerable code structure. I AgenticRepair: Context-Engineered Agentic Vulnerability Repair In this section, we present the architecture of AgenticRepair. As illustrated in Figure 3, the framework comprises two main steps: 1 multi-faceted program context engineering, in which three specialized subagents operate in parallel to engineer code-structure, runtime-execution, and commit-history contexts, which are then synthesized into a unified multi-faceted program context; and 2 patch synthesis with engineered program context, in which the unified context is persistently embedded into the episodic memory of a dedicated repair subagent, which then iteratively generates and verifies patches until the vulnerability is eliminated. Figure 3: Overview of our AgenticRepair architecture, including three subagents (struct,exec,andhistA_struct,A_exec,andA_hist) for program context engineering and one subagent (repairA_repair) for vulnerability patch synthesis. We formally define AgenticRepair as follows: AgenticRepair=⟨,ℰ,,,P⟩ AgenticRepair= ,E,A,C,P where: • V: the input vulnerability specified by the vulnerability description together with the AddressSanitizer report; • ℰE: the sandbox environment containing the project repository ℛR and the vulnerability reproduction harness H; • =struct,exec,hist,repairA=\A_struct,A_exec,A_hist,A_repair\: the four specialized subagents; • =struct,exec,histC=\C_struct,C_exec,C_hist\: the unified multi-faceted program context, comprising the code-structure context structC_struct, the runtime-execution context execC_exec, and the commit-history context histC_hist engineered by the three context engineering subagents; • P: a candidate patch generated by the Repair Subagent. Below, we describe the two main steps in detail. I-A Multi-Faceted Program Context Engineering In Step 1, the three context engineering subagents—structA_struct, execA_exec, and histA_hist—operate in parallel within the sandbox environment ℰE (containing the project repository ℛR). Guided by the vulnerability description V, each subagent independently extracts the relevant program structure, runtime execution behavior, or commit history, respectively. These partial contexts are then synthesized into the unified multi-faceted program context =struct,exec,histC=\C_struct,C_exec,C_hist\. I-A1 Code-Structure Context (structC_struct) In Step 1a, the code structure subagent structA_struct prepares the program-structure context structC_struct as part of the multi-faceted context engineering pipeline. Guided by the vulnerability description and sanitizer trace in V, structA_struct first classifies the vulnerability type and identifies the relevant files and locations within the project repository ℛR. structA_struct then extracts precise structural information (i.e., data-flow relations, taint propagation paths, control-flow dependencies, and vulnerable memory operation patterns around the vulnerable site) through semantic code analysis By summarizing the extracted findings and reflecting on the root cause, structA_struct then condenses the results into a compact structured representation including the vulnerable location, a data-flow summary, the structural concern related to the vulnerability, and high-level fix direction suggestions. I-A2 Runtime-Execution Context (execC_exec) In Step 1b, the runtime execution subagent execA_exec prepares the execution context execC_exec as part of the multi-faceted context engineering pipeline. Similar to structAstruct, execAexec first classifies the vulnerability type and then identifies the relevant files and locations within the project repository ℛR based on the vulnerability description and sanitizer trace provided in V. execA_exec then triggers the reproduction harness H under dynamic instrumentation to capture precise runtime behaviors, including crash signatures (address and type), full stack backtraces, memory access patterns and violations, and anomalous execution states around the vulnerable site. Finally, execA_exec compresses the observed runtime outputs and root cause analysis into a compact structured representation encompassing the crash location and type, key backtrace frames, memory state observations, the runtime vulnerability insight, and high-level fix suggestions. I-A3 Commit-History Context (histC_hist) In Step 1c, the commit-history subagent histA_hist prepares the commit-history context histC_hist as part of the multi-faceted context engineering pipeline. Similar to structA_struct and execA_exec, histA_hist first identifies the key files and functions involved in the vulnerability within the project repository ℛR guided by the vulnerability description and sanitizer trace in V. histA_hist then mines the version-control history preceding the vulnerable base commit to reconstruct evolutionary patterns, extracting relevant commit metadata, code change summaries, and historical modification contexts around the identified sites. By summarizing the extracted historical evidence and reflecting on the root cause, histA_hist condenses these results into a compact structured representation including the analyzed file and function, relevant commits with change summaries and relevance scores, the vulnerability origin insight, and high-level fix direction suggestions. To consolidate its findings, histA_hist compresses the historical evidence and root cause analysis into a compact structured representation — one that captures the analyzed file and function, relevant commits with their change summaries and relevance, the origin of the vulnerability, and suggested directions for repair. I-B Patch Synthesis with Engineered Multi-Faceted Program Context In Step 2, the repair subagent repairA_repair performs context-conditioned patch synthesis by embedding the engineered multi-faceted program context C directly into a persistent episodic memory ℳM, ensuring that all repair decisions are grounded in unified, cross-dimensional program understanding rather than surface-level code context. Guided by the vulnerability description and sanitizer trace in V, repairA_repair iterates over a synthesis-verification loop, generates minimal candidate patches P, applies them to the project repository ℛR, rebuilds the project, and re-executes the reproduction harness H while continuously reflecting on verification outcomes within the same memory window. This closed-loop design enables repairA_repair to converge on a verified patch satisfying all sanitizer checks, which constitutes the final output of AgenticRepair. I-C Implementation AgenticRepairis realized as a custom multi-agent orchestration framework built atop the smolagents library Roucher et al. (2025). The system is architected around a two-phase pipeline that directly operationalizes our multi-faceted program context engineering approach. In the first phase, three specialized context engineering subagents (structA_struct, execA_exec, and histA_hist) execute in parallel. Each follows the ReAct paradigm Yao et al. (2022): it reasons over the vulnerability input V, selects and invokes domain-specific tools to gather its facet of information, observes the results, and reflects to produce the corresponding partial context (structC_struct, execC_exec, or histC_hist). The three partial contexts are then synthesized into the unified multi-faceted program context C and injected into a persistent episodic memory ℳM. In the second phase, the Repair Subagent repairA_repair operates exclusively over this enriched memory window, ensuring every repair decision remains fully aware of the complete engineered context across iterations. Each subagent is assigned an independent model backend with a configurable step budget, and the entire pipeline executes inside isolated Docker environments for reproducibility. IV Experimental Design In this section, we present the motivation for our two research questions, the studied benchmark, baseline approaches, and experimental setup. IV-A Research Questions To evaluate our AgenticRepair approach, we formulate the following two research questions. (RQ1) What is the accuracy of our AgenticRepair for automated vulnerability repair? While recent agent-based approaches have shown promise in general program repair Bouzenia et al. (2025); Rondon et al. (2025), they are primarily designed and evaluated on non-security benchmarks. Existing frameworks often lack integration with specialized program analysis and repository history—capabilities critical for diagnosing security issues and generating patches. To evaluate whether incorporating our multi-faceted program context improves vulnerability repair, we evaluate AgenticRepair on the full 300-instance SEC-Bench benchmark Lee et al. (2025). (RQ2) What are the contributions of the components of our AgenticRepair? Our AgenticRepair incorporates several key design choices, including the multi-faceted program context (code structure, runtime execution, and commit history), the multi-agent scaffolding architecture, and base-model capacity. However, little is known about the contributions of these components to the effectiveness of AgenticRepair. Thus, we formulate this research question to investigate the contributions of each component of AgenticRepair. IV-B Studied Benchmark To address our RQs, we adopt SEC‑Bench Lee et al. (2025), a recently introduced benchmark constructed from real‑world C/C++ projects. We select SEC‑Bench over CyberGym Wang et al. (2025), which relies on fuzz‑generated inputs that begin execution from artificial fuzz targets rather than real program interfaces. We select SEC‑Bench over ARVO Mei et al. (2024), which assembles thousands of OSS‑Fuzz cases but triggers vulnerabilities through fuzz harnesses that do not reflect how users naturally interact with the software. In contrast, SEC‑Bench reproduces vulnerabilities in native builds with real entry points, provides human‑readable PoCs, and uses sanitizer‑based oracles for deterministic verification, offering a more faithful environment for assessing agentic repair approaches. Unlike traditional vulnerability repair datasets (e.g., CVEFixes Bhandari et al. (2021), Big‑Vul Fan et al. (2020), and DiverseVul Chen et al. (2023)) that supply isolated code snippets and rely on exact‑patch matching—which can incorrectly penalize semantically correct but syntactically different repairs—SEC‑Bench offers full codebases, build environments, and execution harnesses, making it well-suited for evaluating interactive, agentic repair approaches. SEC‑Bench provides 300 reconstructed vulnerabilities drawn from 34 repositories and 32 projects across 242 historical commits. For each vulnerability, agents receive two primary inputs: an AddressSanitizer report, which describes the concrete failing execution (median ≈ 1.2k tokens per report), and a human‑written bug description summarizing the root cause and impact (median ≈ 48 tokens per description), such as identifying an out‑of‑bounds heap write in a specific parsing routine. These inputs mirror the information available to security engineers during triage and give agents both dynamic evidence of the failure and a high‑level semantic explanation of the flaw. The agent then interacts with the full codebase at the vulnerable commit provided by SEC‑Bench to generate a repair. SEC-Bench also includes the corresponding human‑written patch (median ≈ 238 tokens per patch) for each instance, enabling analyses such as checking whether an agent’s patch unintentionally resembles the developer fix, which could indicate potential data leakage. IV-C Baselines We compare our AgenticRepair approach against four widely adopted LLM-based agentic frameworks: OpenHands Wang et al. (2024), SWE-Agent Yang et al. (2024), Aider Aider (2026), and Smolagents Roucher et al. (2025). OpenHands is an open-source platform for building general-purpose AI software engineering agents, SWE-Agent is an autonomous agent framework designed for solving real-world software engineering tasks, Aider is a terminal-based AI pair-programming tool for direct code editing and git workflows, and Smolagents is a lightweight framework for constructing modular multi-step LLM agents. IV-D Experimental Setup In AgenticRepair, all subagents are instantiated as ToolCallingAgent instances from the smolagents library. Unlike CodeAgent, which generates and executes free-form Python code, ToolCallingAgent operates via structured JSON tool calls. We use the gpt-5.2-2025-12-11 model with its default medium reasoning effort and a fixed temperature of 1.0 (enforced by the provider for reasoning-effort models). Each analysis subagent (structA_struct, execA_exec, histA_hist) is configured with a maximum of 20 steps, while the repair subagent (repairA_repair) is allowed up to 75 steps to support iterative patch refinement, following the configuration used in the SEC-Bench benchmark. V Experimental Results In this Section, we present the experimental results to answer the following two research questions. TABLE I: RQ1: Vulnerability Patching Performance on SEC-bench (Strict Evaluation, 300 instances) LLM Agent Base Model CVE (200) OSS (100) Total (300) Success Rate Rank Success Rate Rank Success Rate Rank AgenticRepair (ours) GPT-5.2 75.0% (150) 1 70.0% (70) 1 73.3% (220) 1 Smolagents GPT-5.2 45.0% (90) 2 44.0% (44) 2 44.7% (134) 2 Smolagents GPT-5-mini 34.5% (69) 3 32.0% (32) 3 33.7% (101) 3 Smolagents GPT-5-nano 11.5% (23) 7 11.0% (11) 4 11.3% (34) 4 OpenHands Claude 3.7 Sonnet 34.0% (68) 4 – – – – SWE-Agent Claude 3.7 Sonnet 31.5% (63) 5 – – – – Aider Claude 3.7 Sonnet 23.5% (47) 6 – – – – TABLE I: RQ2: Ablation Study on AgenticRepair Components (200 CVE instances) Configuration Generous Medium Strict Δ (Strict) Success Rate Full AgenticRepair (GPT-5.2) 80.0% (160) 80.0% (160) 75.0% (150) – Ablation on Multi-Faceted Program Context w/o Code‑Structure Context 76.5% (153) 76.5% (153) 73.5% (147) -1.5% w/o Program-Execution Context 77.5% (155) 77.5% (155) 74.5% (149) -0.5% w/o Commit-History Context 77.0% (154) 76.5% (153) 73.0% (146) -2.0% Ablation on Agent Scaffolding w/ Single Agent Scaffold 56.0% (112) 55.0% (110) 30.5% (61) -44.5% Ablation on Base Model Size AgenticRepair (GPT-5-Mini) 68.5% (137) 67.5% (135) 50.0% (100) -25.0% AgenticRepair (GPT-5-Nano) 19.0% (38) 18.5% (37) 10.0% (20) -65.0% (RQ1) What is the accuracy of our AgenticRepair for automated vulnerability repair? Approach. To address RQ1, we evaluate the automated vulnerability repair capabilities of our AgenticRepair approach against several state-of-the-art LLM-based agents, including OpenHands, SWE-Agent, Aider (using Claude 3.7 Sonnet as the base model), and Smolagents (configured with three distinct base models: GPT-5.2, GPT-5-mini, and GPT-5-nano). We use SEC-Bench Lee et al. (2025), which comprises 200 CVE-sourced C/C++ vulnerabilities and 100 vulnerabilities from OSS-Fuzz. We directly report the results of OpenHands, SWE‑Agent, and Aider from the SEC‑Bench leaderboard produced by the original paper Lee et al. (2025); these methods were evaluated only on the 200 CVE instances, as the 100 OSS‑Fuzz cases were added later. For Smolagents, we build and run all configurations on the full set of 300 instances. We follow the same experimental setup as SEC-Bench Lee et al. (2025). Each agent receives a vulnerability description—including sanitizer reports and call‑stack information—and the vulnerable repository at the exact commit where the issue occurs. The agent then interacts with a fully prepared Docker environment that contains all dependencies, build scripts, and PoC execution scripts, enabling reproduction and verification of the vulnerability. A repair is considered correct if the patched code compiles, prevents the original PoC from triggering the sanitizer error during reproduction, and does not introduce new sanitizer‑detectable issues. Following SEC‑Bench Lee et al. (2025), we measure the success rate as the number of successfully repaired instances divided by the total number of instances tested. Results. Table I presents the experimental results of AgenticRepair and the six baseline approaches, measured by success rate. AgenticRepair achieves the highest overall success rate of 73% (220/300), outperforming the strongest Smolagents baseline (GPT‑5.2) by 29% and successfully repairing 86 additional vulnerabilities. On the 200 CVE‑sourced vulnerabilities, AgenticRepair reaches a success rate of 75% (150/200), exceeding state‑of‑the‑art agentic frameworks—OpenHands, SWE‑Agent, and Aider—by 41–52%, and outperforming the strongest Smolagents baseline (GPT‑5.2) by a 30% margin. For the 100 OSS‑Fuzz instances, AgenticRepair achieves a 70% success rate (70/100), repairing 26 more vulnerabilities than the strongest Smolagents baseline (GPT‑5.2). These results demonstrate the effectiveness of AgenticRepair. By engineering a unified multi-faceted program context C that integrates program-structure insights, runtime-execution behavior, and commit-history patterns, AgenticRepair substantially outperforms existing agentic repair approaches that rely solely on basic tool execution and LLM reasoning. This combination of program context leads to consistently higher repair success across both CVE and OSS‑Fuzz vulnerabilities. We present php.ossfuzz-42501106 as a concise single-file case study, in which only AgenticRepair successfully generates a repair that addresses the vulnerability at its root cause. The vulnerability is a heap-use-after-free in closure teardown: a closure created from a CALL_VIA_TRAMPOLINE path stores function_name from trampoline state, but zend_free_trampoline() is called immediately afterward, so later zend_closure_free_storage() releases a dangling zend_string*. Runtime execution context (execC_exec) confirms this with a heap-use-after-free in zend_string_release and a backtrace through zend_closure_free_storage, showing a second release on already-freed string memory (see Figure 5). Code-structure context (structC_struct) identifies the ownership mismatch in zend_create_closure_from_callable and zend_closure_from_frame: both functions used borrowed function_name pointers even though closure teardown assumes ownership and calls zend_string_release. Commit-history context (histC_hist) further explains origin and intent: prior closure fixes introduced special handling to keep call-magic names stable, but left inconsistent ownership across trampoline pathways. Guided by these contexts, the patch generated by our AgenticRepair (Figure 4) updates both construction sites to use zend_string_copy(...) before zend_free_trampoline(...), so the closure now holds an independent reference until teardown. This directly fixes the lifetime invariant instead of suppressing a symptom. This case study illustrates how multi-faceted context engineering enables AgenticRepair to diagnose the precise ownership mismatch and generate a minimal, semantically correct patch directly from the root cause. Figure 4: Patch generated by AgenticRepair for php.ossfuzz-42501106. The top hunk shows the change in zend_create_closure_from_callable and the bottom hunk shows the change in zend_closure_from_frame. The red-to-green edits (deleted borrowed pointer assignments, added zend_string_copy calls, and explanatory comments) directly reflect the ownership mismatch identified by the three contexts. Figure 5: Runtime execution context (execC_exec) for php.ossfuzz-42501106. The backtrace shows the release path zend_closure_free_storage() → zend_string_release() on a previously freed zend_string* pointer (heap-use-after-free / double-release pattern). (RQ2) What are the contributions of the components of our AgenticRepair? Approach. To address this RQ, we investigate the contribution of each component within AgenticRepair. AgenticRepair integrates three forms of program context: code‑structure context, runtime‑execution context, and commit‑history context. To quantify the contribution of each context, we compare AgenticRepair against three ablated variants: “w/o Code‑Structure Context”, “w/o Program‑Execution Context”, and “w/o Commit‑History Context”. In addition to these components, AgenticRepair also incorporates a multi‑agent scaffolding design and a specific base‑model configuration. To assess their contributions, we further compare AgenticRepair with three additional variants: “w/ Single‑Agent Scaffold” to evaluate the effect of scaffolding, and “AgenticRepair(GPT‑5‑Mini)” and “AgenticRepair(GPT‑5‑Nano)” to examine the impact of base‑model size. We conduct this ablation study on the 200 CVE‑sourced vulnerabilities in SEC‑Bench, which provide a representative and sufficiently large subset for isolating component‑level effects. As shown in Table I, performance trends on the CVE subset are consistent with those observed on the full 300‑instance benchmark, making it an appropriate and cost‑effective basis for ablation. We report the repair success rate under three modes—generous, medium, and strict—which differ in how they use the program’s exit code when running the PoC to check whether the patch succeeds. In the generous mode, a repair is successful if the patch applies, compiles, and the PoC runs without sanitizer errors or timeouts. The medium mode additionally requires the exit code to match the benchmark’s expected value. The strict mode is the most conservative, requiring an exit code of exactly 0 in addition to the common criteria above, meaning the generated repair must allow the PoC to execute normally and terminate without any errors. We include all three modes to reveal how each ablated component affects repair outcomes under different exit‑code requirements, while we report strict‑mode results for RQ1 to provide the most conservative and reliable estimate of overall repair accuracy. Results. Table I presents the ablation results for the components of AgenticRepair. Across generous, medium, and strict modes, all configurations follow the same qualitative pattern, so we base our analysis on the strict setting. Removing any single program context leads to only small drops (−0.5-0.5% to −2.0-2.0%), showing that no single context is solely responsible for performance. Instead, each pair of remaining program contexts continues to support strong repair accuracy, indicating that the three context types are complementary and collectively strengthen our AgenticRepair approach rather than acting as isolated drivers. In contrast, replacing the multi‑agent scaffold with a single‑agent setup causes a sharp decline (−44.5-44.5%), even though all insights remain available. This suggests that a single subagent struggles to process and think over the long, multi-source context, whereas the multi‑agent scaffold effectively distributes the cognitive load and enables more reliable use of the insights. Base‑model capacity also plays a substantial role: even with all insights and the multi‑agent scaffold intact, replacing GPT‑5.2 with GPT‑5‑Mini reduces performance by 25%, and GPT-5-Nano falls to only 10% success rate, indicating that larger models are substantially more capable of interpreting the provided insights and producing correct patches. Overall, the ablation results show that the performance of AgenticRepair stems from the combined effect of its multi-faceted program context, multi‑agent scaffolding, and sufficiently capable base model, each providing an essential contribution and collectively validating our design rationale. VI Discussion In the previous section, we showed that AgenticRepair achieves a 73% success rate (220/300) on the full SEC-Bench dataset, driven by the complementary interplay of multi-faceted program context, multi-agent scaffolding, and base-model capacity. To better understand how our approach enables effective repairs—and why failures persist—we analyze the following four aspects: (1) the semantic alignment between generated patches and reference repairs, (2) the distribution and root causes of the 80 failures under SEC-Bench’s taxonomy, (3) tool-calling trajectories that reveal subagent specialization and effort, and (4) performance variation across repositories and vulnerability categories. VI-A Patch Similarity to Reference Repairs SEC-Bench provides a reference (gold) patch for each benchmark instance Lee et al. (2025). To examine whether AgenticRepair succeeds by reproducing these reference patches, we compare each generated patch from the main strict run against the corresponding gold patch using three similarity measures. First, exact diff equality checks whether the generated patch is textually identical to the reference patch. Second, patch-line Jaccard similarity measures textual overlap between the two patches by computing the Jaccard index between their sets of modified lines, defined as |Lg∩Lr|/|Lg∪Lr||L_g∩ L_r|/|L_g∪ L_r|, where LgL_g and LrL_r denote the modified-line sets of the generated and reference patches. Third, file-level Jaccard similarity compares the sets of files modified by the two patches, capturing whether they operate in the same repair region even when the specific edits differ. Across the 300 instances, AgenticRepair submits 298 patches, yet none exactly matches the gold patch. The average normalized patch-line Jaccard similarity is 0.1177 (median 0.0869), and the average content-only similarity is 0.0561, indicating minimal textual overlap with the reference patches. In contrast, the average file-level Jaccard similarity is 0.5836, suggesting that the generated repairs often target similar regions of the codebase while introducing substantially different edits. Furthermore, 296 of the 298 patches fall below 0.70 normalized patch-line similarity, with only two cases in the 0.70–0.90 range. These results indicate that AgenticRepair rarely reproduces the benchmark patches and instead synthesizes alternative repairs. VI-B Failure Analysis of AgenticRepair Following the failure analysis taxonomy introduced in SEC-Bench Lee et al. (2025), we examined the 80 failures produced by AgenticRepair across its evaluation on the full 300-instance SEC-Bench dataset. These failures fall into four categories: No Patch (NP) — the agent terminated without outputting any candidate patch; Improper Format (IF) — the agent produced a patch, but in an invalid or non-applicable format; Compilation Error (CE) — the generated patch failed to compile; and Still Vulnerable (SV) — the patch compiled successfully, but the vulnerability remained exploitable under sanitizer testing. In addition, we measure the patch breadth of both successful and failed instances as the total number of lines edited and the number of files modified by each submitted patch to further characterize the behavior of successful versus failed repairs. Figure 6 presents the distribution of the four failure types and the patch breadth of both successful and failed repairs. IF is the dominant failure type, accounting for 53 of the 80 failures (66.2%), followed by SV with 25 cases (31.2%). NP is rare, with only two instances, and no CE failures are observed in the main run. These results indicate that AgenticRepair’s failures rarely stem from producing uncompilable code; rather, they more often arise from issues in patch construction or validation after a repair candidate has been generated. On the other hand, successful patches edit a median of 32 lines across one file, whereas failed submitted patches modify a median of 47.5 lines across two files. The failed-patch distribution is also substantially heavier-tailed: 13 failed submitted patches exceed 500 edited lines, compared with only two successful patches, and 10 failed patches touch more than five files, compared with only four successful patches, despite the much larger number of successes. This pattern suggests that many failures stem from overbroad or unstable repair candidates. Figure 6: Failure analysis of AgenticRepairon the 300 instances. (a) Distribution of failures under SEC-Bench’s taxonomy Lee et al. (2025). (b) Combined patch-breadth comparison between successful and failed submitted patches, reporting median edited lines and median modified-file counts. To provide a more fine-grained understanding of failures, we conduct a dynamic runtime-based attribution analysis Ma et al. (2025); Zhang et al. (2025) over the 80 failed trajectories of AgenticRepair. This analysis identifies the earliest unrecoverable step (t∗t^*) at which failure becomes inevitable, and examines the corresponding subagent outputs and execution states to localize root causes. • Git apply corrupt patch (53 cases). Failures arise immediately during patch application in repairA_repair. The dominant cause is the generation of syntactically invalid or truncated diffs. Inspection of failure traces shows that many of these cases could be avoided with a simple pre-application validation and regeneration step. • PoC harness-fatal runtime validity error (22 cases). These failures stem from a misalignment between the sanitizer-oriented repair objective and the full acceptance conditions enforced by the PoC harness (e.g., parsing or semantic checks). The traces suggest that incorporating functional failure signals into execA_exec would reduce this class. • Infrastructure/container termination (2 cases). Failures are caused by external runtime issues (e.g., container crashes) before repair completion, and are not attributable to subagent behavior. • PoC timeout (1 case) and OOM/resource exhaustion (2 cases). In these cases, generated patches fail to eliminate execution paths that trigger timeouts or excessive resource consumption. The observed execution patterns indicate that exposing such resource-related signals to the subagents would enable earlier avoidance. Across all categories, failures can be traced to specific decision points where the system either produces invalid repair artifacts or optimizes against incomplete execution signals. Notably, a large proportion of failures originates at the final repair synthesis stage, where the generated patch does not satisfy downstream execution constraints despite available contextual signals. Actionable insights. The attribution results motivate two concrete improvements for future work: (1) introducing a lightweight patch-integrity check before git apply, and (2) extending verification to incorporate functional correctness and resource constraints alongside sanitizer outcomes. Together, these changes would address 75 out of 80 failures (93.8%). Overall, dynamic runtime-based trajectory attribution provides a fine-grained account of where and why failures occur, highlighting the central role of patch validity and execution-aware verification in further improving the performance. VI-C Subagent Trajectory Patterns of AgenticRepair To better understand how AgenticRepair uses its tools during repair, we analyze the tool-calling trajectory of the four specialized subagents in AgenticRepair. Figure 7 shows the per-turn normalized tool activity for the code-structure Subagent, runtime-execution subagent, commit history subagent, and repair subagent. Figure 7: Per-turn tool-usage density across AgenticRepairtrajectories, separated by subagent role. A clear pattern is early role specialization. In the first few turns, each context engineering subagent strongly emphasizes its dedicated tools: the code-structure subagent is initially CodeQL-heavy, the runtime-execution subagent begins with runtime-inspection tools such as GDB and Valgrind, and the commit history subagent begins with the PyDriller tool for repository mining. After the specialized early steps, all three shift toward the command-line tool for repository inspection. This behavior contrasts with the single-agent trajectories in SEC-Bench, where one agent must continuously interleave inspection, reasoning, and action throughout the task Lee et al. (2025). In AgenticRepair, the early analysis burden is explicitly decomposed across specialized roles. The repair subagent uses more interaction turns and primarily relies on command-line and GDB tools to verify the multi-faceted program context provided by the other three subagents and synthesize a repair patch. Across the 298 available trajectories, it averages 28 steps, compared with only 7–9 average steps for the upstream subagents, and it accounts for 8,616 total tool calls, 96.0% of which use cmd. This indicates that the main difficulty in vulnerability repair is not merely collecting isolated signals, but repeatedly integrating, testing, and refining those signals inside the final repair loop. Taken together, the trajectory patterns suggest that AgenticRepair’s multi-agent scaffold successfully front-loads diagnosis through role specialization. The dominant remaining cost lies in converting the multi-faceted program context into a concrete patch that applies and passes verification. VI-D Performance Across Projects and Vulnerability Categories To analyze the performance of AgenticRepair across different projects and vulnerability categories, we compute repair success rates by repository and vulnerability category in SEC-Bench. For the project-level analysis, we focus on repositories with at least five instances, as many projects in the benchmark contribute only one or two cases. For the vulnerability-category analysis, we categorize the 300 instances into seven groups: buffer overflow/out-of-bounds, null dereference, use-after-free, leak/resource misuse, invalid free/double free, uninitialized / type confusion, and other memory-safety issues. Figure 8 illustrates success rates for these projects. Across the larger project groups, AgenticRepair achieves 90.3% success on ImageMagick (28/31), 85.0% on LibreDWG (17/20), 80.0% on mruby (32/40), and 76.7% on GPAC (33/43). Performance is lower on libxml2 (64.5%, 20/31) and php-src (63.2%, 12/19), and particularly low on exiv2 (20.0%, 2/10). A closer inspection of exiv2 suggests that the low score is not primarily due to edits being applied to incorrect locations: all eight failed cases still overlap the gold patch at the file level but fail at the git apply step. Moreover, these failed patches are unusually broad, with a median of 2,038.5 edited lines across six files, compared with medians of only 25–64 edited lines across one to two files for other large projects. In contrast, the two successful exiv2 repairs are narrow single-file edits that match the gold patch file set exactly. These results demonstrate the effectiveness of AgenticRepair across a diverse range of open-source repositories, achieving consistently high success rates on several large and complex projects. Figure 8: Repair success rate by project on the 300-instance strict run. Shown are projects with at least five benchmark instances, sorted by instance count. Bar labels report success count and rate. Figure 9 shows performance across vulnerability categories. Buffer-overflow and out-of-bounds vulnerabilities form the largest group with 150 instances and a 74.7% success rate, followed by null dereferences with 52 instances and a 73.1% success rate, and use-after-free cases with 51 instances and a 68.6% success rate. Smaller categories exhibit greater variance, including 71.4% for leak or resource-misuse cases (10/14) and 33.3% for invalid-free or double-free cases (2/6). Overall, these results suggest that AgenticRepair is broadly effective across major memory-safety vulnerability classes, while repairs involving complex object lifetime and deallocation semantics—particularly use-after-free and invalid/double-free cases—remain more challenging. Figure 9: Vulnerability-category success rates. Categories are inferred from benchmark text via rule matching; buckets with at least six instances. VII Threats to Validity Data Contamination. A potential threat to validity is that the base model may have been exposed to portions of the SEC-Bench dataset during pre-training. To mitigate this threat, we conducted a patch similarity analysis comparing AgenticRepair’s generated patches with the corresponding gold patches. None of the 298 generated patches exactly matched the ground truth. The average normalized patch-line Jaccard similarity is 0.1177, while content-only similarity is even lower at 0.0561. Although file-level overlap is higher (average 0.5836), the very low textual similarity indicates that AgenticRepair synthesizes novel repairs rather than reproducing memorized patches. Non-determinism of LLMs. Large language models are inherently non-deterministic, which can affect reproducibility. To mitigate this threat, we release the complete AgenticRepair framework as open source, including all prompts, tool implementations, orchestration logic, and experimental configurations, along with a ready-to-run replication package. Generalizability. Our evaluation focuses on SEC-Bench, a benchmark designed to approximate realistic vulnerability repair scenarios in C/C++, grounded in real-world codebases and commit-level patches across diverse vulnerability types. While the benchmark provides meaningful evidence, further studies are needed to assess generalizability to other programming languages and vulnerability types beyond the vulnerabilities covered in SEC-Bench. VIII Conclusion In this paper, we present AgenticRepair, the first agentic vulnerability repair framework that operationalizes multi-faceted program context engineering for automated vulnerability repair. AgenticRepair orchestrates three specialized context engineering subagents that operate in parallel to engineer code-structure, runtime-execution, and commit-history contexts — facets routinely assembled by security engineers in practice — and embeds them into a persistent episodic memory that grounds a dedicated repair subagent throughout patch synthesis. Evaluated on SEC-Bench comprising 300 real-world vulnerable instances, AgenticRepair achieves the best 73% success rate (220/300) against other baselines. Notably, 40% of successful repairs involve edits spanning multiple files, demonstrating AgenticRepair’s capacity to handle complex, cross-file security vulnerabilities. These findings lead us to conclude that engineering multi-faceted program context is a key design principle for effective agentic vulnerability repair, bridging the gap between how security engineers diagnose vulnerabilities in practice and how agentic AI approaches assemble program understanding for vulnerability repair. References Aider (2026) Aider. Note: Accessed: 2026-02-26 External Links: Link Cited by: §I-C, §IV-C. G. Bhandari, N. Gavric, and A. Shalaginov (2025) Generating vulnerability security fixes with code language models. Information and Software Technology 185, p. 107786. Cited by: §I, §I-A. G. Bhandari, A. Naseer, and L. Moonen (2021) CVEfixes: automated collection of vulnerabilities and their fixes from open-source software. In Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering, p. 30–39. Cited by: §IV-B. A. Bosu, J. C. Carver, M. Hafiz, P. Hilley, and D. Janni (2014) Identifying the characteristics of vulnerable code changes: an empirical study. In Proceedings of the 22nd ACM SIGSOFT international symposium on foundations of software engineering, p. 257–268. Cited by: §I. I. Bouzenia, P. Devanbu, and M. Pradel (2025) Repairagent: an autonomous, llm-based agent for program repair. In 2025 IEEE/ACM 47th International Conference on Software Engineering (ICSE), p. 2188–2200. Cited by: §I, §I, §I-C, §I-D, §IV-A. Y. Chen, Z. Ding, L. Alowain, X. Chen, and D. Wagner (2023) Diversevul: a new vulnerable source code dataset for deep learning based vulnerability detection. In Proceedings of the 26th international symposium on research in attacks, intrusions and defenses, p. 654–668. Cited by: §IV-B. Z. Chen, S. Kommrusch, and M. Monperrus (2022) Neural transfer learning for repairing security vulnerabilities in c code. IEEE Transactions on Software Engineering 49 (1), p. 147–165. Cited by: §I, §I-A. J. Fan, Y. Li, S. Wang, and T. N. Nguyen (2020) AC/c++ code vulnerability dataset with code changes and cve summaries. In Proceedings of the 17th international conference on mining software repositories, p. 508–512. Cited by: §IV-B. M. Fu, V. Nguyen, C. Tantithamthavorn, D. Phung, and T. Le (2024a) Vision transformer inspired automated vulnerability repair. ACM Transactions on Software Engineering and Methodology 33 (3), p. 1–29. Cited by: §I, §I-A. M. Fu, C. K. Tantithamthavorn, V. Nguyen, and T. Le (2023) Chatgpt for vulnerability detection, classification, and repair: how far are we?. In 2023 30th Asia-Pacific Software Engineering Conference (APSEC), p. 632–636. Cited by: §I, §I-B. M. Fu, C. Tantithamthavorn, T. Le, Y. Kume, V. Nguyen, D. Phung, and J. Grundy (2024b) Aibughunter: a practical tool for predicting, classifying and repairing software vulnerabilities. Empirical Software Engineering 29 (1), p. 4. Cited by: §I, §I-A. M. Fu, C. Tantithamthavorn, T. Le, V. Nguyen, and D. Phung (2022) Vulrepair: a t5-based automated software vulnerability repair. In Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering, p. 935–947. Cited by: §I, §I-A. X. Gao, B. Wang, G. J. Duck, R. Ji, Y. Xiong, and A. Roychoudhury (2021) Beyond tests: program vulnerability repair via crash constraint extraction. ACM Transactions on Software Engineering and Methodology (TOSEM) 30 (2), p. 1–27. Cited by: §I. K. Huang, J. Zhang, X. Bao, X. Wang, and Y. Liu (2025) Comprehensive fine-tuning large language models of code for automated program repair. IEEE Transactions on Software Engineering 51 (4), p. 904–928. Cited by: §I, §I-B. M. Jiang, J. Jiang, T. Wu, Z. Ma, X. Luo, and Y. Zhou (2024) Understanding vulnerability inducing commits of the linux kernel. ACM Transactions on Software Engineering and Methodology 33 (7), p. 1–28. Cited by: §I. H. Lee, Z. Zhang, H. Lu, and L. Zhang (2025) Sec-bench: automated benchmarking of llm agents on real-world software security tasks. arXiv preprint arXiv:2506.11791. Note: To appear in NeurIPS 2025 Cited by: §I, §I-C, §I-D, §IV-A, §IV-B, §V, Figure 6, Figure 6, §VI-A, §VI-B, §VI-C. H. Lee (2025) SEC-bench: can llm agents solve critical security challenges?. Note: https://sec-bench.github.io/ Cited by: §I. M. Ma, J. Zhang, F. Yang, Y. Kang, Q. Lin, S. Rajmohan, and D. Zhang (2025) DoVer: intervention-driven auto debugging for llm multi-agent systems. arXiv preprint arXiv:2512.06749. Cited by: §VI-B. X. Mei, P. S. Singaria, J. Del Castillo, H. Xi, T. Bao, R. Wang, Y. Shoshitaishvili, A. Doupé, H. Pearce, B. Dolan-Gavitt, et al. (2024) Arvo: atlas of reproducible vulnerabilities for open source software. arXiv preprint arXiv:2408.02153. Cited by: §IV-B. mity (2021) Use of uninitialized value in the md_analyze_line() function. Note: GitHub issue #155 in mity/md4cCVE-2021-30027 External Links: Link Cited by: Figure 2, Figure 2. P. Rondon, R. Wei, J. Cambronero, J. Cito, A. Sun, S. Sanyam, M. Tufano, and S. Chandra (2025) Evaluating agent-based program repair at google. In 2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP), p. 365–376. Cited by: §I, §I-C, §I-D, §IV-A. A. Roucher, A. V. del Moral, T. Wolf, L. von Werra, and E. Kaunismäki (2025) ‘Smolagents‘: a smol library to build great agentic systems.. Note: https://github.com/huggingface/smolagents Cited by: §I-C, §IV-C. Y. Roumani (2021) Patching zero-day vulnerabilities: an empirical analysis. Journal of Cybersecurity 7 (1), p. tyab023. Cited by: §I. X. Wang, B. Li, Y. Song, F. F. Xu, X. Tang, M. Zhuge, J. Pan, Y. Song, B. Li, J. Singh, et al. (2024) Openhands: an open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741. Cited by: §I-C, §IV-C. Z. Wang, T. Shi, J. He, M. Cai, J. Zhang, and D. Song (2025) CyberGym: evaluating ai agents’ cybersecurity capabilities with real-world vulnerabilities at scale. arXiv e-prints, p. arXiv–2506. Cited by: §IV-B. X. Wen, Z. Lin, Y. Yang, C. Gao, and D. Ye (2025) Vul-r2: a reasoning llm for automated vulnerability repair. In 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE), p. 26–38. Cited by: §I, §I-B. C. S. Xia, Y. Deng, S. Dunn, and L. Zhang (2024) Agentless: demystifying llm-based software engineering agents. arXiv preprint arXiv:2407.01489. Cited by: §I, §I-C, §I-D. C. S. Xia and L. Zhang (2024) Automated program repair via conversation: fixing 162 out of 337 bugs for $0.42 each using chatgpt. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, p. 819–831. Cited by: §I, §I-B. F. Yamaguchi, N. Golde, D. Arp, and K. Rieck (2014) Modeling and discovering vulnerabilities with code property graphs. In 2014 IEEE symposium on security and privacy, p. 590–604. Cited by: §I. J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press (2024) Swe-agent: agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37, p. 50528–50652. Cited by: §I, §I-C, §IV-C. S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. R. Narasimhan, and Y. Cao (2022) React: synergizing reasoning and acting in language models. In The eleventh international conference on learning representations, Cited by: §I-C. S. Zhang, M. Yin, J. Zhang, J. Liu, Z. Han, J. Zhang, B. Li, C. Wang, H. Wang, Y. Chen, et al. (2025) Which agent causes task failures and when? on automated failure attribution of llm multi-agent systems. arXiv preprint arXiv:2505.00212. Cited by: §VI-B. Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury (2024) Autocoderover: autonomous program improvement. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis, p. 1592–1604. Cited by: §I, §I-C, §I-D. X. Zhou, K. Kim, B. Xu, D. Han, and D. Lo (2024) Out of sight, out of mind: better automatic vulnerability repair by broadening input ranges and sources. In Proceedings of the IEEE/ACM 46th international conference on software engineering, p. 1–13. Cited by: §I, §I-A.

Instant research discovery