arXiv CSopen access

Knowledge-Enhanced Agentic Vulnerability Repair

Knowledge-Enhanced Agentic Vulnerability Repair Sicong Cao† , Hao Ma† , Le Yu† , Kangyi Ding‡ , Xiaolei Liu‡ , Terry Yue Zhuo§ , Bo Wang¶ , Xingwei Lin♢ , Xiaobing Sun♠ , Linzhang Wang♣ , David Lo♡

arXiv:2607.00820v1 [cs.SE] 1 Jul 2026

†

Nanjing University of Posts and Telecommunications ‡ National Interdisciplinary Research Center of Engineering Physics § Alibaba Qwen ¶ Beijing Jiaotong University ♢ Zhejiang University ♠ Yangzhou University ♣ Nanjing University ♡ Singapore Management University

Limitations. While promising, existing LLM-based approaches suffer from two fundamental Limitations. L1: Unreliable Root Cause Analysis. Identifying the root cause of a vulnerability and providing an optimal code location to apply patches is typically the gold standard in most AVR approaches [8], [9], [13]. However, this assumption does not align with the reality faced by developers: even the state-of-theart localization tool struggles to precisely pinpoint the exact statements that need to be fixed [17]. More importantly, root causes often do not intersect with the fix location, in fact they may be far apart [18]. Instead, agentic AVR approaches [15], [16] delegate localization entirely to the LLM. Given a sanitizer report, the patching agent reasons about the vulnerability, supplemented by the context retrieved from the project codebase. Unfortunately, due to the inherent hallucination issue [19], solely relying on the internal knowledge and free-form reasoning of LLMs is not enough. Additionally, the demand for sanitizer report that only applicable to memory safety issues significantly constrains their generalizability. L2: Insufficient Utilization of Vulnerability knowledge. Despite powerful reasoning capabilities, LLMs have been proven to still require some guidance in orchestrating the steps for fixing [20], [21]. A straightforward countermeasure is RAG, I. I NTRODUCTION which dynamically retrieves a set of similar vulnerability-patch As the cybersecurity capabilities of frontier foundation pairs as references, as prior works [14], [22] do. Nevertheless, models like Claude Mythos [1] and GPT-5.5-Cyber [2] continue naive retrieval strategies are suboptimal as they primarily focus to evolve, the cost and effort required to find and exploit on surface-level code similarity, neglecting the deeper causesoftware vulnerabilities have all dropped dramatically. As of level logical similarities that are critical in patch generation May 2026, the public Common Vulnerabilities and Exposures [23]. Although APPatch [13] alleviates this problem to some (CVE) program [3] has disclosed 29,120 new vulnerabilities, an extent by prompting the LLMs to select historical exemplars increase of approximately 39.89% year-over-year. The resulting that closely match the root cause of the sample to be patched, backlog far outpaces the resources available to triage them, it still suffers from the precision and scalability issues. creating a strong demand for tools that can quickly generate Our Work. To tackle the above two challenges, we procorrect patches for known vulnerabilities [4]. pose K EA R EPAIR, a novel Knowledge-Enhanced Agentic Existing Efforts. Recent progresses in Large Language Models vulnerability Repair approach. The key insights underlying (LLMs) have sparked interest in their application to Automated K EA R EPAIR include: (❶) reliable vulnerability causes should Vulnerability Repair (AVR) [5], primarily due to their superior be derived from verified program facts rather than purely reasoning capabilities compared to traditional rule-intensive [6], static LLM reasoning, as well as (❷) high-level vulnerability [7] or popular data-driven approaches [8], [9]. Early attempts knowledge from historical fixes helps filter out superficially primarily follow the one-step repair paradigm, employing similar exemplars with divergent repair patterns. Specifically, prompt engineering [10], reinforcement learning [11], [12], K EA R EPAIR consists of three tightly coupled phases. First, or Retrieval-Augmented Generation (RAG) [13] to directly inspired by that most vulnerabilities can be modeled from the output candidate patches. Afterwards, a series of LLM-based view of control- or data-flow, K EA R EPAIR characterizes and patching agents [14]–[16] have been proposed to autonomously distills view-specific multi-dimensional vulnerability knowllocalize faults and synthesize patches in an iterative workflow. edge under the supervision of ground-truth patches, with Abstract—Frontier foundation models have significantly accelerated vulnerability discovery while slashing costs, but the bigger challenge is how the remediation side keeps up. Despite recent progresses in Automated Vulnerability Repair (AVR), current solutions struggle to reliably pinpoint vulnerability causes, and insufficiently utilize the prior fix knowledge to guide the patch generation process, undermining their effectiveness in practice. To address this gap, we propose K EA R EPAIR, a novel agentic AVR approach that grounds patch generation in verified program facts and high-level vulnerability knowledge. Specifically, K EA R EPAIR first extracts dual-view multi-dimensional knowledge items from historical vulnerability-patch pairs, and constructs dedicated retrieval knowledge bases. It then employs a toolaugmented agent that performs ReAct-style reasoning to collect verified program facts for vulnerability diagnosis. Finally, based on the diagnostic results, K EA R EPAIR performs knowledgelevel retrieval-augmented patch generation and iteratively refines patches through a closed-loop validation process. Experimental results show that K EA R EPAIR significantly outperforms existing AVR approaches on 55 reproducible C/C++ vulnerabilities. When paired with Gemini-3.1-Pro, KeaRepair successfully repairs 46 vulnerabilities, achieving a repair rate of 83.64%. Moreover, K EA R EPAIR fixes nine unique vulnerabilities that the state-of-theart baseline PatchAgent cannot address, and further demonstrates strong cross-language generalizability.

dedicated knowledge bases for exemplar retrieval. Second, proposed to improve automation by learning repair patterns instead of assuming perfect localization or asking an LLM from historical vulnerability-patch pairs. They typically frame to infer the vulnerability cause from incomplete symptoms, the task as a sequence-to-sequence problem and operate at the K EA R EPAIR leverages a set of specialized static analysis tools function-level. For example, VulRepair [8] incorporates preto actively gather verified program facts from the vulnerable trained CodeT5 to learn better code representations for patch code, thereby minimizing inherent hallucinations of LLMs. generation, while VulMaster [9] augments its fine-tuning dataset Third, with the structured diagnostic report, K EA R EPAIR with CWE knowledge to further improve performance. Most constructs view-specific semantic queries to retrieve relevant recently, LLM-based approaches have shown promise due to historical exemplars as well as their corresponding knowledge the ability to generalize from a vast amount of data [5]. Pearce items, and synthesizes candidate patches. et al. [10] systematically examines LLMs’ patch generation Evaluation. We implement a prototype system of K EA R EPAIR, capability in zero-shot settings, highlighting that they still and conduct comparative experiments with eight state-of- struggle to generate plausible fixes in real-world scenarios. the-art AVR approaches [7]–[9], [13], [14], [24]–[26] on San2Patch [16] employs multi-stage reasoning with LLMs to 55 reproducible C/C++ vulnerabilities sourced from V UL 4C generate patches using only sanitizer logs and source code. [17]. Experimental results show that K EA R EPAIR substantially Software Engineering Agents. LLM agents, hereinafter also outperforms all studied approaches. In particular, when paired referred to as agents for short, are AI systems that autonomously with Gemini-3.1-Pro, K EA R EPAIR achieves the optimal cost- execute complex tasks by equipping LLMs with the capabilities benefit trade-off, repairing 83.64% (46/55) of vulnerabilities of perceiving and utilizing external resources and tools. In at a lower cost ($0.30) and within practical timeframes (under recent years, a number of agent-driven solutions have been 50 seconds) per vulnerability. More importantly, K EA R EPAIR proposed to complete real-world software engineering tasks is able to fix nine unique CVEs that the best-performing [28], such as GitHub issue resolution [29]. For example, SWEbaseline PatchAgent cannot address. In addition, K EA R EPAIR agent [30] designs an Agent-Computer Interface (ACI) to bridge demonstrates remarkable generalizability to more complex LLMs and terminal environments via structural tool interactions, vulnerabilities in other programming languages [27], yielding while Atomizer [31] introduces a collaborative multi-agent a success rate of up to 85.55% (148/173). framework to untangle composite commits by inferring the Contributions. This paper makes the following contributions: intent of each code change and iteratively self-correcting. • New Dimension. We identify and address two key challenges III. M OTIVATION of existing LLM-based AVR approaches: unreliable root To illustrate the fundamental limitations of existing LLMcause analysis and insufficient knowledge utilization. based AVR approaches and motivate the key insights of our • Novel Approach. We propose K EA R EPAIR , a novel agentic AVR approach. By grounding patch generation in ver- approach, we use a real-world vulnerability CVE-2017-6828 ified program facts and multi-dimensional vulnerability [32] from audiofile as a running example. knowledge, K EA R EPAIR effectively alleviates the inherent hallucination issue of purely static LLM reasoning while A. Motivating Example sufficiently unleashing their in-context learning capabilities. As shown in Fig. 1 (left), in the case of WAVE_FORMAT_ADPCM, • Extensive Study. We evaluate K EA R EPAIR against a rigor- a 16-bit unsigned integer numCoefficients is read directly ous benchmark of 55 reproducible C/C++ vulnerabilities. The from an untrusted WAV file (line 280) to determine how many experimental results demonstrate that K EA R EPAIR achieves iterations should perform. To avoid the loop from executing superior performance across all vulnerabilities types by lever- far more times than the array m_msadpcmCoefficients can aging diverse LLM backbones, significantly outperforming accommodate, an assert statement is applied (line 7) to validate prior approaches. The extensive cross-language evaluation whether the value of numCoefficients falls within an expected further reveals the strong generalizability of K EA R EPAIR. range (between 7 and 255). Nevertheless, asserts are typically eliminated when building the library with NDEBUG. As a result, II. BACKGROUND AND R ELATED W ORK the intended input validation is completely absent in producAutomated Vulnerability Repair. Research on Automated tion environments, introducing a heap-based buffer overflow Vulnerability Repair (AVR) has witnessed significant progress vulnerability that allows an attacker to supply any value up over the past two decades [4], evolving from search-based to 65,535 that past the bounds of m_msadpcmCoefficients. To and template-guided to more intelligent approaches. One such fix this vulnerability, developers add a robust runtime check approach is Senx [6], which uses heuristic rules to identify that executes in all build configurations (lines 8-13) to ensure safety properties violated by vulnerabilities, and then generates the number of coefficients is within the array range. predicates for patch synthesis. Another notable approach is ExtractFix [26], which employs symbolic execution to derive ☞ Observation 1 ▶ Symbolic localization tools or agentic crash-free constraints from a PoC and transforms them to reasoning alone struggles to reliably identify root causes. ◀ candidate patches, without relying on extensive test suites. As vulnerabilities grow in volume and complexity, a series As a prerequisite for initiating the patching process, vulnerof learning-based approaches [8], [9], [24], [25] have been ability localization aims to find a program point at which the

1 case WAVE_FORMAT_ADPCM: 2 { 3 uint16_t bitsPerSample, extraByteCount, 4 samplesPerBlock, numCoefficients; 5 [...] // omit 10 lines 6 readU16(&numCoefficients); 7 assert(numCoefficients >= 7 && numCoefficients <= 255); 8 + if (numCoefficients < 7 || numCoefficients > 255) 9 + { 10 + _af_error(AF_BAD_HEADER, 11 + "Bad number of coefficients"); 12 + return AF_FAIL; 13 + } 14 m_msadpcmNumCoefficients = numCoefficients; 15 for (int i=0; i<m_msadpcmNumCoefficients; i++) 16 { 17 readS16(&m_msadpcmCoefficients[i][0]); 18 readS16(&m_msadpcmCoefficients[i][1]); 19 }

APPatch

LoopRepair Codebase Source/ File 1

Vulnerability Localization

Fix Locations

WAVE. cpp:7

...

File 2

--- a/source/libaudiofile/WAVE.cpp +++ b/source/libaudiofile/WAVE.cpp @@@ -7,13 +7,13 @@ 7 assert(numCoefficients >= 7 && numCoefficients <= 255); 8 m_msadpcmNumCoefficients = numCoefficients; 9 + if (m_msadpcmNumCoefficients > MSADPCM_MAX_COEFFICIENTS) 10 + { 11 + _af_error(AF_BAD_CODEC_CONFIG, 12 + "too many MS ADPCM coefficients: %u (max %u)", 13 + (unsigned)m_msadpcmNumCoefficients, 14 + (unsigned)MSADPCM_MAX_COEFFICIENTS); 15 + return AF_FAIL; 16 + } 17 for (int i=0; i<m_msadpcmNumCoefficients; i++) 18 { 19 readS16(&m_msadpcmCoefficients[i][0]);

// Selected Examplar 1: CVE-2018-16419 Given the following code slice: <slice code>, which has a CWE-119 vulnerability at line 334, please generate the patch for the vulnerability. Step 1. The root cause is that `bufsize` is assigned …... Step 2. Add a bounds check for `bufsize` before …... Step 3. Ground-truth patch: @@ 334 335 +

bufsize = file->size; bufsize = MIN(file->size, sizeof buf);

…... // Selected Examplar N Given the following code slice: <slice code>, which has a CWE-119 vulnerability at line 7, please generate five possible patches for the vulnerability. Step 1. The root cause is the use of an `assert` statement to validate the untrusted `numCoefficients` value read from the WAV file. In release builds (e.g., when `NDEBUG` is defined), the `assert` macro is stripped out by the compiler, completely removing the validation. This allows an attacker to supply a maliciously large value (up to 65,535), causing the `for` loop to write past the bounds of the fixed-size `m_msadpcmCoefficients` array, resulting in a buffer overflow. Step 2. A correct fix must replace the `assert` with a robust runtime check that executes in all build configurations (not just debug builds). Step 3. Patch Generation: --- a/source/libaudiofile/WAVE.cpp +++ b/source/libaudiofile/WAVE.cpp @@@ -7,10 +7,10 @@ 7 - assert(numCoefficients >= 7 && numCoefficients <= 255); 8 + const uint16_t kMaxMsAdpcmCoefficients = 9 + static_cast<uint16_t>(AF_ARRAY_SIZE(m_msadpcmCoefficients)); 10 + if (numCoefficients > m_msadpcmNumCoefficients) 11 + { 12 + _af_error(AF_BAD_CODEC_CONFIG, 13 + "invalid number of MS ADPCM coefficients: %u", 14 + numCoefficients); 15 + return AF_FAIL; 16 + } 17 m_msadpcmNumCoefficients = numCoefficients;

Fig. 1: An illustrative example using a real-world vulnerability (CVE-2017-6828) from the audiofile project. Note the patch is simplified to include only the relevant context for brevity. root cause of an observed program failure can be fixed [33]. Similar to prior AVR approaches [7], [8], LLM-based solutions typically assume perfect vulnerability localization, where the vulnerable function and all locations for modification are given [13], [23]. However, this assumption is unrealistic in practice as developer-provided fix locations are unavailable [34]. To tackle this issue, LoopRepair [14] employs CrashAnalysis [35], a state-of-the-art localization tool based on concolic execution, to identify root cause locations, and instructs the LLM to predict the corresponding fix locations. While effective, such a dynamic solution may suffer from significant scalability and precision issues. As shown in Fig. 1 (bottom), except the actual root cause statement (line 7), LoopRepair mistakenly pinpoints 13 faulty locations across six files, with a false positive rate of 92.86%. Another common paradigm is agentic reasoning, which prompts the LLM to autonomously analyze the crash log, localize the issue, and generate patches without human intervention [15], [16]. However, they are limited to generating patches for vulnerabilities detected by a sanitizer. ☞ Observation 2 ▶ Prior vulnerability knowledge should be better utilized to guide the patch generation process. ◀ Apart from unreliable root cause analysis, Another limitation of existing LLM-based AVR approaches is their insufficient utilization of vulnerability knowledge. As reported by Pearce et al. [10], LLMs struggle to generate plausible fixes in a zeroshot setting. An intuitive way is RAG, which feeds LLMs with

a few relevant demonstrations to provide valuable guidance [14], [21]. For example, PailGen [22] dynamically retrieves top-ranked vulnerability-patch pairs that are both lexically and semantically similar to the testing vulnerable code as external knowledge. Despite empirically validated effective, mainstream retrieval strategies (lexical-based, semantic-based, or both) rely solely on surface-level code similarity, which can lead to mismatches between the retrieved examples and the actual repair needs [23]. Instead, APPatch [13] incorporates historical exemplars that closely match the root cause of the testing sample, as well as their corresponding fixing strategies and ground-truth patches, into the prompt for patch generation. Nevertheless, with the expansion of exemplar scale, such a purely LLM-driven selection process is time-consuming and cost-expensive. In addition, even identified the root cause of the vulnerability under the guidance of developer-provided repair oracle (typically unavailable in practice), APPatch fails to produce correct patches as LLMs may be misled by exemplars with similar root causes but completely different repair strategies. As demonstrated in Fig. 1 (right), one of the selected exemplars CVE-2018-16419 [36] contains a stackbased buffer overflow vulnerability in which the variable bufsize is overwritten with file->size retrieved from the smartcard. If file->size is larger than 2048 bytes, the read operation will write data beyond the bounds of the fixed stack buffer. This vulnerability was fixed officially by capping the read buffer size to the smaller of the untrusted file size and the fixed 2048-byte capacity of the stack buffer. Unfortunately, the

Taint Trace-Guided Patch Selection Patch Ranking

Input

Vulnerability Knowledge Base Construction Knowledge Extraction

Knowledge Abstraction Knowledge Base

Vuln-Fix Pair

View-Specific Query Generation Vulnerable Program

Diagnostic Agent

Re Act

Patches

Test Suite

Verified Facts

PoCs

Cascading Knowledge Retrieval

Test Cases

Specialized Tool Set trace_data_flow is_path_reachable inspect_API_usage

Fact-Grounded Agentic Vulnerability Diagnosis

Repair Agent

Candidates

Quality Assessment

Patch Verification Fail

with crafted static analysis tools conducts iterative, demanddriven reasoning and exploration to collect verified facts related to suspicious program points. Vulnerable Program • Knowledge-Level Retrieval-Augmented Patch Generation: Vulnerable Candidate Vulnerability Hunks Patches Localization Based on the diagnostic report, K EA R EPAIR independently retrieves relevant historical samples from the constructed PoV Locationview-specific sePatch knowledge base in accordance with each Prediction Generation mantic query, and incorporatesLLMthem along with the Patchdistilled Hunks vulnerability knowledge into the prompt to synthesize a patch. The patch will be validated against Location-Aware a series Patch of Generation automated checks in a closed feedback loop. B. Vulnerability Knowledge Base Construction

Knowledge-Level RetrievalAugmented Patch Generation

Inspired by how developers understand vulnerabilities [39], K EA R EPAIR distills multi-dimensional knowledge from historFig. 2: Overview of K EA R EPAIR. ical vulnerabilities and fixes to better guide LLMs. To achieve patch generated by APPatch is neither (❶) compilable due to this, we need to address three tasks: (❶) Knowledge Extraction, the use of undefined macro AF_ARRAY_SIZE nor (❷) complete (❷) Knowledge Abstraction, and (❸) Knowledge Storage. 1) Knowledge Extraction: Different from APPatch [13], as numCoefficients should be at least 7. which characterizes vulnerabilities through single-view root APPatch 1 case WAVE_FORMAT_ADPCM: cause analysis, we independently represent and extract vulB. Key Ideas 2 { // Selected Examplar 1: CVE-2018-16419 3 uint16_t bitsPerSample, extraByteCount, knowledge from dual views, including data-flow Given the following code slice:nerability <slice code>, which has a CWE-119 vulnerability 4 samplesPerBlock, numCoefficients; Based on//the knowledge5 [...] omit above 10 lines observations, we propose a at line 334, please generate the patch for the vulnerability. 6 readU16(&numCoefficients); and control-flow, which have been proven to be essential for Step 1. The root cause is that `bufsize` is assigned …... 7 assert(numCoefficients >= 7 approach && numCoefficients <= 255); enhanced agentic AVR that jointly addresses root Step 2. Add a bounds check for `bufsize` before …... 8 + if (numCoefficients < 7 || numCoefficients > 255) understanding vulnerability semantics [38], [40]. For each view, Step 3. Ground-truth patch: 9 + analysis { cause accuracy and demonstration quality. @@ 10 + _af_error(AF_BAD_HEADER, 334 bufsize = file->size; we instruct LLMs to distill the following five knowledge items 11 + "Bad number of coefficients"); (1) agentic vulnerability diagnosis. 335 + bufsize In= MIN(file->size, sizeof buf); 12 + Fact-grounded return AF_FAIL; …... 13 + } from three dimensions with dedicated prompts. 14 of m_msadpcmNumCoefficients = numCoefficients; stead relying on purely static LLM reasoning// or dynamic Selected Examplar N 15 for (int i=0; i<m_msadpcmNumCoefficients; i++) Root Cause. This dimension describes the fundamental security 16 { localization tools, we introduce a tool-augmented diagnostic Given the following code slice: <slice code>, which has a CWE-119 vulnerability 17 readS16(&m_msadpcmCoefficients[i][0]); at line 7, please generate five possible patches for the vulnerability. issue responsible for the violation of security by comparing 18 readS16(&m_msadpcmCoefficients[i][1]); agent performs ReAct-style [37] reasoning on vulnerable 19 that } Step 1. The root cause is the use of anvulnerable `assert` statement tocode validate the untrusted the and its corresponding patch. codeLoopRepair to collect verified program facts for reliable`numCoefficients root cause ` value read from the WAV file. In release builds (e.g., when Vulnerable Behaviors. This dimension concludes the unex`NDEBUG` is defined), the `assert ` macro is stripped out by the compiler, completely Codebase analysis. These grounded facts facilitate minimizing removinginherent the validation. This allows an attacker to supply a maliciously large value pected program behaviors to 65,535), causing the `for` loop to write past the bounds of the fixed-size that raise vulnerabilities. For instance, Locations hallucinations of Vulnerability LLMs [19]Fixin subsequent patch(up generation. `m_msadpcmCoefficients ` array, resulting in a buffer overflow. ... Localization a the memory occurs when allocated memory is not freed 2. A correct fix must replace `assert` with leak a robust runtime check that (2) Knowledge-level retrieval-augmented Step patch genexecutes in all build configurations (not just debug builds). along some program path. The behavior can be described from Step 3. Patch Generation: --- a/source/libaudiofile/WAVE.cpp eration. Prior approaches suffer from suboptimal retrieval +++ b/source/libaudiofile/WAVE.cpp --- a/source/libaudiofile/WAVE.cpp three perspectives: (❶) Sensitive APIs are basic operations @@@ -7,13 +7,13 @@ +++ b/source/libaudiofile/WAVE.cpp strategies, where root cause-similar exemplars with divergent 7 assert(numCoefficients >= 7 && numCoefficients <= 255); @@@ -7,10 +7,10 @@ (e.g., malloc ) that vulnerabilities typically originate from their 8 m_msadpcmNumCoefficients = numCoefficients; 7 - assert(numCoefficients >= 7 && numCoefficients <= 255); repair easily mislead LLMs into generating invalid 9 + patterns if (m_msadpcmNumCoefficients > MSADPCM_MAX_COEFFICIENTS) 8 + const uint16_t kMaxMsAdpcmCoefficients = 10 + { improper usage; (❷) Taint Flow describes how an untrusted 9 + static_cast<uint16_t>(AF_ARRAY_SIZE(m_msadpcmCoefficients)); 11 + _af_error(AF_BAD_CODEC_CONFIG, patches. To effectively and efficiently reuse prior fix knowledge 10 + if (numCoefficients > m_msadpcmNumCoefficients) 12 + "too many MS ADPCM coefficients: %u (max %u)", 11 + { input propagate from an entry point to the security-sensitive 13 + (unsigned)m_msadpcmNumCoefficients, + _af_error(AF_BAD_CODEC_CONFIG, to unleash the potential of LLMs for patching, we12 decompose 14 + (unsigned)MSADPCM_MAX_COEFFICIENTS); 13 + "invalid number of MS ADPCM coefficients: %u", sink; and (❸) Control Branch records the specific control 15 + return AF_FAIL; 14 + numCoefficients); the single similarity metric into dual complementary views [38], 16 + } 15 + return AF_FAIL; 17 for (int i=0; i<m_msadpcmNumCoefficients; i++) conditions and precise path information, illustrating under what 16 + } 18 { including control-flow and data-flow, with dedicated 17 knowledge m_msadpcmNumCoefficients = numCoefficients; 19 readS16(&m_msadpcmCoefficients[i][0]); conditions the vulnerabilities are triggered. bases for retrieval-augmented patch generation. Fixing Strategies. This dimension summarizes the fixing solution by analyzing the vulnerability-patch pair. IV. M ETHODOLOGY Source/

WAVE. cpp:7

File 1 File 2

A. Overview

Prompt Template for Knowledge Extraction

Fig. 2 illustrates the overall workflow of K EA R EPAIR, which operates through three main phases: vulnerability knowledge base construction, fact-grounded agentic vulnerability diagnosis, and knowledge-level retrieval-augmented patch generation. • Vulnerability Knowledge Base Construction: Given a group of historical vulnerability-patch pairs, K EA R EPAIR instructs the LLM to distill view-specific multi-dimensional vulnerability knowledge under the supervision of groundtruth patches. All the knowledge items are then aggregated to form the final knowledge base for retrieval. • Fact-Grounded Agentic Vulnerability Diagnosis: For a to-be-patched vulnerability, the diagnostic agent equipped

[System Prompt] You are a senior security expert experienced in vulnerability diagnosis. Your objective is to meticulously analyze the given vulnerability-patch pair from the view of data (/control) flow to extract high-level vulnerability knowledge. [User Prompt] You are given the following information for analysis: • CVE Description: {CVE_description} • Vulnerable Function: {vuln_func} • Patched Function: {patch_func} Please perform your analysis by strictly following the

Outp

Plausi Patc

hierarchical reasoning process below. Think step-by-step: • Step 1: Code Change Comprehension. What was added, deleted, or modified to edit the vulnerable function into the patched version. • Step 2: Vulnerable Behavior Reasoning. Which securitysensitive APIs are used in the vulnerable function, and how they can be called to perform dangerous operations via a specific taint flow (/control branch). • Step 3: Pairwise Analysis. Based on the above analysis, summarize the generalizable root cause that leads to the vulnerability and the specific solution to fix it. Please return the results in a structured JSON format.

and intermediate reasoning accumulated across turns. Especially, instead of relying on general-purpose operation interfaces [15], [30] or syntax-based retrieval [16], [29], our diagnostic agent is equipped with three specialized static analysis tools to collect semantic facts related to suspicious program points: trace_data_flow requires the LLM to specify a variable v of interest at statement l, and returns its intra-procedural taint propagation paths via backward traversal on the precomputed def-use chains. It allows to verify whether untrusted, unchecked, or otherwise unsafe values can influence the vulnerable operation. • is_path_reachable requires the LLM to specify a source statement s, a target statement t, and a variable v of interest, and returns the intra-procedural control-flow paths from s to t. For each path, the tool reports the involved statements, branch predicates, and dominating conditions related to v. It allows to verify whether a suspicious operation is executable under particular control-flow conditions and whether relevant checks are encountered before the target statement. • inspect_api_usage requires the LLM to specify a sensitive API call in the vulnerable code, and returns the syntactic usage context of the API, including the callee, receiver object, arguments, return value, enclosing function, and surrounding statements. If the callee is locally defined in the same file, the tool further returns its implementation slice. These observations help the agent understand the actual behavior of project-specific APIs from code evidence. •

Prompt Design. The prompt template for extracting viewspecific knowledge is shown above. We start from a system prompt to inform the model of the role it plays. Then it is followed by the data we present to the LLM, which consists of the CVE description and vulnerability-patch pair. The subsequent segment outlines the task directives provided to the LLM. In particular, K EA R EPAIR employs a hierarchical reasoning strategy [41], which gradually progresses from observing an editing action to understanding why the vulnerability occurs and how it is fixed, mimicking an expert’s cognitive workflow in vulnerability diagnosis. Finally, the LLM is mandated to output a structured report formatted in JSON that contains view_type, root_cause, risky_calls, taint_flow (data-flow-only), control_branch (control-flowonly), and fixing_strategy. We utilize the tree-sitter [44] parsing library to provide 2) Knowledge Abstraction: As different vulnerability in- the above primitive tools. The ReAct loop will not stop until stances might share high-level commonality (e.g., the similar the maximum interaction turns K (where K = 15 in our root causes and fixing strategies), K EA R EPAIR further performs experiments) reaches or sufficient program facts are received. abstraction to distill more general knowledge that is less bound These facts are then organized as structured diagnostic report, to concrete code implementation details. Following Du et al. which forms the basis of the subsequent patch generation. [42], we instruct LLMs to abstract the concrete code elements, including method invocations, variable names, and types, in D. Knowledge-Level Retrieval-Augmented Patch Generation the extracted vulnerability causes and fixing solutions. Given the structured diagnostic report, K EA R EPAIR syn3) Knowledge Storage: For each vulnerability instance, its thesizes dual-view semantic queries, and retrieves relevant dual-view vulnerability knowledge is stored in separate vector historical exemplars from the view-specific knowledge base databases for indexing and retrieval. Specifically, K EA R EPAIR in parallel for patch generation. Only patches that pass all leverages all-MiniLM-L6-v21 , a lightweight sentence embedquality criteria are selected as final solutions; otherwise, they ding model, to encode the root cause into a 384-dimensional are iteratively refined with execution feedback. feature vector, while retaining the other knowledge items and 1) View-Specific Query Generation: Unlike existing retrievalthe corresponding vulnerability-patch pair as metadata. To augmented AVR approaches that solely use vulnerable code enable efficient retrieval in high-dimensional spaces, we use [20], [22] as the query, K EA R EPAIR prompts LLMs to generate Faiss [43] as our search engine. view-specific root causes based on the diagnostic report to find exemplars that share high-level commonality with the given C. Fact-Grounded Agentic Vulnerability Diagnosis vulnerability. It’s noteworthy that, despite the similarity to The online repair stage begins with an in-depth diagnosis of APPatch [13] in terms of the design idea, our vulnerability the input vulnerable code, aiming to understand the root cause cause is derived from the verified program facts instead of and characteristics of the vulnerability. To this end, we design a free-form LLM reasoning, which suffers from the hallucination tool-augmented diagnostic agent following the ReAct paradigm issue and shows unstable bias with different prompts [42]. [37]. This interleaved thought-action-observation cycle enables 2) Cascading Knowledge Retrieval: To select relevant histordemand-driven exploration of the repository, with observations ical exemplars and their corresponding knowledge items (e.g., referable fixing strategies) as demonstrations, K EA R EPAIR 1 https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2 adopts a cascading retrieval pipeline. Initially, K EA R EPAIR

retrieves the Top-10 candidates separately from the viewspecific vulnerability knowledge base. We use the same embedding model all-MiniLM-L6-v2 to encode dual-view root causes (i.e., query), and compute the squared L2 (Euclidean) distance between the query embedding and the key embeddings stored in vulnerability knowledge base. A shorter distance indicates greater similarity. However, retrieving the exemplar with the most similar root cause does not guarantee finding the one that helps fix the target vulnerability as they may correspond to distinct repair patterns [23]. To address this, we further re-rank the retrieved exemplars using a hybrid re-ranker. Given a set of retrieved candidates, the hybrid re-ranker measures the similarity between the target vulnerability and historical exemplars at the code- and behavior-level. Code Similarity. Unlike previous studies training the embedding model from scratch [22], we directly employ the pretrained CodeLlama [45] to encode the vulnerable code q code to be patched and the vulnerable code dcode ∈ D of candidate i exemplar di . K EA R EPAIR then computes the cosine similarity Cos(q code , dcode ) between their embeddings to measure their i semantic relevance. Behavior Similarity. We utilize BM25 [46] to retrieve exemplars with similar vulnerable behaviors. To be specific, K EA R EPAIR treats the structured diagnostic report q beh as a token sequence, and converts it into a bag-of-words representation. Similarly, three knowledge items, including sensitive APIs, taint flow, and/or control branch) of each candidate exemplar di are concatenated as dbeh i . It then calculates the lexical similarity BM 25(q beh , dbeh i ) of the target vulnerability and candidate exemplars at the behavior-level. Hybrid Re-ranking. To take both code- and behavior-level information into account, we adopt a hybrid approach that integrates CodeLlama and BM25 in a unified manner. The hybrid similarity score is calculated as follows: fϕ (q, di ) = λCos(q code , dcode ) + (1 − λ)BM25(q beh , dbeh i i ) (1)

continues until all checks are passed or a pre-defined iteration limit N is reached. V. E VALUATION A. Research Questions Our work seeks to answer four Research Questions (RQs): RQ1: How does K EA R EPAIR perform in generating patches for real-world vulnerabilities? – RQ1a: Which LLM backbone is the best for K EA R EPAIR? – RQ1b: What about the inference cost of K EA R EPAIR? • RQ2: How effective is K EA R EPAIR compared to baselines? • RQ3: How do various components affect the overall performance of K EA R EPAIR? • RQ4: What is the influence of hyper-parameters on the performance of K EA R EPAIR?

•

B. Baselines We evaluate K EA R EPAIR against four groups of baselines, including constraint-based [7], [26], learning-based [8], [9], LLM-based [13], [14], and agent-based approaches [15], [16]. Constraint-based approaches employ static analysis or dynamic execution of test cases or exploits to generate candidate patches. ExtractFix [26] derives crash-free constraints via sanitizer-defined rules, while VulnFix [7] infers invariants by mutating program states to guide the generation process. • Learning-based approaches fine-tune pre-trained code models to generate the fixed version of a vulnerable function [8]. The state-of-the-art VulMaster [9] integrates diverse information, encompassing vulnerable code structures and expert knowledge to achieve a high repair capability. • LLM-based approaches use carefully crafted prompts to guide LLMs in patch generation. LoopRepair [14] instructs LLMs to generate candidate patches based on predicted fix locations, and designs a taint trace-guided ranking strategy to select the optimal patch during iteration. APPatch [13] combines semantics-aware slicing, adaptive prompting, and exemplar selection to improve patch generation. • Agent-based approaches embed the LLM in an iterative loop equipped with tools for code navigation, compilation, and test execution. Starting from the sanitizer report, PatchAgent [15] and San2Patch [16] retrieve context iteratively and reasons about the vulnerability statically. •

where λ is a weight coefficient to balance the two re-rankers. Note that the BM25 score is normalized between 0-1 to ensure that it is on the same scale as cosine similarity. Adhering to the best practice [21], we select the Top-4 relevant exemplars based on this combined similarity score (placed in ascending order) to guide the patch generator. 3) Patching and Validation: Based on the (❶) diagnostic report, (❷) retrieved exemplars, and (❸) their corresponding knowledge items, the repair agent performs in-context learning over historical fixing strategies to synthesize an initial patch, formatted as a multi-hunk unified diff. As LLMs frequently C. Dataset hallucinate line numbers or context lines, we applies a deterWe evaluate K EA R EPAIR using the V UL 4C [17] dataset, ministic patch correction algorithm [15], which automatically which contains 68 real-world C/C++ vulnerabilities, each paired adjusts the diff using a minimal edit distance heuristic. Patch Refinement with Feedback. Once a valid patch is with the associated PoCs and test cases. 13 vulnerabilities are output, K EA R EPAIR recompiles the target project and applies excluded as they could not be processed by constraint- or two progressively stricter validation checks in turn: replaying learning-based baselines, resulting in a final evaluation set of the triggering PoC, and re-executing the test suite. If any check 55 CVEs, which correspond to 10 software products and six fails, K EA R EPAIR returns the failure output to the repair agent vulnerability types, ranging from buffer overflows and integer to guide its next exploration or edit. This closed feedback loop overflows to more complex use-after-free vulnerabilities.

TABLE I: Patching results of K EA R EPAIR across various vulnerability types under different LLMs.

TABLE II: Cost analysis of K EA R EPAIR under different LLMs.

Arch.

Backbone Model

K EA R EPAIR Standalone

Model

GPT-5.1 Claude-Sonnet-4-6 Gemini-3.1-Pro Qwen3.5-Plus DeepSeek-V3.2 GPT-5.1 Claude-Sonnet-4-6 Gemini-3.1-Pro Qwen3.5-Plus DeepSeek-V3.2

BO 18/38 21/38 16/38 19/38 16/38 30/38 30/38 30/38 28/38 29/38

Vulnerability Type† IO DZ UAF NPD 3/6 2/5 1/2 0/2 3/6 2/5 2/2 1/2 5/6 2/5 0/2 0/2 3/6 1/5 2/2 1/2 5/6 1/5 1/2 0/2 6/6 4/5 2/2 2/2 6/6 3/5 1/2 2/2 6/6 4/5 2/2 2/2 6/6 3/5 1/2 2/2 4/6 2/5 1/2 2/2

IL 0/2 1/2 1/2 1/2 1/2 2/2 2/2 2/2 1/2 2/2

Total 24/55 30/55 24/55 27/55 24/55 46/55 44/55 46/55 41/55 40/55

GPT-5.1 Claude-Sonnet-4-6 Gemini-3.1-Pro Qwen3.5-Plus DeepSeek-V3.2

Repair Rate (%)

Avg. Iter.

83.64 80.00 83.64 74.55 72.73

1.70 1.89 1.20 1.54 1.60

Time Overhead (s) Min Max Med Avg. 8 398 25 61.24 7 529 27 68.80 5 409 22 49.43 9 527 22 62.15 7 507 32 75.60

Avg. Cost ($) 1.15 1.38 0.30 0.12 0.09

VI. E XPERIMENTAL R ESULTS A. RQ1: Effectiveness of K EA R EPAIR

1) [RQ1a] Optimal LLM Selection: Experiment Setup. In order to analyze how different backbone models affect the performance of K EA R EPAIR, we select a D. Evaluation Metrics range of frontier LLMs, including GPT-5.1-2025-11-13, ClaudeIn line with prior work [15], [16], [27], we adopt two widely Sonnet-4-6, Gemini-3.1-Pro-Preview, Qwen3.5-Plus-2026-0420, and DeepSeek-V3.2-0324, as the backend. Apart from used metrics for evaluating approaches: being integrated into our approach, they are also naively • Repair Rate measures the overall repair performance. Let prompted under the zero-shot setting [10] to generate fixes at a denotes the number of vulnerabilities for which an AVR the place in the code where the original developers patched each tool generates at least one compilable patch that successfully vulnerability to act as the control group. To obtain deterministic pass security tests (via PoCs) and functionality tests (via and reproducible results, we set the temperature parameter to test cases), and b the total number of vulnerabilities under 0 for LLMs that support this option, while retaining default repair. This metric is defined as a/b × 100%. configurations for those that do not. • Average Cost calculates the average LLM API cost per instance from token usage, regardless of success or failure. Results. Table I reports the patching results for each model across different vulnerability types. Overall, K EA R EPAIR delivers strong performance across all types by leveraging E. Implementation diverse LLMs, and consistently outperform standalone LLMs. Experiment Environment. All experiments were conducted We can observe that, when paired with GPT-5.1 (or Geminion an Ubuntu 22.04.5 LTS server with an AMD Ryzen 7 3.1-Pro), K EA R EPAIR stands out with the highest repair rate, 5700G @3.80GHz, 128GB RAM, and one NVIDIA A100 successfully addressing 46 out of 55 (83.64%) vulnerabilities, GPU (80GB). Throughout the experiments, LLM APIs were excelling particularly in integer overflow, use-after-free, null uniformly accessed via OpenRouter2 . Unless otherwise stated, pointer dereference, and infinite loop with a perfect 100% the default LLM backbone used was Google’s Gemini-3.1-Pro- success rate. For buffer overflow and divide by zero, the success Preview as it struck a good trade-off between effectiveness and rates are slightly lower, at 78.95% (30/38) and 80.00% (4/5), efficiency (§VI-A). In light of the best performance (§VI-D), respectively. Claude-Sonnet-4-6 also performs impressively, we report experimental results in a setting with the weight achieving an 80.00% (44/55) repair rate. In contrast, two opencoefficient λ as 0.3. sourced LLMs Qwen3.5-Plus and DeepSeek-V3.2 lag behind, Knowledge Preparation. To collect exemplars for retrieval, patching 41 and 40 vulnerabilities, respectively. Despite that, we employ P RIME V UL [47], a high-quality function-level they still outperform the best-performing standalone Claudevulnerability dataset that addresses label inaccuracies through Sonnet-4-6, which patches only 30 vulnerabilities. Additionally, combined automated labeling and manual verification, cou- we find that the performance gains brought by incorporating pled with rigorous de-duplication. P RIME V UL features 5,480 K EA R EPAIR vary for different LLMs. For example, when vulnerability-patch pairs across 130 CWE categories, sourced paired with K EA R EPAIR, the number of vulnerabilities patched from 754 open-source projects. Given the demand for rapid by GPT-5.1 increases from 24 to 46, with the most significant response and cost-effectiveness in generating a large volume of improvement of 91.67%. A similar situation can be observed vulnerability-related knowledge items, we adopt GPT-5-mini- as in Gemini-3.1-Pro. These results underscore the superiority of K EA R EPAIR in effectively patching vulnerabilities. 2025-08-07 during the offline knowledge base construction. Patch Validation. To ensure reproducibility, each vulnerability ✍ Answer to RQ1a ▶ K EA R EPAIR delivers strong perforis isolated within a Docker container and includes an automated mance across all vulnerabilities types by leveraging diverse script that compiles the target first, and then executes the LLMs. Among the tested models, GPT-5.1 and Gemini-3.1PoC and unit tests to confirm whether it is successfully fixed. Pro achieve the highest repair performance, successfully Adhering to the best practice [20], we adopt five times of addressing 46 out of 55 vulnerabilities. ◀ interaction iterations (i.e., N = 5) as the default setting. †

BO: Buffer Overflow, IO: Integer Overflow, DZ: Divide by Zero, UAF: Use-AfterFree, NPD: Null Pointer Dereference, IL: Infinite Loop.

2 https://openrouter.ai

2) [RQ1b] Efficiency:

Experiment Setup. To assess the practical feasibility of TABLE III: Comparison with state-of-the-art AVR approaches. K EA R EPAIR in real-world scenarios, we further measure the Project CVE-ID Type V.R. V.M. V.F. E.F. L.R. AP. P.A. S.P. K.R. CVE-2006-2025 IO ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ average time (in seconds) and API costs (in USD) required CVE-2010-2481 BO ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ CVE-2013-4243 BO ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ per vulnerability for each LLM to generate patches. CVE-2016-10092 BO ✓ ✗ ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ CVE-2016-10093 BO Results. The statistics are summarized in Table II. Overall, CVE-2016-10094 IO ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ CVE-2016-10266 DZ Gemini-3.1-Pro, which achieves the highest repair success CVE-2016-10267 DZ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ CVE-2016-10268 IO ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ rate at 83.64%, strikes the optimal cost-performance trade-off. libtiff CVE-2016-10271 BO ✗ ✗ ✗ ✗ ✓ ✗ ✗ ✓ ✓ CVE-2016-10272 BO ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✓ Particularly, the average time required per vulnerability is 49.43 CVE-2016-5321 BO ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ CVE-2017-5225 BO ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✗ ✓ seconds, with an approximate cost of $0.30, demonstrating that ✗ ✗ ✓ ✗ ✓ ✗ ✓ ✓ ✓ CVE-2017-7595 DZ CVE-2017-7598 DZ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✗ ✓ it can be reasonably applied in real-world environments [48]. CVE-2017-7601 BO ✗ ✗ ✓ ✗ ✓ ✓ ✓ ✓ ✓ CVE-2017-7602 IO ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✓ In contrast, despite the comparable effectiveness, GPT-5.1 and CVE-2012-5134 BO ✗ ✗ ✓ ✗ ✓ ✗ ✓ ✓ ✓ Claude-Sonnet-4-6 incur a higher cost ($1.15/&1.38) and time ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✗ CVE-2016-1838 BO libxml2 CVE-2017-5969 NPD ✗ ✗ ✓ ✗ ✗ ✗ ✗ ✓ ✓ overhead (61.24/68.80 seconds), respectively. DeepSeek-V3.2 CVE-2016-10349 BO ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ offers the most cost-effective solution at $0.09 per vulnerability, libarchive CVE-2016-10350 BO ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ CVE-2016-5844 IO ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ though with a lower repair rate of 72.73%. Qwen3.5-Plus falls CVE-2017-12858 UAF ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✓ ✓ libzip CVE-2017-14107 BO ✗ ✗ ✗ ✗ ✓ ✗ ✓ ✗ ✓ in the middle range, repairing 74.55% of vulnerabilities with an CVE-2017-12937 BO ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ✓ average of 1.54 iterations, resulting in a lower time overhead ✗ ✓ ✗ ✓ ✗ ✓ ✓ ✓ graphicsmagick CVE-2017-14103 UAF ✓ CVE-2017-14649 NPD ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ (62.15 seconds) and cost ($0.12) per vulnerability. CVE-2017-6827 BO ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✓ ✍ Answer to RQ1b ▶ Gemini-3.1-Pro achieves the optimal cost-benefit trade-off, repairing 83.64% of vulnerabilities at a lower cost ($0.30) and within practical timeframes (under 50 seconds) per vulnerability. ◀ B. RQ2: Comparison with State-of-the-Art Work

audiofile

elfutils

CVE-2017-6828 CVE-2017-6829 CVE-2017-6830 CVE-2017-6831 CVE-2017-6832 CVE-2017-6833 CVE-2017-6834 CVE-2017-6835 CVE-2017-6836 CVE-2017-6838

BO BO BO BO BO BO BO BO BO IO

✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✓

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

✗ ✗ ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✓

✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗

✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✗ ✗

✗ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✗ ✓

✓ ✓ ✓ ✗ ✓ ✓ ✗ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓

CVE-2017-7607 CVE-2017-7610 CVE-2017-7611 CVE-2017-7612

BO BO BO BO

✗ ✗ ✗ ✗

✓ ✗ ✗ ✗

✗ ✗ ✗ ✗

✗ ✗ ✗ ✗

✓ ✗ ✗ ✗

✓ ✓ ✓ ✓

✗ ✓ ✓ ✓

✗ ✓ ✓ ✓

✓ ✓ ✓ ✓

Experiment Setup. We evaluate K EA R EPAIR (K.R.), which CVE-2017-7962 DZ ✗ ✓ ✓ ✗ ✗ ✗ ✗ ✗ ✗ employs the optimal LLM Gemini-3.1-Pro in RQ1, against ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ CVE-2017-8325 BO CVE-2017-9204 BO ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ imageworsener eight state-of-the-art AVR approaches described in Section CVE-2017-9205 BO ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ CVE-2017-9206 BO ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ V-B: VulRepair [8] (V.R.), VulMaster [9] (V.M.), VulnFix [7] CVE-2017-9207 BO ✓ ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✗ CVE-2017-9209 IL ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ (V.F.), ExtractFix [26] (E.F.), LoopRepair [14] (L.R.), APPatch qpdf ✗ ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✓ CVE-2017-9210 IL [13] (AP.), PatchAgent [15] (P.A.), and San2Patch [16] (S.A.). CVE-2018-10677 BO ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✓ CVE-2018-10717 BO ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✓ ✓ ngiflib Following Hu et al. [17], for two learning-based approaches ✗ ✗ ✗ ✗ ✗ ✗ ✓ ✗ ✓ CVE-2019-16346 BO CVE-2019-16347 BO ✗ ✗ ✗ ✗ ✗ ✓ ✓ ✗ ✓ [8], [9], we randomly split the de-duplicated VulRD [8] dataset, Total 6/55 4/55 12/55 1/55 30/55 27/55 39/55 36/55 46/55 which removes vulnerabilities that are already contained in our KEAREPAIR benchmark V UL 4C, into 80%-20% for training and validation, 6 KEAREPAIR San2Patch Others and set the beam size to 50, meaning that 50 candidate patches 0 10 0 1 0 0 7 01 2 are produced for each applicable vulnerability. Regarding 1 1 1 0 0 29 LLM-based and agentic approaches, we run them using the 0 1 8 0 0 0 0 1 same backbone model as ours to ensure a fair comparison. In 3 0 0 VulnFix 0 0 3 addition, as VulRepair, VulMaster, and APPatch require exact 2 2 APPatch 10 8 1 LoopRepair vulnerability manifestation or fix locations, we provide the diff 0 PatchAgent 0 version between the vulnerable and patched code as an oracle. Results. Table III presents the performance comparison be(a) vs. agentic approaches. (b) vs. other approaches. tween K EA R EPAIR and the state-of-the-art baselines on each CVE. A vulnerability is deemed successfully patched (denoted Fig. 3: Overlapping among CVEs fixed by different approaches. by ✓) only if there exists a patch that passes both the security tests (via PoCs) and functionality tests (via unit test suites); have been provided with perfect localization information. For otherwise, it is marked as ✗. Overall, K EA R EPAIR substantially example, the state-of-the-art VulMaster can only patch four outperforms all other approaches. In particular, compared to out of 55 vulnerabilities, yielding a success rate of just 7.27%. the best-performing baseline PatchAgent, K EA R EPAIR patches These results are consistent with previous studies [17], [49], seven more vulnerabilities in total. Meanwhile, K EA R EPAIR [50], which suggest that learning-based AVR approaches rely improves over the most related work APPatch, which also heavily on memorized token sequences rather than capturing follows the RAG paradigm, by 70.37% (46 vs. 27), indicating generalizable repair patterns. In contrast, despite the limited the superiority of our proposed knowledge-level retrieval. It scalability, traditional constraint-based VulnFix can still address is noteworthy that learning-based AVR approaches perform 21.82% (12/55) of the total vulnerabilities. extremely poorly in the majority of cases, even though they Overlap Analysis. To investigate to what extent K EA R EPAIR

TABLE IV: Ablation study of K EA R EPAIR components. Variant K EA R EPAIR (Full) -w/o Retrieval (CF) -w/o Retrieval (DF) -w/o Retrieval -w/o Diagnosis -w/o Iteration

BO 30/38 26/38 24/38 22/38 26/38 19/38

Vulnerability Type IO DZ UAF NPD 6/6 4/5 2/2 2/2 4/6 2/5 2/2 1/2 4/6 3/5 1/2 2/2 3/6 2/5 2/2 1/2 5/6 4/5 1/2 2/2 1/6 3/5 1/2 1/2

IL 2/2 1/2 1/2 0/2 0/2 1/2

Total 46/55 36/55 35/55 30/55 38/55 26/55

complements existing approaches, we further draw a Venn diagram to showcase the performance difference. For a better presentation, we first compare K EA R EPAIR against two most related agent-based approaches. As shown in Fig. 3a, while there is substantial overlap in the vulnerabilities resolved by all three approaches, each one also uniquely resolves a small subset of cases except San2Patch. In particular, K EA R EPAIR can provide the correct patch for nine unique vulnerabilities that the best-performing baseline PatchAgent misses. We also independently illustrate the Top-3 best non-agentic baselines (i.e., LoopRepair, APPatch, and VulnFix) in Fig. 3b on the basis of the number of correctly repaired vulnerabilities, and divide the rest approaches into one group (named “Others”) for easy reference. We observe that K EA R EPAIR is able to fix the most number of unique vulnerabilities of six that prior approaches cannot address. Compare with other two LLMbased approaches, LoopRepair and APPatch, K EA R EPAIR can repair 18 and 20 unique vulnerabilities, respectively, exemplifying the superiority of K EA R EPAIR.

performance drop in the underline. The experimental results show that the full K EA R EPAIR configuration achieves the highest performance across all vulnerability types, and removing any single component results in a measurable performance decline. For example, when retrieving demonstrations solely from the view of data flow or control flow, the repair success rate of K EA R EPAIR drops by 21.74% (46→36) and 23.91% (46→35), respectively. Once the entire retrieval pipeline is removed, we can observe a substantial performance degradation (46→30). This confirms that the integration of dual-view vulnerability knowledge is essential for effectively capturing the diversity of vulnerabilities. Notably, we find that the feedback-based iteration mechanism makes the greatest contribution among all variants. Compared to the variant without iteration, K EA R EPAIR significantly improves the repair rate by 76.92% (26→46). The results indicate that single-turn repair attempt is often insufficient for real-world vulnerabilities, and that feedbackdriven refinement is critical for producing more plausible patches, which is consistent with recent works [14], [20]. ✍ Answer to RQ3 ▶ Each component makes a vital and positive contribution to K EA R EPAIR. The most important component is the feedback-based iteration mechanism that results in 76.92% improvement in repair success rate. ◀

R e p a ir R a te ( % )

D. RQ4: Sensitivity Analysis Experiment Setup. To keep simplicity, λ is varied from 0 to 1 with an internal of 0.1. All other configurations are kept consistent with RQ2, including the default LLM backbone and metric computation. ✍ Answer to RQ2 ▶ The performance improvements Results. Fig. 4 presents the of K EA R EPAIR over the state-of-the-art baselines are sig8 5 performance of K EA R EPAIR nificant. Particularly, K EA R EPAIR outperforms the bestwith varying weight coeffiperforming PatchAgent by 17.95% in terms of successfully 8 0 cient λ. We can observe that, repaired vulnerabilities, and is able to fix the most number 7 5 the repair success rate stably of unique CVEs that prior approaches cannot address. ◀ goes up with the increasing 7 0 of λ, and reaches the optimal 6 5 C. RQ3: Ablation Study performance at 0.3. Never0 .0 0 .2 0 .4 0 .6 0 .8 1 .0 Experiment Setup. To quantify the contribution of each theless, as the proportion of component, we evaluate five ablated variants against the full code-level similarity continFig. 4: Parameter analysis of implementation by disabling one key component at a time. ues to increase, the number the weight coefficient λ. • w/o Retrieval (CF/DF): Distills and retrieves the vulnerabil- of fixes degrades sharply. A ity knowledge solely from the view of Data (/Control) Flow possible reason is that project-specific identifiers and incidental for patch generation. logic of lexically-similar examples introduce contextual noise, • w/o Retrieval: Bypasses the vulnerability knowledge base making LLMs more inclined to mimic the verbatim code construction phase, injecting raw diagnostic report directly patterns of the provided demonstrations, rather than learn highinto the prompt to instruct the repair agent to generate fixes level repair strategies. in a zero-shot setting. ✍ Answer to RQ4 ▶ The repair success rate stably goes • w/o Diagnosis: Disables the tool-augmented diagnostic agent, up with the increasing of λ, and our default hyper-parameter Instructing the LLM to generate root causes from vulnerable setting achieve optimal results. ◀ code for retrieval and generation. • w/o Iteration: Replaces the feedback-based iteration mechVII. D ISCUSSION anism with one-step repair paradigm, outputting the initial A. Analysis of Failure Cases patch without further refinement. Results. Table IV summarizes the ablation results across all Despite superior performance, we carefully analyze all the variants, with the best results highlighted in bold and the largest cases where patching fails on the V UL 4C dataset, and identify λ

TABLE V: Performance on the PATCH E VAL dataset. PoC-only PoC & Unit Go Js Py Total Go Js Py Total GPT-5.1 11/62 13/47 7/64 31/173 10/62 10/47 6/64 26/173 Claude-Sonnet-4-6 20/62 19/47 10/64 49/173 18/62 13/47 9/64 40/173 Gemini-3.1-Pro 19/62 23/47 17/64 59/173 19/62 20/47 16/64 55/173 Qwen3.5-Plus 10/62 13/47 8/64 31/173 10/62 9/47 5/64 24/173 DeepSeek-V3.2 14/62 14/47 10/64 38/173 14/62 10/47 8/64 32/173 GPT-5.1 49/62 43/47 52/64 144/173 43/62 40/47 47/64 130/173 Claude-Sonnet-4-6 57/62 44/47 54/64 155/173 56/62 38/47 49/64 143/173 Gemini-3.1-Pro 38/62 39/47 53/64 130/173 36/62 30/47 38/64 104/173 Qwen3.5-Plus 58/62 45/47 52/64 155/173 56/62 43/47 49/64 148/173 DeepSeek-V3.2 33/62 34/47 43/64 110/173 29/62 30/47 40/64 99/173 GPT-5.1 12/62 17/47 17/64 46/173 10/62 15/47 14/64 39/173 Claude-Sonnet-4-6 14/62 17/47 12/64 43/173 14/62 16/47 11/64 41/173 Gemini-3.1-Pro 14/62 21/47 22/64 57/173 13/62 20/47 21/64 54/173 Qwen3.5-Plus 11/62 19/47 15/64 45/173 9/62 15/47 13/64 37/173 DeepSeek-V3.2 13/62 19/47 16/64 48/173 13/62 17/47 15/64 45/173

Arch. Backbone Model SWE-Agent K EA R EPAIR Standalone

two major failure modes. Challenges in Static Analysis. K EA R EPAIR relies on static analysis (e.g., pre-computed def-use chains) to collect verified program facts for vulnerability diagnosis. However, real-world C/C++ projects often contain complex macros, compilerspecific extensions, and conditionally compiled paths that are difficult to resolve without full build-system integration. When static analyzers yield imprecise or unsound results, diagnosis falls back from fact-grounded reasoning to under-constrained LLM reasoning. A representative case is CVE-2016-1838 [51], where deeply nested macro expansions prevent reliable scope resolution and intra-procedural data-flow analysis, ultimately resulting in incorrect patches. Limitations of Single-Location Fixes. Another common issue involves inter-procedural vulnerabilities. Despite high-quality, our used P RIME V UL dataset constructs vulnerability-patch pairs at the function-level, resulting in distilled vulnerability knowledge fails to capture global context such as cross-file dependencies. As a result, the repair agent may be misled to produce patches that are syntactically valid within the target file but semantically incomplete at the project-level. As revealed in Table III, all six CVEs in imageworsener require coordinated changes across multiple files, which none of the investigated LLM-based and agentic approaches can handle.

of 173 vulnerabilities for a success rate of 60.12%. These results indicate that there is no “one-size-fits-all” model can always perform the best, indicating the necessity of empirically selecting a proper LLM. We also observe that integrating general-purpose SWE-Agent does not lead to performance gains, even degrades results, underscoring the importance of developing domain-specialized agents tailored. C. Threats to Validity

Threats to External Validity come from the risk of data leakage. We evaluated the performance of K EA R EPAIR on B. Cross-Language Evaluation 55 and 173 reproducible vulnerabilities sourced from V UL 4C Motivation. While demonstrated superior performance, the and PATCH E VAL, respectively. Since LLMs are trained on heavy reliance on benchmarks centered on C/C++ significantly massive inscrutable corpora, it is difficult to rule out the constrains the generalizability of evaluation results. Prior works possibility that CVEs or their patches in these static datasets [52], [53] have shown that LLMs have promising capabilities are included in their pre-training data, resulting in artificially for multilingual vulnerability repair tasks due to their language- inflated performance. To mitigate this threat, we plan to conagnostic capabilities. For this purpose, we are interested to struct a contamination-resistant, reproducible, and continuously investigate whether our proposed K EA R EPAIR can handle more updatable benchmark tailored to real-world AVR tasks. Despite that, our controlled studies under the same LLM backbone diverse vulnerabilities beyond C/C++. Experiment Setup. We evaluate the generalizability of K EA R E - demonstrate that the observed improvements are attributable to PAIR on PATCH E VAL [27], a multilingual benchmark for Go, K EA R EPAIR ’s design rather than differences in training data. JavaScript, and Python. To be specific, we consider a subset Threats to Internal Validity refer to the generalizability of 173 CVEs equipped with runtime sandbox environments, of our findings. We evaluated K EA R EPAIR on four popular enabling patch validation through security and/or functionality programming languages, i.e., C/C++, Python, JavaScript, and tests. As specialized vulnerability repair agents, i.e., PatchAgent Go, and thus our experimental results may not generalizable and San2Patch, only take the sanitizer report as input, we also to other programming languages. However, we believe the key evaluate another general-purpose approach SWE-Agent [30]. unique design of K EA R EPAIR (i.e., performing tool-augmented Other experimental settings, such as LLM backbones and model agentic reasoning to collect verified program facts for reliable root cause analysis, and improving the patch quality via dualconfigurations, are the same as those in RQ1. Results. As shown in Table V, K EA R EPAIR generalizes effec- view knowledge retrieval) is language-agnostic, and thus can tively to multilingual vulnerability repair tasks. In particular, be easily ported for a new programming language. when paired with Qwen3.5-Plus, K EA R EPAIR achieves the best Threats to Construct Validity arise from the sufficiency of performance, patching 148 out of 173 (85.55%) cases, followed our oracle-based evaluation measures. Following prior work by Claude-Sonnet-4-6 with 143 successful repairs. Additionally, [27], we combine security tests and functionality tests to for each LLM, incorporating K EA R EPAIR yields a significant confirm whether a vulnerability is fixed. Unfortunately, these improvement over its standalone performance as before, with dynamic checks still cannot guarantee the correctness of gains ranging from 89.09% (Gemini-3.1-Pro) to 516.67% generated patches as they may pass all available tests while (Qwen3.5-Plus), demonstrating the practical implications of still introducing regressions not covered by the test suites [55]. K EA R EPAIR in real-world scenarios, in which multilingual Manual validation is preferred, yet it is knowledge-intensive. development is prevalent [54]. Notably, Gemini-3.1-Pro which Thus, automated approaches capable of assessing what a patch outperforms all other models in RQ1 can only patch 104 out fixes, not whether the observed crash is suppressed are required.

VIII. C ONCLUSION Frontier foundation models are discovering vulnerabilities at a pace and depth that human red teams simply cannot match, resulting in a faster-growing backlog of unresolved critical issues. In this paper, we presented K EA R EPAIR, a knowledgeenhanced agentic approach for automated vulnerability repair. By combining vulnerability knowledge base construction, factgrounded vulnerability diagnosis, and retrieval-augmented patch generation, K EA R EPAIR grounds LLM-based repair in verified program facts and reusable historical fix knowledge. Extensive experiments on real-world vulnerabilities demonstrate that K EA R EPAIR substantially outperforms state-of-the-art baselines in both repair effectiveness and cross-language generalizability. R EFERENCES [1] Assessing Claude Mythos Preview’s cybersecurity capabilities, 2026, https://red.anthropic.com/2026/mythos-preview. [2] Scaling Trusted Access for Cyber with GPT-5.5 and GPT-5.5-Cyber, 2026, https://openai.com/index/gpt-5-5-with-trusted-access-for-cyber. [3] Common Vulnerabilities and Exposures, 2026, https://www.cve.org. [4] Y. Li, F. H. Shezan, B. Wei, G. Wang, and Y. Tian, “SoK: Towards effective automated vulnerability repair,” in Proceedings of the 34th USENIX Security Symposium (Security), 2025, pp. 4441–4462. [5] X. Zhou, S. Cao, X. Sun, and D. Lo, “Large language model for vulnerability detection and repair: Literature review and the road ahead,” ACM Trans. Softw. Eng. Methodol., vol. 34, no. 5, pp. 145:1–145:31, 2025. [6] Z. Huang, D. Lie, G. Tan, and T. Jaeger, “Using safety properties to generate vulnerability patches,” in Proceedings of the 40th IEEE Symposium on Security and Privacy (S&P), 2019, pp. 539–554. [7] Y. Zhang, X. Gao, G. J. Duck, and A. Roychoudhury, “Program vulnerability repair via inductive inference,” in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2022, pp. 691–702. [8] M. Fu, C. Tantithamthavorn, T. Le, V. Nguyen, and D. Phung, “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 (ESEC/FSE), 2022, pp. 935–947. [9] X. Zhou, K. Kim, B. Xu, D. Han, and D. Lo, “Out of sight, out of mind: Better automatic vulnerability repair by broadening input ranges and sources,” in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering (ICSE), 2024, pp. 88:1–88:13. [10] H. Pearce, B. Tan, B. Ahmad, R. Karri, and B. Dolan-Gavitt, “Examining zero-shot vulnerability repair with large language models,” in Proceedings of the 44th IEEE Symposium on Security and Privacy (S&P), 2023, pp. 2339–2356. [11] X. Wen, Z. Lin, Y. Yang, C. Gao, and D. Ye, “Vul-r2: A reasoning LLM for automated vulnerability repair,” in Proceedings of the 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2025, pp. 26–38. [12] C. Yang, T. Zhang, J. Jiang, X. Zhou, H. Tian, M. Du, J. Shi, J. Chen, Y. Li, E. L. Ouh, L. K. Shar, and D. Lo, “SeCuRepair: Semanticsaligned, curriculum-driven, and reasoning-enhanced vulnerability repair framework,” in Proceedings of the 64th Annual Meeting of the Association for Computational Linguistics (ACL), 2026, pp. 1–16. [13] Y. Nong, H. Yang, L. Cheng, H. Hu, and H. Cai, “APPATCH: Automated adaptive prompting large language models for real-world software vulnerability patching,” in Proceedings of the 34th USENIX Security Symposium (Security), 2025, pp. 4481–4498. [14] Z. Ye, X. Sun, S. Cao, L. Bo, and B. Li, “Well begun is half done: Location-aware and trace-guided iterative automated vulnerability repair,” in Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE), 2026. [15] Z. Yu, Z. Guo, Y. Wu, J. Yu, M. Xu, D. Mu, Y. Chen, and X. Xing, “PATCHAGENT: A practical program repair agent mimicking human expertise,” in Proceedings of the 34th USENIX Security Symposium (Security), 2025, pp. 4381–4400. [16] Y. Kim, S. Shin, H. Kim, and J. Yoon, “Logs in, patches out: Automated vulnerability repair via tree-of-thought LLM analysis,” in Proceedings of the 34th USENIX Security Symposium (Security), 2025, pp. 4401–4419.

[17] Y. Hu, Z. Li, K. Shu, S. Guan, D. Zou, S. Xu, B. Yuan, and H. Jin, “SoK: Automated vulnerability repair: Methods, tools, and assessments,” in Proceedings of the 34th USENIX Security Symposium (Security), 2025, pp. 4421–4440. [18] E. O. Soremekun, L. Kirschner, M. Böhme, and M. Papadakis, “Evaluating the impact of experimental assumptions in automated fault localization,” in Proceedings of the 45th IEEE/ACM International Conference on Software Engineering (ICSE). IEEE, 2023, pp. 159–171. [19] N. Jiang, Q. Li, L. Tan, and T. Zhang, “Collu-bench: A benchmark for predicting language model hallucinations in code,” arXiv preprint arXiv: 2410.09997, 2024. [20] X. Yin, C. Ni, S. Wang, Z. Li, L. Zeng, and X. Yang, “ThinkRepair: Self-directed automated program repair,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2024, pp. 1274–1286. [21] S. Gao, X. Wen, C. Gao, W. Wang, H. Zhang, and M. R. Lyu, “What makes good in-context demonstrations for code intelligence tasks with llms?” in Proceedings of the 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2023, pp. 761–773. [22] M. Shao, Y. Ding, C. Gao, and G. Zhu, “Fix pattern-aware vulnerability patch generation via in-context learning,” ACM Trans. Softw. Eng. Methodol., pp. 1–44, 2026. [23] J. Li, Z. Chen, Y. Su, and M. R. Lyu, “Vulkey: Automated vulnerability repair guided by domain-specific repair patterns,” in Proceedings of the 34th ACM International Conference on the Foundations of Software Engineering (FSE). ACM, 2026, pp. 1–24. [24] Z. Chen, S. Kommrusch, and M. Monperrus, “Neural transfer learning for repairing security vulnerabilities in C code,” IEEE Transactions on Software Engineering, vol. 49, no. 1, pp. 147–165, 2023. [25] M. Fu, V. Nguyen, C. Tantithamthavorn, D. Phung, and T. Le, “Vision transformer inspired automated vulnerability repair,” ACM Trans. Softw. Eng. Methodol., vol. 33, no. 3, pp. 78:1–78:29, 2024. [26] X. Gao, B. Wang, G. J. Duck, R. Ji, Y. Xiong, and A. Roychoudhury, “Beyond tests: Program vulnerability repair via crash constraint extraction,” ACM Trans. Softw. Eng. Methodol., vol. 30, no. 2, pp. 14:1–14:27, 2021. [27] Z. Wei, J. Zeng, M. Wen, Z. Yu, K. Cheng, Y. Zhu, J. Guo, S. Zhou, L. Yin, X. Su, and Z. Ma, “PATCHEVAL: A new benchmark for evaluating llms on patching real-world vulnerabilities,” arXiv preprint arXiv: 2511.11019, 2025. [28] J. Liu, K. Wang, Y. Chen, X. Peng, Z. Chen, L. Zhang, and Y. Lou, “Large language model-based agents for software engineering: A survey,” ACM Transactions on Software Engineering and Methodology, 2025. [29] Y. Zhang, H. Ruan, Z. Fan, and A. Roychoudhury, “Autocoderover: Autonomous program improvement,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2024, pp. 1592–1604. [30] J. Yang, C. E. Jimenez, A. Wettig, K. Lieret, S. Yao, K. Narasimhan, and O. Press, “Swe-agent: Agent-computer interfaces enable automated software engineering,” in Proceedings of the 38th Annual Conference on Neural Information Processing Systems (NeurIPS), 2024. [31] K. Zhu, Z. Tian, S. Wang, M. Leng, and X. Mao, “Atomizer: An llm-based collaborative multi-agent framework for intent-driven commit untangling,” in Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE), 2026. [32] CVE-2017-6828, 2026, https://nvd.nist.gov/vuln/detail/cve-2017-6828. [33] S. Shen, A. Kolluri, Z. Dong, P. Saxena, and A. Roychoudhury, “Localizing vulnerabilities statistically from one exploit,” in Proceedings of the 16th ACM Asia Conference on Computer and Communications Security (AsiaCCS). ACM, 2021, pp. 537–549. [34] V. Kabadi, D. Kong, S. Xie, L. Bao, G. A. A. Prana, T. B. Le, X. D. Le, and D. Lo, “The future can’t help fix the past: Assessing program repair in the wild,” in Proceedings of the 39th IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2023, pp. 50–61. [35] R. Shariffdeen, C. S. Timperley, Y. Noller, C. Le Goues, and A. Roychoudhury, “Vulnerability repair via concolic execution and code mutations,” ACM Trans. Softw. Eng. Methodol., vol. 34, no. 4, pp. 105:1–105:27, 2025. [36] CVE-2018-16419, 2026, https://nvd.nist.gov/vuln/detail/cve-2018-16419. [37] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in Proceedings of the 11th International Conference on Learning Representations (ICLR), 2023, pp. 1–33.

[38] Y. Yang, B. Xu, X. Gao, and H. Sun, “Context-enhanced vulnerability detection based on large language models,” ACM Trans. Softw. Eng. Methodol., pp. 1–46, 2025. [39] L. Zhao, Y. Zhu, J. Ming, Y. Zhang, H. Zhang, and H. Yin, “Patchscope: Memory object centric patch diffing,” in Proceedings of the 27th ACM SIGSAC Conference on Computer and Communications Security (CCS). ACM, 2020, pp. 149–165. [40] S. Cao, X. Sun, L. Bo, R. Wu, B. Li, and C. Tao, “MVD: memory-related vulnerability detection based on flow-sensitive graph neural networks,” in Proceedings of the 44th IEEE/ACM International Conference on Software Engineering (ICSE). ACM, 2022, pp. 1456–1468. [41] J. Wei, X. Wang, D. Schuurmans, M. Bosma, B. Ichter, F. Xia, E. H. Chi, Q. V. Le, and D. Zhou, “Chain-of-thought prompting elicits reasoning in large language models,” in Proceedings of the 36th Annual Conference on Neural Information Processing Systems (NeurIPS), 2022, pp. 24 824– 24 837. [42] X. Du, G. Zheng, K. Wang, Y. Zou, Y. Wang, W. Deng, J. Feng, M. Liu, B. Chen, X. Peng, T. Ma, and Y. Lou, “Vul-rag: Enhancing llm-based vulnerability detection via knowledge-level RAG,” ACM Trans. Softw. Eng. Methodol., pp. 1–25, 2026. [43] M. Douze, A. Guzhva, C. Deng, J. Johnson, G. Szilvasy, P. Mazaré, M. Lomeli, L. Hosseini, and H. Jégou, “The faiss library,” IEEE Trans. Big Data, vol. 12, no. 2, pp. 346–361, 2026. [44] Tree-sitter, 2026, https://tree-sitter.github.io/tree-sitter. [45] B. Rozière, J. Gehring, F. Gloeckle, S. Sootla, I. Gat, X. E. Tan, Y. Adi, J. Liu, T. Remez, J. Rapin, A. Kozhevnikov, I. Evtimov, J. Bitton, M. Bhatt, C. Canton-Ferrer, A. Grattafiori, W. Xiong, A. Défossez, J. Copet, F. Azhar, H. Touvron, L. Martin, N. Usunier, T. Scialom, and G. Synnaeve, “Code llama: Open foundation models for code,” arXiv preprint arXiv: 2308.12950, 2023. [46] G. Salton and C. Buckley, “Term-weighting approaches in automatic text retrieval,” Inf. Process. Manag., vol. 24, no. 5, pp. 513–523, 1988. [47] Y. Ding, Y. Fu, O. Ibrahim, C. Sitawarin, X. Chen, B. Alomair, D. A.

Wagner, B. Ray, and Y. Chen, “Vulnerability detection with code language models: How far are we?” in Proceedings of the 47th IEEE/ACM International Conference on Software Engineering (ICSE). IEEE, 2025, pp. 1729–1741. [48] Y. Noller, R. Shariffdeen, X. Gao, and A. Roychoudhury, “Trust enhancement issues in program repair,” in Proceedings of the 44th IEEE/ACM 44th International Conference on Software Engineering (ICSE). ACM, 2022, pp. 2228–2240. [49] Y. Wu, N. Jiang, H. V. Pham, T. Lutellier, J. Davis, L. Tan, P. Babkin, and S. Shah, “How effective are neural networks for fixing security vulnerabilities,” in Proceedings of the 32nd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA), 2023, pp. 1282– 1294. [50] W. Han, Y. Kwak, M. Yu, K. Kim, Y. Lee, H. Moon, and Y. Paek, “Rethinking the capability of fine-tuned language models for automated vulnerability repair,” in Proceedings of the 48th IEEE/ACM International Conference on Software Engineering (ICSE), 2026. [51] CVE-2016-1838, 2026, https://nvd.nist.gov/vuln/detail/cve-2016-1838. [52] D. Wang, J. Yu, H. Shu, M. Fu, C. Tantithamthavorn, Y. Kamei, and J. Chen, “On the evaluation of large language models in multilingual vulnerability repair,” ACM Trans. Softw. Eng. Methodol., 2025. [53] B. Yang, H. Tian, J. Ren, H. Zhang, J. Klein, T. F. Bissyandé, C. Le Goues, and S. Jin, “Morepair: Teaching llms to repair code via multiobjective fine-tuning,” ACM Trans. Softw. Eng. Methodol., vol. 35, no. 2, pp. 38:1–38:38, 2026. [54] W. Li, A. Marino, H. Yang, N. Meng, L. Li, and H. Cai, “How are multilingual systems constructed: Characterizing language use and selection in open-source multilingual software,” ACM Trans. Softw. Eng. Methodol., vol. 33, no. 3, pp. 63:1–63:46, 2024. [55] H. Wei, L. Chen, Z. Zhang, G. Shi, and D. Meng, “Sleuth: A switchable dual-mode fuzzer to investigate bug impacts following a single poc,” in Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). ACM, 2024, pp. 730–742.