arXiv CSopen access

RAVEN: Agentic RAG for Automated Vulnerability Repair

RAVEN: Agentic RAG for Automated Vulnerability Repair Varun Gadey∗ , Zijie Liu∗ , Alexandra Dmitrienko∗

arXiv:2606.22647v1 [cs.CR] 21 Jun 2026

∗ University of Duisburg-Essen, Germany

Abstract—Automated vulnerability repair has emerged as a promising direction to mitigate the growing number of software vulnerabilities. Recent advances in Large Language Models (LLMs) have further accelerated research in automated repair. However, existing frameworks remain largely restricted to memory-related vulnerabilities and locally repairable vulnerability settings, leaving generalization to unseen vulnerability types underexplored. Their evaluations are often limited to a single programming language, and largely rely on proprietary models. In this paper, we propose RAVEN, a scalable, efficient and autonomous framework that integrates an agentic retrieval-augmented generation (RAG) pipeline with controlled iterative repair in a unified framework. The framework utilizes open-source LLMs in a fully locally deployable setting with limited GPU requirements, while building a multi-faceted retrieval pipeline to retrieve historically relevant vulnerability fixes and guide the patch generation. In addition, RAVEN introduces a dedicated Curator Agent that retrieves cross-file dependencies from the target repository, to fix complex vulnerabilities that cannot be addressed using local vulnerable code alone. We evaluate RAVEN on 160 real-world CVE vulnerabilities across diverse vulnerability types, two programming languages, unseen CWE categories, and out-of-distribution settings. RAVEN achieves an overall repair success rate of 83.13%, outperforming all existing state-of-the-art repair frameworks, while also demonstrating strong generalization capabilities and maintaining the repair cost negligible.

1. Introduction Software vulnerabilities remain one of the most exploited entry points for modern cyberattacks, while the volume of disclosed vulnerabilities continues to grow rapidly. In 2025, more than 48K CVEs were published, averaging around 131 disclosures per day [1]. At the same time, remediation remains slow in practice, with critical application vulnerabilities reported in 2025 taking an average of 74.3 days to This growing scale and diversity makes manual vulnerability repair increasingly difficult, as developers must analyze program behavior, identify root causes, and fix vulnerabilities without introducing new defects. Consequently, automated vulnerability repair has become essential for producing timely and reliable fixes for both existing and emerging vulnerability threats. A wide range of automated vulnerability repair (AVR) frameworks have been proposed over the past decade.

Search-based methods such as CapGen [2], sharpFix [3] explore predefined mutation spaces guided by test cases, but often suffer from search space explosion and limited coverage when correct patches are absent. Semantic-based approaches, including SOSRepair [4] and Maple [5], leverage symbolic execution and program constraints to guide repair, improving efficiency but restricting adaptability to complex or diverse vulnerabilities. Template-based approaches, such as PAR [6], kPAR [7], and AVATAR [8], construct patches using predefined fix patterns. While effective for recurring defects, they remain bounded by the availability and coverage of templates, as well as fault localization accuracy, hindering applicability to diverse and unseen vulnerabilities. Learning-based approaches model program repair as a data-driven task from buggy to fixed code using neural models. Techniques such as Sequencer [9], DeepRepair [10], and CoCoNuT [11] learn code patterns to improve patch generation. Despite these advances, their effectiveness remains constrained by training data quality and distribution, often limiting generalization to complex and context-dependent vulnerabilities. More recently, LLM-based approaches [12], [13], [14], [15], [16], [17], [18], [19], [20] have emerged as a promising direction by leveraging large code models to reason over vulnerable code and to generate patches. Existing works include training or fine-tuning based repair frameworks such as VRepair [12], SeqTrans [13], VulRepair [14], and VulMaster [15], retrieval-augmented generation for functionality bugs such as RAP-Gen [17], and zero-shot or promptbased repair approaches such as Pearce et al. [16]. Among recent state-of-the-art frameworks, PatchAgent [19] introduces an autonomous agent-based framework that combines fault localization, patch generation, and validation. APPATCH [20] proposes adaptive prompting and vulnerability semantics reasoning for patch generation. SAN2PATCH [18] leverages sanitizer logs with multi-stage LLM reasoning to decompose vulnerability repair into structured subtasks. Despite these advances, existing LLM-based frameworks remain limited in several important aspects. They are often restricted to specific Common Weakness Enumerations (CWEs) i.e. categories; and are commonly evaluated only within a single programming language; and mostly target vulnerabilities whose repair can be inferred from a single line, function, or local code region. Moreover, their generalization capability to unseen vulnerability types remains underexplored, and dedicated mechanisms for controlling

the probabilistic nature of LLMs are largely ignored. Collectively, these limitations reveal open challenges in automated vulnerability repair, which are discussed in detail below. 1 Many real-world vulnerabilities (CVEs) Challenge ⃝ can span across multiple source files and cannot be repaired using only the local code snippet. For complex families of vulnerability types such as access control, input handling, and injection-based, the root cause may depend on crossfile dependencies, global context or semantic and data-flow interactions across the repository. However, recent repair frameworks [20], [19], [18], [21], [15], [12] largely focus on memory-safety and arithmetic-related families of vulnerability types, where the repair is often very localized. 2 Due to the probabilistic nature of LLMs, Challenge ⃝ generated patches may unintentionally introduce new vulnerabilities or provide only partial fixes to existing ones. Moreover, all the recent frameworks [18], [17], [16], [20], [19], [21], [15], [12] primarily focus only on one-shot automated repair. Dedicated mechanisms for systematically scrutinizing, reviewing, and refining generated patches through iterative feedback remain largely unexplored. 3 Most of the LLM-based repair frameChallenge ⃝ works [19], [20] heavily rely on large proprietary models from providers such as OpenAI and Anthropic, leading to high token cost, longer repair time, and limited deployability. For instance, PatchAgent [19] reports that running only 75 repair cases cost over $1500, highlighting the financial limitations of such approaches. Thus, efficient, low-cost, and locally deployable repair framework remains an important open challenge. 4 Finally, LLM-based repair frameworks Challenge ⃝ remain highly susceptible to hallucinations, inconsistent patch generation, and non-deterministic behaviors. Although recent works such as APPATCH [20] acknowledge this issue through post-generation validation strategies, dedicated mechanisms to proactively reduce hallucinations during patch generation itself remain largely unexplored. To address these challenges, we propose RAVEN, a scalable and autonomous framework for automated vulnerability repair designed to operate across diverse vulnerability types and generalize to previously unseen vulnerabilities. RAVEN is the first repair framework to integrate an agentic retrievalaugmented generation (RAG) pipeline with historical fix retrieval, context dependency retrieval, and controlled iterative patch refinement in a unified framework. To support practical and cost-effective deployment, RAVEN utilizes recent open-source medium-sized LLMs, including Gemma-4-26B [22], and Nemotron-3-30B [23], allowing locally deployable vulnerability repair without reliance on proprietary cloud-based models. With RAVEN, developers can efficiently perform automated vulnerability repair across diverse software projects using locally deployable open-source LLMs, reducing significantly repair cost and dependency on proprietary services. Contributions In particular, we make the following contributions: • We propose RAVEN, a first-of-its-kind automated vulnerability repair framework designed that uniquely

combines the ability to repair complex real-world vulnerabilities across 10 diverse CWE types and programming languages, including Java and C. • We design an agentic RAG framework that performs multi-faceted retrieval using lexical, syntactic, and semantic vulnerability cues to retrieve relevant historical fixes. In addition, RAVEN introduces a dedicated Curator Agent that scans the target repository to extract rootcause information, and cross-file dependencies guiding patch generation beyond local vulnerable snippets. • We introduce an automated iterative repair mechanism that incorporates a dedicated Patch Reviewer module and static analysis feedback to progressively refine generated patches and improve repair quality. • We evaluate RAVEN on 160 real-world CVE vulnerabilities across diverse experimental setups, including multiple vulnerability types, programming languages, unseen CWE categories, and out-of-distribution datasets. RAVEN achieves an overall repair success rate of 83.13%, outperforming existing state-of-the-art repair tools. • We demonstrate the generalizability and efficiency of RAVEN through cross-language evaluation (86.21% success rate), unseen vulnerability-type (CWEs) evaluation (87.50% success rate), and local deployment using open-source LLMs with negligible token cost. Overall, this work addresses key limitations in existing automated vulnerability repair by proposing a unified agentic RAG-based framework that integrates historical fix and dependency retrieval, iterative patch refinement, and independent validation to enable scalable, low-cost, and generalizable repair of real-world CVEs. To the best of our knowledge, no existing repair framework explicitly targets Java-based CWEs spanning access control, SQL injection, code injection, and memory-related vulnerabilities. Outline. Appendix A provides background on Retrieval Augmented Generation (RAG). Section 2 highlights the complexity of fixing vulnerabilities autonomously. In Section 3, we present our RAVEN approach. Section 4 presents the evaluation results, showcasing RAVEN’s effectiveness across various experimental settings. Section 5 reviews the related literature. Finally, Section 6 concludes the paper.

2. Motivation In this section, we demonstrate the significance of RAVEN by examining a real-world vulnerability, CVE2023-37910[24], identified in the XWiki platform[25] within the file MoveAttachmentJob.java. This vulnerability corresponds to CWE-862 Missing Authorization[26], where a security-sensitive operation is executed without verifying whether the requesting user has sufficient access rights. This class implements a refactoring job responsible for moving attachments across documents in the repository. The vulnerability stems from the method protected void process(EntityReference source), where the attachment move operation is executed, followed by the triggering of notification events. As shown in Figure 1, the critical

2

1 2 3 4 5 6 7 8

9 10

this.modelBridge.setContextUserReference( this.request.getUserReference()); try { this.progressManager.startStep(this); moveAttachment(source, destination, autoRedirect, wiki); // vulnerable call this.progressManager.endStep(this); this.progressManager.startStep(this); this.observationManager.notify( new AttachmentMovedEvent( (AttachmentReference) source, destination), this, this.request); this.progressManager.endStep(this); }

Figure 1: CWE-862 Missing Authorization issue occurs at line 4, where moveAttachment(...) is directly invoked without any prior authorization check on the requesting user. The surrounding lines primarily manage execution flow, including setting the user context (lines 1–2), tracking progress (lines 3, 5, 7, 9), but do not perform access control checks before the sensitive operation is executed. Exploitation of this vulnerability allows an unauthorized user to move attachments across documents without possessing the required access rights, potentially leading to unauthorized data manipulation, or information disclosure within the repository. Fixing this issue is non-trivial and particularly challenging for automated vulnerability repair tools, as the vulnerability arises from a missing security precondition rather than an explicit syntactic or semantic error. The repair requires coordinating multiple code-level changes, and integrating the authorization logic at the correct point in the existing control flow. Moreover, this authorization logic is not fully apparent from the local code alone, meaning that a naive repair strategy focused solely on local context may fail to identify the missing precondition or introduce ad hoc checks that are inconsistent with the system’s design.

Figure 2: RAVEN Framework Overview; To further improve repair quality, RAVEN employs an iterative refinement mechanism in which generated patches are progressively evaluated and revised using feedback from a static analysis tool and a patch review module. This design aims to support generalization across programming languages and diverse vulnerability types, addressing limitations observed in recent state-of-the-art repair approaches [19], [20], [18]. RAVEN uses recent mediumsized LLMs, such as Gemma-4-26B [22] and Nemotron3-30B [23], as core components for patch generation and evaluation. These models offer a practical balance between effectiveness and efficiency and can be deployed locally, allowing RAVEN to maintain a lightweight and cost-effective design without reliance on external services.

3.1. Framework Overview

3. RAVEN Design

Figure 2 provides an overview of the RAVEN framework, illustrating its core modules and their interactions. 1 Semantic RAVEN comprises five core modules that are ⃝ 2 Context Retriever, ⃝ 3 Patch Generator, Retriever, ⃝ 4 Patch Reviewer, and ⃝ 5 Patch Validator. Each module ⃝ has its own dedicated pipeline and is designed to meet a specific objective. For instance, Sematic Retrieval module is responsible for retrieving highly-relevant and semantically similar fix patches, while Context Retrieval is designed to address the complex vulnerabilities by providing cross file dependencies and global context of the vulnerable code. The outputs of both these modules are serving as inputs to Patch Generator module. One-shot vulnerability repair rarely succeeds across various vulnerability types. Therefore, Patch Generator and Patch Reviewer modules are involved into an automated iterative repair process, where Patch Generator produces candidate patch, which is reviewed by Patch Reviewer and a static analysis tool. Lastly, the best patch among all the patches generated through the

In this section, we present Agentic Retrieval Augmented Generation for Automated Vulnerability Repair (RAVEN), a scalable and efficient framework designed to autonomously repair real-world software vulnerabilities. RAVEN introduces retrieval-augmented generation (RAG) into the automated vulnerability repair pipeline, enabling the model to leverage external security knowledge during patch generation. Building on this foundation, RAVEN further incorporates an agentic RAG methodology, where the retrieval process is actively guided by lexical, semantic, and syntactic vulnerability patterns derived from publicly disclosed vulnerabilities (e.g., CVEs), while agent-based reasoning dynamically identifies and retrieves relevant contextual information from the project repository. This enables the framework to capture cross-file and global code dependencies automatically and perform more context-aware repair beyond localized code regions.

3

1 Similar Retrieval and ⃝ 2 Context Retrieval extracts and Figure 3: RAVEN’s Repair Workflow with its four phases. ⃝ 3 Iterative repair brings out the best plausible patch for the provides various useful information to the Patch Generator. ⃝ 4 Verification where the plausible patch is vulnerability through numerous iterations between generator and reviewer. ⃝ validated against the ground truth patch; Color schema: Gray → Data, orange → Agents, Yellow → prompts, Blue → Tools, Red → Vulnerable, Green → Fix iterations is served as an input to Patch Validator module. Patch Validator uses a dedicated LLM configuration and standard code semantic metrics to independently assess the quality of the final patch before it is reported as validated.

3.2. Repair Work Flow Figure 3 illustrates the end-to-end repair workflow of RAVEN. There are four key work phases in the framework 1 Semantic Retrieval, ⃝ 2 Context Retrieval, ⃝ 3 Iterative ⃝ 4 Verification. Repair and ⃝ 3.2.1. Semantic Retrieval. The Semantic Retriever module mitigates spurious pattern learning and hallucinations in the Patch Generator by retrieving highly relevant and semantically similar historical vulnerability fixes to guide patch generation. To improve retrieval robustness, the module employs multiple specialized retrievers, each designed to capture different vulnerability-related patterns in the vulnerable code, enabling a multi-faceted retrieval process. The goal of the Semantic Retriever is to dynamically identify the most relevant historical fix patches corresponding to the same or closely related vulnerability types. These retrieved patches are augmented into the prompt template of the Patch Generator, directing and constraining the repair process toward more accurate and consistent patch generation. To support this retrieval process, we construct a dedicated RAG database as shown in Figure 4) from a com-

Figure 4: Semantic Retriever Module

prehensive real-world Common Vulnerabilities and Exposures (CVE) dataset, namely the CVEFixes[27] dataset. The database contains diverse vulnerability instances, their corresponding fix patches, and associated metadata. Specifically, we curate a broad set of CVEs covering the targeted CWEs, enabling retrieval across a wide range of vulnerability patterns. As new vulnerability types and recently

4

disclosed CVEs become available, the database can be continuously extended, making RAVEN adaptable and scalable. Retrieving the most relevant vulnerability patch, however, remains challenging. Including multiple retrieved patches in the prompt may introduce ambiguity, potentially confusing the LLM and diverting the repair process. Likewise, excessive contextual information can act as noise within the model’s limited context window. Effective retrieval and careful prompt context management are therefore critical for reliable repair. To address these challenges, we introduce a multifaceted retrieval strategy that retrieves candidate patches based on four complementary vulnerability patterns. Each retriever operates independently on a specific representation and recommends only the single most relevant patch according to its retrieval criterion. Because retrieval is performed across distinct lexical, syntactic, and semantic perspectives, the resulting recommendations are often diverse and complementary. To enable this process, we perform a dedicated data preprocessing step that transforms historical vulnerability and fix data into multiple (particularly, four) representations capturing lexical, syntactic, and semantic repair cues, as illustrated in Figure 4. These representations form the foundation of the retrievers within the Semantic Retriever module. A Selector Agent then evaluates the retrieved candidates and identifies the single most suitable patch to guide repair according to predefined selection criteria. Preprocessed Representations Below, we describe the four distinct preprocessed representations used in the Semantic Retriever. 6 Keyword: A concise six-keyword representation is constructed by extracting the most salient lexical cues from the CVE description and the corresponding vulnerable code context. This representation is particularly effective for frequently occurring vulnerabilities within the same CWE, where a small set of discriminative lexical signals is often sufficient for accurate retrieval. 40 Keyword: A richer forty-keyword representation is constructed using an expanded set of lexical cues derived from the CVE description, code context, and associated metadata. The choice of forty keywords is based on empirical evaluation, balancing broader contextual coverage with the need to minimize retrieval noise. Vulnerable Code: The exact vulnerable code snippet is extracted and stored as a separate representation, preserving the syntactic structure of the vulnerability. This pattern leverages syntax-level cues, which can be particularly effective for vulnerability types where structural code patterns provide strong retrieval signals. Code Property Graphs (CPGs): Code Property Graphs are generated using the Joern tool [28], providing a unified representation of the vulnerable code’s syntax, control flow, and data dependencies. This representation enables deeper semantic retrieval by capturing structural and behavioral similarities across vulnerability instances. Retrieval Mechanism A sparse retrieval mechanism such as BM25 [29] is used to query the RAG database for each preprocessed representation, enabling a multi-faceted

retrieval process. Each retriever independently retrieves the most relevant historical vulnerability patch for its respective pattern. A deduplication step removes overlapping results to ensure diversity in the final candidate set. The resulting patches are then passed to the Selector Agent (see Figure 4), which evaluates them using predefined criteria and selects the single most relevant patch to guide the Patch Generator module. Selection Criteria The Selector Agent evaluates candidate patches based on the following key selection criteria: (1) prioritizing the underlying vulnerability root cause over superficial attributes such as file names, function names, or CVE identifiers; (2) favoring patches that exhibit the most similar repair strategy and security logic, including bounds validation, length checks, null handling, and state consistency; (3) avoiding reliance on superficial textual overlap and instead emphasizing semantic equivalence in the applied fix; (4) resolving inconsistencies between the CWE description and the vulnerable code by prioritizing the actual code pattern and its implied root cause; and (5) treating patches that replicate logic already present in the vulnerable code with caution to account for dataset noise or previously patched code fragments. The prompt template for semantic retrieval is provided in the Appendix C. 3.2.2. Context Retrieval. Most of the existing vulnerability repair tools[20], [18], [19] address vulnerabilities based on the vulnerable code, logs, metadata, and recommended exemplars, which constrain the tool’s access to only the local context of the vulnerable code and which can significantly impact the success of automated repair. Moreover, for certain vulnerability types, it is nearly impossible to accurately analyze and fix the vulnerability by considering only the local context of the code. Addressing this challenge, RAVEN introduces a dedicated Context Retriever module, which operates in parallel with the Semantic Retriever module to retrieve global context and dependency code snippets from the project repository. Specifically, A dedicated Curator Agent is designed to retrieve these dependencies as shown in Figure 3. The retrieved context is then provided as an additional input to the Patch Generator module ultimately guiding the repair process. Algorithm 1 illustrates the detailed workflow of the Context Retriever module. The module takes as input the vulnerable code v , vulnerability metadata c, and target file path f and produces a potential root-cause description, repair constraints, and single or multiple dependency code snippets as output. We design and equip the Curator agent 1 read bundle, with five tool-calling operations, namely ⃝ 2 search repo, ⃝ 3 find symbol, ⃝ 4 read file, and ⃝ 5 finish curating. The exploration is performed it⃝ eratively over a bounded number of steps (line 4 in algorithm 1), where at each iteration the agent selects a single tool based on the current context and accumulated observations to progressively refine its understanding of the vulnerability. The Curator Agent begins exploration with an initial 1 read bundle call (line 5 in algorithm 1), which provides ⃝

5

Algorithm 1 Context Retrieval

erator and the Patch Reviewer, as illustrated in the middle section of Figure 3. The Patch Reviewer, instantiated using the same LLM model as Patch Generator, evaluates each generated patch according to predefined repair criteria. In addition, a static application security testing (SAST) tool, Semgrep [30], is used to analyze the generated patch for potential security issues and rule violations. The reviewer’s structured feedback, together with the SAST report, is then returned to the Patch Generator to guide subsequent repair iterations. This iterative refinement process enables the framework to progressively improve patch correctness and reduce ineffective or suboptimal repairs. Patch Generator: The Patch Generator is guided by the 1 prioritizing the concrete vulnerfollowing principles: ⃝ ability root cause over superficial similarity to retrieved 2 applying the smallest targeted fix necessary patches; ⃝ to eliminate the unsafe behavior while preserving exist3 avoiding unnecessary refactoring, ing program logic; ⃝ renaming, formatting changes, or modifications to unrelated 4 refraining from introducing new helper code regions; ⃝ functions, macros, types, or external dependencies unless 5 reusing existing clearly implied by the provided context; ⃝ validation patterns, control flow, and error-handling mecha6 nisms to maintain consistency with the surrounding code; ⃝ ensuring syntactic correctness and coherence with the local 7 restricting the output to a single code code structure; ⃝ block containing only the minimal fixed code snippet(s); 8 omitting any additional explanatory text outside and ⃝ the code block. Additional language-specific and revisionrelated requirements are provided in the prompt templates in Appendix C. Patch Reviewer: Patch Reviewer evaluates each generated 1 disregarding patch according to the following criteria: ⃝ unused helper methods, dead code, comments, logging state2 verments, and formatting-only changes as valid repairs; ⃝ ifying that the introduced security logic is executed on the 3 enactual runtime path before or at the vulnerable sink; ⃝ suring that, for vulnerabilities involving library misuse, the patch replaces, intercepts, or mitigates the exact affected 4 comparing the current patch against runtime behavior; ⃝ the previous iteration strictly in terms of vulnerability-fixing 5 identifying regressions only when a effectiveness; and ⃝ new patch weakens existing protection, reintroduces the vulnerability, or replaces an effective fix with an ineffective or irrelevant modification. Controlling the behavior of the LLM within the Patch Generator is challenging due to the probabilistic nature of language models. To guide patch generation effectively, RAVEN injects the outputs of the Semantic Retriever and Context Retriever into the prompt template of the Patch Generator. The prompt assigns a specific repair objective, defines explicit rules and constraints, and provides all necessary contextual information in a concise manner. Based on this augmented context, the Patch Generator produces an initial fix patch for the given vulnerability. To further improve patch quality, RAVEN employs an iterative feedback loop between the Patch Generator and the Patch Reviewer, as illustrated in the middle section

Input: metadata c, file path f , vulnerable code v Output: Root cause, repair constraints, dependency code 1: Initialize trace T ← ∅ 2: Load v from f and metadata c 3: Construct prompt with metadata c, file f , & trace T 4: for i = 1 to N do // Agent selects next tool // Load structured 5: if agent calls read bundle then summary of the target file, symbols, callers, callees, tests, build files else if agent calls search repo then // Search repo for relevant patterns with literal or regex search // Retrieve 7: else if agent calls find symbol then symbol definitions and caller relationships 8: else if agent calls read file then // Read selected line ranges from repo files for detailed inspection 9: else if agent calls finish curating then 10: return root cause, dependency code, & con6:

straints 11: end if 12: Append tool observation to trace T 13: end for 14: return retrieved context

a structured summary of the target file, including methodlevel information, related symbols, and caller–callee rela2 search repo tionships. Subsequently, the Agent utilizes ⃝ (line 6 in algorithm 1) to locate relevant code patterns across the repository using keyword or regex-based search. It 3 find symbol (line 7 in algorithm 1) to identify employs ⃝ symbol definitions and trace caller relationships for cross4 read file (line 8 in file dependency analysis. Further, ⃝ algorithm 1) is used to inspect selected file regions from the repository in detail and extract relevant dependency 5 finish curating (line 9 in code snippets. Finally, ⃝ algorithm 1) explicitly terminates the exploration and returns the found dependency code snippets, root cause and a list of repair constraints. This Agentic exploration loop continues until a hard limit of 10 steps is reached. The 10 step limit is chosen empirically as a balance between collecting sufficient dependency context and avoiding unproductive exploration. A shorter limit may risks missing key dependency context, whereas an unbounded loop would significantly increase runtime cost. 3.2.3. Iterative Repair. Controlling the behavior of the LLM within the Patch Generator is challenging due to the probabilistic nature of language models. To guide patch generation effectively, RAVEN injects the outputs of the Semantic Retriever and Context Retriever into the prompt template of the Patch Generator. The prompt assigns a specific repair objective, defines explicit rules and constraints, and provides all necessary contextual information in a concise manner. Based on this augmented context, the Patch Generator produces an initial fix patch for the given vulnerability. To further improve patch quality, RAVEN employs an iterative feedback loop between the Patch Gen-

6

CWE 787[32] 125[33] 79[34] 89[35] 94[36] 22[37] 502[38] 352[39] 862[26] 863[40]

of Figure 3. The Patch Reviewer, instantiated using the same LLM model as the generator, evaluates each generated patch according to predefined repair criteria. In addition, Semgrep [30], is used to analyze the generated patch for potential security issues and rule violations. Patch Reviewer’s structured feedback, together with the SAST report, is then returned to the Patch Generator to guide subsequent repair iterations. 3.2.4. Verification. Right side of Figure 3 illustrates the final Patch Validator module, which evaluates the most promising patch produced by the iterative repair process. This stage performs multi-faceted validation by combining LLM-based assessment with quantitative semantic similarity analysis. The generated patch is first compared against the ground truth fix, which is available for each real-world CVE in the evaluation dataset. A dedicated Patch Validator, instantiated using a distinct LLM from the previous modules, acts as an expert judge under a strict evaluation guideline. The validator assesses the generated patch in relation to the ground truth patch and uses commit information as additional input, considering factors such as repair correctness, completeness, alignment with the intended vulnerability resolution, and consistency with expected repair patterns. Based on this assessment, each patch is classified into one of three categories: Full Fix Patch, Partial Fix, or No Fix. To complement the LLM-based judgment, a CodeBLEU [31] score is computed between the generated patch and the ground truth fix. Unlike exact string matching, CodeBLEU captures structural and semantic similarity, providing a quantitative measure of repair quality. Together, the LLMbased evaluation and CodeBLEU scoring provide a robust validation strategy for assessing both functional correctness and semantic alignment with the expected fix. Summary Overall, RAVEN is a modular agentic framework that combines multi-faceted retrieval, repository-level context reasoning, iterative patch refinement, and independent validation to enable robust vulnerability repair. It systematically guides LLM-based patch generation toward root-cause fixes while improving reliability through structured feedback and semantic verification.

Description Out-of-bounds Write Out-of-bounds Read Cross-site Scripting (XSS) SQL Injection Code Injection Path Traversal Untrusted Deserialization Cross-Site Request Forgery Missing Authorization Incorrect Authorization

Cluster Memory Memory Injection Injection Injection Input Handling Input Handling Access Control Access Control Access Control

TABLE 1: Targeted 10 Java CWE categories patterns. This diversity allows us to assess the effectiveness of RAVEN in handling both localized vulnerabilities and those requiring cross-file dependencies and semantic understanding. The complete list of targeted CWEs and their categorization is shown in Table 1. Datasets: We leverage publicly available real-world vulnerability datasets to evaluate RAVEN. Our primary dataset is CVEFixes [27], from which we extract and preprocess vulnerabilities corresponding to 10 targeted Java-based CWE categories. To assess generalization beyond the primary dataset, we additionally evaluate RAVEN on the Vul4J dataset [41], which contains real-world Java vulnerabilities outside our primary CVEFixes [27] dataset and serves as an out-of-distribution benchmark. To assess RAVEN on C programs, we further randomly select vulnerabilities corresponding to CWE-125 [33] (Out-of-bounds Read) and CWE-863 [40] (Incorrect Authorization) from the CVEFixes [27]. Furthermore, we adopt a subset of the Zero-Day C language dataset introduced in APPATCH [20], consisting of vulnerabilities reported after 2024, to evaluate RAVEN on recently disclosed and diverse vulnerability instances. This subset includes diverse unseen vulnerability types such as CWE-835 [42] (Loop with Unreachable Exit Condition), CWE-828 [43] (Signal Handler with Non-reentrant Function), CWE-770 [44] (Allocation of Resources Without Limits or Throttling), CWE-476 [45] (NULL Pointer Dereference), CWE-416 [46] (Use After Free), CWE-281 [47] (Improper Preservation of Permissions), and CWE-96 [48] (Improper Neutralization of Directives). Notably, these CWE categories are not included in the RAG database of RAVEN, challenging its ability to repair previously unseen vulnerability types and generalization capability.

4. Evaluation This section evaluates RAVEN across diverse vulnerability types in Java and C, focusing on its ability to generate correct fixes.

4.2. Experimental Setup and Evaluation Metrics

4.1. Targeted Vulnerabilities

LLMs: We employ recent open-source state of the art LLMs as core components within RAVEN to ensure both effectiveness and practical deployability. Specifically, we use Gemma-4-26B [22] for Patch Generator and Patch Reviewer modules, and Nemotron-3-30B [23] for the Patch Validator module. To ensure efficient local deployment, all models are executed in 4-bit quantized format using the Q4 K M scheme. Here, Q4 denotes 4-bit weight quantiza-

To evaluate the robustness and generalizability of RAVEN, we select a diverse set of real-world vulnerability types based on widely reported CWEs. The selected vulnerabilities span multiple categories, including memory safety, injection, access control, and input handling, ensuring broad coverage across different root causes and exploitation

7

4.3. Performance on 10 Java-Based CWEs

tion, K refers to a grouped (K-quant) quantization strategy that preserves accuracy through shared scaling factors, and M represents a medium configuration that balances computational efficiency and model fidelity. Hardware: All experiments were conducted on a local AI workstation running Windows 11 Pro, equipped with an Intel® Core™ Ultra 7 processor (up to 5.5 GHz, 20 cores), 32 GB DDR5 memory, and an NVIDIA RTX™ 2000 Ada Generation GPU with 16 GB VRAM. The system includes 1 TB PCIe Gen5 NVMe SSD storage and integrated Intel® graphics support. Evaluation Metrics: To comprehensively assess the performance of RAVEN, we evaluate the quality and effectiveness of the generated patches based on three outcome categories: Correct, Partial Fix, and Failed. • Correct Fix implies that the generated patch completely mitigates the underlying vulnerability without introducing new vulnerability and preserves the intended functionality. The patch does not need to match the ground truth exactly at the syntactic or semantic level, provided that it is securityequivalent. • Partial Fix indicates that the patch mitigates the security vulnerability but introduces functional inconsistencies or breaks intended functionality. Such patches are still considered partial security fixes, even if they are not fully functionally correct. • Failed indicates that the patch does not resolve the underlying vulnerability and the vulnerable behavior remains present. This category also includes patches that introduce new vulnerabilities or other significant issues. • Repair Success Rate (RSR) measures the proportion of vulnerabilities successfully addressed by RAVEN, including both fully correct and partial fixes.

The results presented in Table 2 demonstrate the effectiveness of RAVEN across diverse vulnerability families. For memory-based vulnerabilities (CWE-787, CWE-125), RAVEN achieves a perfect repair success rate of 100%, with all instances successfully mitigated, indicating strong capability in handling localized memory safety issues. Moving to injection-based vulnerabilities (CWE-79, CWE-89, CWE94), the framework achieves high success rates of 86.67% for both XSS and SQL injection, while code injection (CWE-94) achieves a success rate of 66.67%, reflecting the increased complexity of semantic program transformations required for such vulnerabilities. For input handling vulnerabilities (CWE-22, CWE-502), RAVEN maintains strong performance with success rates of 85.71% and 100.00%, respectively, demonstrating its ability to handle vulnerabilities involving external input validation and sanitization across different contexts. Access control vulnerabilities (CWE-352, CWE-862, CWE-863) exhibit consistently strong but still varied performance, with success rates ranging from 75.00% to 100.00%. While RAVEN effectively mitigates all cases of missing authorization (CWE-862 at 100.00%), the relatively lower performance on CWE-352 highlights the challenges associated with correctly identifying and enforcing security checks in access-control-related workflows. Overall, out of 83 real-world vulnerabilities, RAVEN successfully repairs 72 instances (including both correct and partial fixes), achieving an overall repair success rate of 86.75% across all 10 CWE categories, indicating robust performance across diverse vulnerability types. Furthermore, the consistently high CodeBLEU scores (average 0.815) suggest that the generated patches not only address the vulnerabilities but also maintain strong syntactic and semantic similarity to the ground truth, underlying the quality and reliability of the repair process. To the best of our knowledge, no existing automated repair framework explicitly targets Javabased CWEs spanning access control, SQL injection, code injection, and memory-related vulnerabilities. As a result, direct benchmark comparisons are currently unavailable, and the results reported for RAVEN provide an initial reference point for this setting.

RSR = (Correct + Partial Fix)/Total Instances × 100 Following common evaluation practices in prior automated vulnerability repair research [21], [18], [19], partial fixes are also considered successful repairs when the generated patch mitigates the underlying vulnerability, even if complete functional correctness is not preserved. • CodeBLEU Score[31]: a code similarity metric that captures syntactic structure, data-flow, and semantic alignment between the generated patch and the ground truth patch. The score ranges from 0 to 1, where higher values indicate greater similarity. In our context, CodeBLEU serves as a complementary metric to correctness-based evaluation. A high CodeBLEU score (e.g., > 0.7) generally indicates strong structural and semantic similarity between the generated patch and the ground truth implementation. However, lower scores do not necessarily imply an incorrect repair, as security-equivalent patches may differ syntactically or adopt alternative implementation strategies while still effectively mitigating the vulnerability.

4.4. Generalizability on Unseen Vulnerabilities To evaluate the generalization capability of RAVEN and enable comparison with existing repair tools, we consider a set of real-world CVEs from the CVEFixes dataset [27] that fall outside our targeted CWE categories but are shared across multiple prior repair frameworks. These vulnerabilities are in C programs, which introduces additional challenge such as cross-language repair with the limited availability of closely related vulnerability patches within the retrieval database. As shown in Table 3, the selected CVEs cover a range of memory safety and arithmeticrelated weaknesses, including CWE-119, CWE-125, CWE190, CWE-369, and CWE-787.

8

TABLE 2: Repair performance for each CWE type. Green denotes correct, olive denotes partial, and red denotes failed fixes CWE

Files Correct Partial Failed

Repair CodeBLEU CVEs Success Rate Score

CWE-787

1

0

1

0

100.00%

0.630

CVE-2023-26470 (P)

CWE-125

3

3

0

0

100.00%

0.896

CVE-2020-25021, CVE-2020-25022, CVE-2020-25023

CWE-79

15

9

4

2

86.67%

0.872

CVE-2013-7250, CVE-2014-2065, CVE-2018-1000129 (P), CVE-201825084, CVE-2021-4284 (F), CVE-2021-43288, CVE-2022-3127 (F), CVE2022-32065, CVE-2022-4513 (P), CVE-2022-4560, CVE-2022-4593 (P), CVE-2023-29528, CVE-2023-32070 (P), CVE-2023-33962, CVE-20237171

CWE-89

15

7

6

2

86.67%

0.772

CVE-2013-10019 (P), CVE-2014-125047 (P), CVE-2014-125052, CVE2014-125074 (P), CVE-2015-10020, CVE-2015-10034 (P), CVE-201615021, CVE-2016-4040, CVE-2016-6652 (F), CVE-2022-4963 (P), CVE2023-25157, CVE-2023-25158 (P)

CWE-94

6

1

3

2

66.67%

0.844

CVE-2021-21244 (P), CVE-2021-21248, CVE-2021-32621 (P), CVE-202224816 (P), CVE-2022-46166 (F), CVE-2023-46243 (F)

CWE-22

21

15

3

3

85.71%

0.802

CVE-2018-14371, CVE-2018-9159 (F), CVE-2020-6950, CVE-2021-32769, CVE-2021-3856 (P), CVE-2021-39180, CVE-2021-41152 (F), CVE-202141242 (P), CVE-2021-43795 (P), CVE-2022-21675, CVE-2022-24830, CVE-2022-29253, CVE-2023-37913, CVE-2024-21633, CVE-2024-24565 (F)

CWE-502

6

3

3

0

100.00%

0.879

CVE-2018-6331, CVE-2021-21242, CVE-2021-21243 (P), CVE-202121249 (P), CVE-2021-32634, CVE-2022-41958 (P)

CWE-352

4

2

1

1

75.00%

0.748

CVE-2013-7251, CVE-2014-0120 (F), CVE-2014-0168 (P)

CWE-862

6

3

3

0

100.00%

0.849

CVE-2020-10194, CVE-2022-23617, CVE-2022-23621 (P), CVE-202241929 (P), CVE-2023-37910 (P)

CWE-863

6

4

1

1

83.33%

0.748

CVE-2020-19005 (P), CVE-2021-21318, CVE-2021-32620, CVE-202239302, CVE-2023-26056 (F)

10 CWEs

83

47

25

11

86.75%

0.815

–

TABLE 3: Comparison with recent existing repair tools. Baseline results are reported from their papers; ✓denote correct and partial repairs; ✗denote failures, and “–” denotes unavailable CVE

CWE

Target File

CVE-2016-8691 CVE-2016-9387 CVE-2018-14498 CVE-2016-5314 CVE-2016-9557 CVE-2016-5844 CVE-2016-10092 CVE-2016-10272 CVE-2017-5225

CWE-369 CWE-190 CWE-125 CWE-787 CWE-190 CWE-190 CWE-119 CWE-119 CWE-119

jpc cs.c jpc dec.c rdbmp.c tif pixarlog.c jpg dec.c archive read support format iso9660.c tiffcrop.c tiffcrop.c tiffcp.c

RAVEN SAN2PATCH[18] PatchAgent[19] ExtractFix[21] VulnFix[49] VulMaster[15] ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗

✗ – ✓ – ✓ ✓ ✓ ✓ ✓

✓ ✓ ✓ ✓ – – – – –

✓ ✓ ✗ ✗ – – – – –

✓ – ✗ – ✗ ✓ ✗ ✗ ✗

✓ – ✗ – ✗ ✗ ✗ ✗ ✗

these vulnerability categories. Other approaches, including ExtractFix [21], VulnFix [49], and VulMaster [15], show limited or inconsistent coverage across the evaluated CVEs, with multiple instances either unsupported or failing to produce valid repairs. These results highlight the difficulty of generalizing automated vulnerability repair across diverse vulnerability classes and suggest that RAVEN generalizes effectively to previously unseen vulnerabilities.

Across these instances, RAVEN produces correct fixes for 7 out of 9 CVEs, failing on two cases corresponding to CWE-787 and CWE-119. For comparison, we report baseline results as presented in the respective papers, while RAVEN is evaluated directly on the selected CVEs. At the per-CVE level, SAN2PATCH [18] successfully repairs several memory-related vulnerabilities (e.g., CWE-125 and CWE-119), but fails or is not applicable in other cases such as CWE-369. PatchAgent [19] exhibits complementary behavior, successfully handling some arithmetic-related vulnerabilities (e.g., CWE-190 and CWE-369), but without consistent coverage across all evaluated instances. In contrast, RAVEN demonstrates competitive performance across most CVEs despite not being specifically designed for

4.5. Evaluation on Out-of-Distribution data 4.5.1. Generalization on Vul4J Dataset. To further evaluate the generalization capability of RAVEN, we conduct experiment on a subset of 23 randomly selected CVEs

9

TABLE 4: RAVEN performance on out-of-distribution data. CWEs CWE-835, CWE-20, CWE-22, CWE-611, CWE-79, CWE-269, CWE-310, CWE-532, CWE-770, CWE-918

CVEs Correct Partial Fail

23

10

5

8

Succ. Rate

TABLE 5: RAVEN performance on 2024 CVEs from APPATCH[20] dataset. ✓mark correct and partial repairs; ✗mark failures

Code BLEU

CVE CVE-2024-2397 CVE-2024-2397 CVE-2024-24746 CVE-2024-25742 CVE-2024-25742 CVE-2024-28871 CVE-2024-29489 CVE-2024-29489 CVE-2024-31578 CVE-2024-32002 CVE-2024-32020 CVE-2024-32487 CVE-2024-32658 CVE-2024-32659 CVE-2024-32661 CVE-2024-32662

65.22% 0.897

from the Vul4J[41] dataset, specifically focusing on the single-file-commit setting. These vulnerabilities span multiple CWE categories (e.g., CWE-835, CWE-20, CWE22, CWE-611, CWE-79, CWE-269, CWE-310, CWE-532, CWE-770, CWE-918), most of which are not part of the targeted CWE categories in our retrieval database, thereby representing a true out-of-distribution evaluation setting. As shown in Table 4, RAVEN produces 15 successful repairs including 10 correct and 5 partial fixes, resulting in a repair success rate of 65.22%. Despite the absence of similar vulnerability patterns in the retrieval database and the diversity of unseen CWE types, the framework demonstrates remarkable performance across these CVEs. Furthermore, the average CodeBLEU score of 0.897 indicates that the generated patches maintain strong structural and semantic similarity to the ground truth. Overall, these results suggest that RAVEN is capable of adapting to unseen vulnerability types and generating meaningful repairs beyond its primary evaluation scope.

CWE CWE-835 CWE-835 CWE-835 CWE-828 CWE-828 CWE-770 CWE-476 CWE-476 CWE-416 CWE-22 CWE-281 CWE-96 CWE-125 CWE-125 CWE-476 CWE-125

Target File RAVEN print-ppp.c ✗ print.c ✓ ble hs conn.c ✓ sev-shared.c ✓ sev.c ✓ http request.c ✓ ecma-function-object.c ✓ ecma-proxy-object.c ✓ hwcontext.c ✓ submodule--helper.c ✓ clone.c ✓ filename.c ✓ interleaved.c ✓ color.c ✓ info.c ✗ redirection.c ✓

(e.g., 14,404 and 24,487 tokens on average, respectively), indicating a more balanced distribution of computational cost across the pipeline. Time Cost In terms of execution time, RAVEN remains efficient despite operating in a local setup. The Context Retrieval and Patch Generator modules account for the majority of the runtime, with average times of 155.0 seconds and 206.4 seconds across all the experimental settings as shown in Table 6. The higher cost in the Patch Generator module is attributed to the automated iterative repair process, where patches are refined over multiple controlled iterations. Although this iterative process increases execution time, it significantly improves repair quality, particularly for complex vulnerabilities. Overall, the end-to-end repair time of RAVEN averages around 7–8 minutes per vulnerability, which is substantially lower than recent tools such as PatchAgent [19], where even the fastest configuration reports 28.7 minutes per repair, demonstrating a significant improvement in repair efficiency.

4.5.2. Evaluation on Recent Vulnerabilities. Furthermore, we evaluate RAVEN on a subset of vulnerabilities from the Zero-Day dataset introduced in APPATCH [20], consisting of recently disclosed CVEs (2024) in C programs. These instances cover diverse CWE categories (e.g., CWE835, CWE-828, CWE-770, CWE-476, CWE-416, CWE-22, CWE-281, CWE-96, CWE-125), including some vulnerability types that are not part of the targeted CWE categories in our retrieval database. As shown in Table 5, RAVEN successfully repairs 14 out of 16 cases, including 11 correct and 3 partial fixes, with only two failed instances. We note that APPATCH[20] does not report per-CVE repair results, which limits direct comparison at a fine-grained level. Nevertheless, the observed results indicate that RAVEN is capable of generating effective repairs on recently disclosed and diverse vulnerability instances.

Overall, the experimental results demonstrate that RAVEN can repair a broad range of real-world vulnerabilities across diverse CWE categories and evaluation settings. Beyond strong performance on the targeted Java-based vulnerabilities, RAVEN also generalizes to previously unseen vulnerability types, recent CVEs, cross-dataset evaluations, and vulnerabilities in C programs. The results further suggest that the combination of agentic retrieval, repositorylevel contextual reasoning, and iterative refinement enables RAVEN to generate effective and semantically meaningful repairs across diverse vulnerability classes. Consistently high CodeBLEU scores additionally indicate strong structural and semantic alignment with ground truth fixes, highlighting the potential of agentic RAG-based approaches for scalable and context-aware automated vulnerability repair.

4.6. RAVEN’s Efficiency Token Cost RAVEN leverages the Google Gemma-426B [22] model in a fully local deployment setting. As an open-source model, it eliminates reliance on proprietary LLM services and associated API costs. As shown in Table 6, the Context Retrieval module accounts for the highest token consumption across all evaluation settings (e.g., 99,509 tokens on average), since it is responsible for repository-level analysis, including the retrieval of cross-file dependencies and global contextual information. In contrast, the Semantic Retriever and Patch Reviewer modules exhibit comparatively lower token usage

10

TABLE 6: RAVEN efficiency in terms of token and time cost Semantic Retrieval (tokens / sec)

Context Retrieval (tokens / sec)

Patch Generator (tokens / sec)

Patch Reviewer (tokens / sec)

Table 2 Average on 10 Java CWEs Table 7 C CWEs (125 and 863) Table 3 Unseen Vulnerabilities in C Table 5 Unseen CVEs 2024 from APPATCH

13013 / 48.15 12943 / 70.2 40745 / 64.3 14560 / 38.7

100108 / 147 86379 / 194.5 142487 / 155.9 116208 / 148.2

30469 / 172.25 35981 / 253.4 161009 / 261.8 37385 / 196.7

14282 / 50.4 17179 / 78.4 147343 / 118.3 23987 / 52.2

Average

14404 / 51.9

99509 / 155.0

41773 / 206.4

24487 / 62.4

Vulnerabilities

5. Related Work

AST structure and CWE knowledge for patch generation. However, it relies on explicitly specified modification locations. Pearce et al. [16] study zero-shot vulnerability repair, highlighting prompt-design challenges in generating suitable fixes. Although effective on synthetic cases, it struggles to produce functionally correct patches for real CVEs. RAPGen [17] introduces a retrieval-augmented LLM framework that leverages CodeT5 to retrieve relevant bug-fix patterns through lexical and semantic matching. Zhang et al. [58] present a comparative study evaluating LLMs and DL-based APR frameworks. VRepair [12] and SeqTrans [13] leverage pre-training on large-scale bug-fixing data followed by finetuning on smaller vulnerability datasets. Nevertheless, VulRepair [14] outperforms both approaches, although some of its limitations are later addressed by VulMaster [15]. Summary It is evident that, although various frameworks have been proposed, none match the effectiveness of RAVEN in achieving high repair success across different experimental settings. RAVEN is the first framework to target diverse vulnerability types and multiple programming languages while demonstrating strong generalization to previously unseen vulnerability types with negligible repair cost.

Automated Program Repair (APR) Search-based APR aims to identify correct patches from a predefined search space using mutation operators and test-suite validation. Approaches such as CapGen[2], sharpFix[3], and VarFix [50] leverage contextual information, code reuse, and variational execution but they often suffer from search space explosion and frequently fail when the correct patch is absent from the mutation space [51]. Semantic-based APR reduces the search space by leveraging symbolic execution and program semantics to derive repair constraints [52]. Techniques such as SOSRepair[4], Maple[5], VulnFix [49] and ExtractFix [21] generate patches that satisfy these constraints, improving efficiency but limiting adaptability when formal constraints fail to capture the underlying bug semantics. Template-based APR relies on predefined fix patterns extracted either manually or automatically. Works such as PAR [6], kPAR [7], and Relifix [53] use expert-defined patterns, while Genesis [54], AVATAR [8], and TBar [55] automate pattern generation. While effective for recurring bug patterns, these methods depend heavily on accurate fault localization and suitable templates, restricting generalization to unseen or complex vulnerabilities. Learning-based APR models program repair as a sequence-to-sequence transformation from buggy to fixed code. Approaches such as Sequencer [9] and DeepRepair [10] use neural models and code similarity to improve repair generation, while DLFix [56], CoCoNuT [11], and Review4Repair [57] incorporate program representations (ASTs) or human-written review information for richer context. Nevertheless, these methods remain limited for complex, context-dependent vulnerabilities due to their reliance on localized representations and training data. LLM-based Vulnerability Repair PatchAgent [19] introduces an agent-based framework combining fault localization, patch generation, and validation. However, it requires substantial repair time and incurs high financial costs due to its reliance on proprietary LLMs. APPATCH [20] proposes an LLM-based framework using adaptive prompting. Nevertheless, it depends on explicitly providing vulnerability location and type within prompts, limiting its autonomy. SAN2PATCH [18] leverages sanitizer logs with multi-stage LLM reasoning to generate patches. However, its applicability is limited to vulnerabilities with available sanitizer logs. Moreover, these frameworks [18], [20], [19] focus only on memory and arithmetic-related vulnerabilities. VulMaster [15] employs a CodeT5-based model incorporating

6. Conclusion To conclude, RAVEN presents a scalable and autonomous framework for automated vulnerability repair based on agentic retrieval-augmented generation and an iterative repair mechanism. By combining historical fix retrieval, repository-level context retrieval, and iterative patch refinement, RAVEN effectively addresses complex vulnerabilities that cannot be resolved using local vulnerable code alone. Our evaluation demonstrates strong repair performance across diverse vulnerability types, unseen CWE categories, and additional programming language settings, while maintaining efficient, low-cost deployment through locally deployable open-source LLMs.

References

11

[1]

“46 Vulnerability Statistics 2026: Key Trends in Discovery, Exploitation, and Risk,” 2026. [Online]. Available: https://security boulevard.com/2026/03/46-vulnerability-statistics-2026-key-trends-i n-discovery-exploitation-and-risk/

[2]

M. Wen, J. Chen, R. Wu, D. Hao, and S.-C. Cheung, “Contextaware patch generation for better automated program repair,” in Proceedings of the 40th International Conference on Software

Engineering, ser. ICSE ’18. New York, NY, USA: Association for Computing Machinery, 2018, p. 1–11. [Online]. Available: https://doi.org/10.1145/3180155.3180233 [3] Q. Xin and S. Reiss, “Better code search and reuse for better program repair,” in 2019 IEEE/ACM International Workshop on Genetic Improvement (GI), 2019, pp. 10–17. [4] A. Afzal, M. Motwani, K. T. Stolee, Y. Brun, and C. Le Goues, “Sosrepair: Expressive semantic search for real-world program repair,” IEEE Transactions on Software Engineering, vol. 47, no. 10, pp. 2162–2181, 2021. [5] T.-T. Nguyen, Q.-T. Ta, and W.-N. Chin, “Automatic program repair using formal verification and expression templates,” in Verification, Model Checking, and Abstract Interpretation, C. Enea and R. Piskac, Eds. Cham: Springer International Publishing, 2019, pp. 70–91. [6] D. Kim, J. Nam, J. Song, and S. Kim, “Automatic patch generation learned from human-written patches,” in 2013 35th International Conference on Software Engineering (ICSE), 2013, pp. 802–811. [7] K. Liu, A. Koyuncu, T. F. Bissyandé, D. Kim, J. Klein, and Y. Le Traon, “You cannot fix what you cannot find! an investigation of fault localization bias in benchmarking automated program repair systems,” in 2019 12th IEEE Conference on Software Testing, Validation and Verification (ICST), 2019, pp. 102–113. [8] K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyandé, “Avatar: Fixing semantic bugs with fix patterns of static analysis violations,” 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), pp. 1–12, 2019. [Online]. Available: https://api.semanticscholar.org/CorpusID:201043038 [9] Z. Chen, S. Kommrusch, M. Tufano, L.-N. Pouchet, D. Poshyvanyk, and M. Monperrus, “Sequencer: Sequence-to-sequence learning for end-to-end program repair,” IEEE Transactions on Software Engineering, vol. 47, no. 9, pp. 1943–1959, 2021. [10] M. White, M. Tufano, M. Martı́nez, M. Monperrus, and D. Poshyvanyk, “Sorting and transforming program repair ingredients via deep learning code similarities,” in 2019 IEEE 26th International Conference on Software Analysis, Evolution and Reengineering (SANER), 2019, pp. 479–490. [11] T. Lutellier, H. V. Pham, L. Pang, Y. Li, M. Wei, and L. Tan, “Coconut: combining context-aware neural translation models using ensemble for program repair,” ser. ISSTA 2020. New York, NY, USA: Association for Computing Machinery, 2020, p. 101–114. [Online]. Available: https://doi.org/10.1145/3395363.3397369 [12] 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. [13] J. Chi, Y. Qu, T. Liu, Q. Zheng, and H. Yin, “Seqtrans: Automatic vulnerability fix via sequence to sequence learning,” IEEE Transactions on Software Engineering, vol. 49, no. 2, pp. 564–585, 2023. [14] M. Fu, C. Tantithamthavorn, T. Le, V. Nguyen, and D. Phung, “Vulrepair: a t5-based automated software vulnerability repair,” ser. ESEC/FSE 2022. New York, NY, USA: Association for Computing Machinery, 2022, p. 935–947. [Online]. Available: https://doi.org/10.1145/3540250.3549098 [15] 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 IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY, USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10.1145/3597503.3639222 [16] H. Pearce, B. Tan, B. Ahmad, R. Karri, and B. Dolan-Gavitt, “Examining zero-shot vulnerability repair with large language models,” in 2023 IEEE Symposium on Security and Privacy (SP), 2023, pp. 2339–2356. [17] W. Wang, Y. Wang, S. Joty, and S. C. Hoi, “Rap-gen: Retrievalaugmented patch generation with codet5 for automatic program repair,” ser. ESEC/FSE 2023. New York, NY, USA: Association for Computing Machinery, 2023, p. 146–158. [Online]. Available: https://doi.org/10.1145/3611643.3616256

[18] Y. Kim, S. Shin, H. Kim, and J. Yoon, Logs in, patches out: automated vulnerability repair via tree-of-thought LLM analysis. USA: USENIX Association, 2025. [19] 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 Conference on Security Symposium, ser. SEC ’25. USA: USENIX Association, 2025. [20] 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 Conference on Security Symposium, ser. SEC ’25. USA: USENIX Association, 2025. [21] 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, Feb. 2021. [Online]. Available: https://doi.org/10.1145/3418461 [22] Google DeepMind, “Gemma 4,” 2026. [Online]. Available: https: //deepmind.google/models/gemma/gemma-4/ [23] NVIDIA Corporation, “Nemotron-3-30b,” 2025. [Online]. Available: https://build.nvidia.com/nvidia/nemotron-3-nano-30b-a3b/modelcard [24] “CVE-2023-37910,” 2023. [Online]. Available: https://www.cve.org/ CVERecord?id=CVE-2023-37910 [25] “XWiki Platform: An Open-Source Enterprise Wiki Framework.” [26] “CWE-862: Missing Authorization.” [Online]. Available: https: //cwe.mitre.org/data/definitions/862.html [27] G. Bhandari, A. Naseer, and L. Moonen, “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, ser. PROMISE 2021. New York, NY, USA: Association for Computing Machinery, 2021, p. 30–39. [Online]. Available: https://doi.org/10.1145/3475960.3475985 [28] J. Developers, “Joern: A tool for parsing and analyzing source code,” 2017. [Online]. Available: https://joern.io [29] S. Robertson and H. Zaragoza, “The probabilistic relevance framework: Bm25 and beyond,” Foundations and Trends in Information Retrieval, vol. 3, pp. 333–389, 09 2009. [30] Semgrep, Inc., “Semgrep: Lightweight static analysis for many languages,” https://github.com/semgrep/semgrep. [31] S. Ren, D. Guo, S. Lu, L. Zhou, S. Liu, D. Tang, N. Sundaresan, M. Zhou, A. Blanco, and S. Ma, “Codebleu: a method for automatic evaluation of code synthesis,” 2020. [Online]. Available: https://arxiv.org/abs/2009.10297 [32] “CWE-787: Out-of-bounds Write.” [Online]. Available: https: //cwe.mitre.org/data/definitions/787.html [33] “CWE-125: Out-of-bounds Read.” [Online]. Available: https: //cwe.mitre.org/data/definitions/125.html [34] “CWE-79: Improper Neutralization of Input During Web Page Generation (’Cross-site Scripting’).” [Online]. Available: https: //cwe.mitre.org/data/definitions/79.html [35] “CWE-89: Improper Neutralization of Special Elements used in an SQL Command (’SQL Injection’).” [Online]. Available: https://cwe.mitre.org/data/definitions/89.html [36] “CWE-94: Improper Control of Generation of Code (’Code Injection’).” [Online]. Available: https://cwe.mitre.org/data/definitio ns/94.html [37] “CWE-22: Improper Limitation of a Pathname to a Restricted Directory (’Path Traversal’).” [Online]. Available: https://cwe.mitre. org/data/definitions/22.html [38] “CWE-502: Deserialization of Untrusted Data.” [Online]. Available: https://cwe.mitre.org/data/definitions/502.html

12

[39] “CWE-352: Cross-Site Request Forgery (CSRF).” Available: https://cwe.mitre.org/data/definitions/352.html

[Online].

[56] Y. Li, S. Wang, and T. N. Nguyen, “Dlfix: context-based code transformation learning for automated program repair,” in Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering, ser. ICSE ’20. New York, NY, USA: Association for Computing Machinery, 2020, p. 602–614. [Online]. Available: https://doi.org/10.1145/3377811.3380345

[40] “CWE-863: Incorrect Authorization.” [Online]. Available: https: //cwe.mitre.org/data/definitions/863.html [41] Q.-C. Bui, R. Scandariato, and N. E. D. Ferreyra, “Vul4j: A dataset of reproducible java vulnerabilities geared towards the study of program repair techniques,” in 2022 IEEE/ACM 19th International Conference on Mining Software Repositories (MSR), 2022, pp. 464–468.

[57] F. Huq, M. Hasan, M. M. A. Haque, S. Mahbub, A. Iqbal, and T. Ahmed, “Review4repair: Code review aided automatic program repairing,” Inf. Softw. Technol., vol. 143, no. C, Mar. 2022. [Online]. Available: https://doi.org/10.1016/j.infsof.2021.106765

[42] “CWE-835: Loop with Unreachable Exit Condition (’Infinite Loop’).” [Online]. Available: https://cwe.mitre.org/data/definitions/835.html

[58] 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, ser. ISSTA 2023. New York, NY, USA: Association for Computing Machinery, 2023, p. 1282–1294. [Online]. Available: https://doi.org/10.1145/3597926.3598135

[43] “ CWE-828: Signal Handler with Functionality that is not Asynchronous-Safe.” [Online]. Available: https://cwe.mitre.org/data /definitions/828.html [44] “ CWE-770: Allocation of Resources Without Limits or Throttling.” [Online]. Available: https://cwe.mitre.org/data/definitions/770.html [45] “CWE-476: NULL Pointer Dereference.” [Online]. Available: https://cwe.mitre.org/data/definitions/476.html

[59] P. Lewis, E. Perez, A. Piktus, F. Petroni, V. Karpukhin, N. Goyal, H. Kuttler, M. Lewis, W.-t. Yih, T. Rocktaschel, S. Riedel, and D. Kiela, “Retrieval-augmented generation for knowledgeintensive nlp tasks,” in Advances in Neural Information Processing Systems, vol. 33, 2020, pp. 9459–9474. [Online]. Available: https://proceedings.neurips.cc/paper/2020/hash/6b493230205f780e1 bc26945df7481e5-Abstract.html

[46] “CWE-416: Use After Free.” [Online]. Available: https://cwe.mitre. org/data/definitions/416.html [47] “CWE-281: Improper Preservation of Permissions.” [Online]. Available: https://cwe.mitre.org/data/definitions/281.html [48] “CWE-96: Improper Neutralization of Directives in Statically Saved Code (’Static Code Injection’).” [Online]. Available: https: //cwe.mitre.org/data/definitions/96.html

[60] Y. Gao, Y. Xiong, X. Gao, K. Jia, J. Pan, Y. Bi, Y. Dai, J. Sun, M. Wang, and H. Wang, “Retrieval-augmented generation for large language models: A survey,” arXiv preprint arXiv:2312.10997, 2023. [Online]. Available: https://arxiv.org/abs/2312.10997

[49] 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, ser. ISSTA 2022. New York, NY, USA: Association for Computing Machinery, 2022, p. 691–702. [Online]. Available: https://doi.org/10.1145/3533767.3534387

Appendix This appendix provides background on Retrieval Augmented Generation, prompt templates and reports the results of repair performance on C based CWEs.

[50] C.-P. Wong, P. Santiesteban, C. Kästner, and C. Le Goues, “Varfix: balancing edit expressiveness and search effectiveness in automated program repair,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ser. ESEC/FSE 2021. New York, NY, USA: Association for Computing Machinery, 2021, p. 354–366. [Online]. Available: https://doi.org/10.1145/3468264.3468600

1. Retrieval Augmented Generation Retrieval Augmented Generation (RAG) incorporates external knowledge at inference time by combining the internal knowledge of an LLM with external sources such as vector databases, knowledge bases, and code repositories [59], [60]. This is particularly beneficial for knowledgeintensive tasks where information changes dynamically or where expert knowledge is difficult to acquire reliably during pre-training. Compared with fine-tuning, RAG offers greater flexibility and scalability, as external knowledge can be updated independently of the model parameters, reducing the need for costly retraining. It also improves factual grounding and transparency by enabling the model to generate responses based on retrieved, context-specific evidence, thereby mitigating hallucinations and enhancing trustworthiness in downstream applications. A typical RAG workflow begins by constructing an external knowledge base, where raw data are collected, processed into retrievable documents, and enriched with relevant metadata. At inference time, the most relevant documents are selected based on the query using lexical or semantic retrieval. During response generation, the query and retrieved context are incorporated into a prompt template, guiding the LLM and substantially improving output quality.

[51] F. Long and M. Rinard, “An analysis of the search spaces for generate and validate patch generation systems,” in Proceedings of the 38th International Conference on Software Engineering, ser. ICSE ’16. New York, NY, USA: Association for Computing Machinery, 2016, p. 702–713. [Online]. Available: https://doi.org/10 .1145/2884781.2884872 [52] R. Baldoni, E. Coppa, D. C. D’elia, C. Demetrescu, and I. Finocchi, “A survey of symbolic execution techniques,” vol. 51, no. 3, May 2018. [Online]. Available: https://doi.org/10.1145/3182657 [53] S. H. Tan and A. Roychoudhury, “relifix: automated repair of software regressions,” in Proceedings of the 37th International Conference on Software Engineering - Volume 1, ser. ICSE ’15. IEEE Press, 2015, p. 471–482. [54] F. Long, P. Amidon, and M. Rinard, “Automatic inference of code transforms for patch generation,” in Proceedings of the 2017 11th Joint Meeting on Foundations of Software Engineering, ser. ESEC/FSE 2017. New York, NY, USA: Association for Computing Machinery, 2017, p. 727–739. [Online]. Available: https://doi.org/10.1145/3106237.3106253 [55] K. Liu, A. Koyuncu, D. Kim, and T. F. Bissyandé, “Tbar: revisiting template-based automated program repair,” in Proceedings of the 28th ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2019. New York, NY, USA: Association for Computing Machinery, 2019, p. 31–42. [Online]. Available: https://doi.org/10.1145/3293882.3330577

13

TABLE 7: Repair performance for C CWEs. Green denotes correct, olive denotes partial, and red denotes failed fix CWE

Files Correct Partial Failed

Repair CodeBLEU CVEs Success Rate Score

CWE-125

20

15

2

3

85.00%

0.894

CVE-2015-2697, CVE-2016-6214, CVE-2016-6911 (F), CVE-2017-6309, CVE-2017-12897, CVE-2017-12985, CVE-2017-13007, CVE-2017-13014, CVE-2017-13045 (F), CVE-201717081, CVE-2018-20174, CVE-2018-20854, CVE-2019-19274, CVE-2020-4033, CVE-202011089 (P), CVE-2020-15888, CVE-2021-3881 (P), CVE-2022-23467 (F)

CWE-863

9

3

5

1

88.89%

0.754

CVE-2018-18397, CVE-2018-18955 (P), CVE-2018-20685, CVE-2019-15900, CVE-202024716 (P), CVE-2023-5521 (P), CVE-2023-5521 (F), CVE-2023-46139 (P)

2 CWEs

29

18

7

4

86.94%

0.824

–

However, irrelevant or conflicting retrieved documents can mislead the model, making retrieval quality and prompt design critical for generating reliable, high-quality outputs. An emerging extension of a RAG paradigm is Agentic RAG, which augments standard retrieval-generation pipelines with autonomous reasoning and decision-making capabilities. Instead of performing retrieval only once, an agentic system can iteratively plan retrieval steps, reformulate queries, evaluate intermediate results, and selectively invoke external tools or additional knowledge sources as needed. This enables dynamic adaptation to complex, multistep tasks where relevant information may not be accessible through a single retrieval pass. By integrating retrieval with iterative reasoning and tool use, Agentic RAG can improve robustness, contextual understanding, and task completion accuracy, particularly in domains that require structured problem solving or continuous interaction with evolving external information.

2. Performance of RAVEN on C based CWEs The results in table 7 further demonstrate the effectiveness of RAVEN on C-based vulnerabilities across memorysafety and access-control categories. For memory-based vulnerabilities (CWE-125), RAVEN successfully repairs 17 out of 20 instances, achieving a repair success rate of 85.00%, which shows its ability to mitigate out-of-bounds read vulnerabilities that often require precise boundary and inputsize reasoning. For access-control vulnerabilities (CWE863), RAVEN achieves an even higher success rate of 88.89%, successfully repairing 8 out of 9 instances, indicating that the framework can also handle security flaws requiring authorization-aware reasoning beyond local code patterns. Overall, across 29 C vulnerabilities, RAVEN repairs 25 instances including correct and partial fixes, achieving an overall repair success rate of 86.94%, while the average CodeBLEU score of 0.824 highlights that the generated patches remain closely aligned with the ground-truth repairs.

3. Prompt Templates

14

Selector Agent Prompt Template: You are a < language > code vulnerability patch selection agent . Select the single candidate patch whose fix strategy is the best semantic reference for repairing the vulnerable code . You are given : - a vulnerable code snippet - a CWE description - several candidate patches Your task is to choose the candidate whose remediation approach is most similar to the fix that should be applied to the vulnerable code . Evaluation rules : 1. Prioritize the underlying vulnerability cause over file names , function names , or CVE IDs . 2. Prefer the candidate with the most similar mitigation strategy and security checks . 3. Focus on the security logic introduced by the patch ( for example : bounds validation , length checks , null checks , state validation , safe iteration limits ). 4. Do not rely on superficial textual overlap alone . 5. If the CWE description and vulnerable code appear inconsistent , prioritize the actual vulnerable code pattern and the implied root cause in the code . 6. If a candidate appears to already match logic present in the vulnerable code , treat it cautiously ; it may indicate dataset noise or a pre - patched snippet . 7. Assume candidate patches may come from related or unrelated files ; file identity is not a deciding factor . Return exactly : Candidate x vulnerable_code : < vulnerable_code > cwe_description : < cwe_description > given_patches : Candidate 1 CVE : < candidate_1_cve_id > Filename : < candidate_1_filename > Patch diff : < candidate_1_patch_diff > --Candidate 2 CVE : < candidate_2_cve_id > Filename : < candidate_2_filename > Patch diff : < candidate_2_patch_diff > Return exactly : Candidate x

Figure 5: Prompt template for Selection Agent

15

Context Curator Agent Prompt Template: You are a repository context curator for < language > vulnerability repair . Your only job is to read the checked - out repository , identify the few most relevant files , and prepare compact evidence for a separate repair actor . Never produce code patches . Never use tools outside the allowed list . The target file ` code_before ` is already provided below . Use function tools to inspect other repository files , or to narrow supporting regions when needed . Case summary : - Case : < case_label > - CVE / CWE : < cve_id > / < cwe_id > - Target filename : < target_filename > - Target path : < target_relpath > - Current step : < step_index > / < max_steps > - Invalid JSON responses so far : < invalid_response_count > Reference patch commit message from the actual vulnerability - fixing commit : < commit_message_or_unavailable > Goal : - Find the smallest set of repository files that explain the vulnerable runtime path . - Prioritize the target file , direct callers / callees , and closely related validation helpers . - Finish once you can justify the most relevant file snippets for the downstream actor prompt . - If you use search alternation like ` foo | bar ` , set ` mode ` to ` regex ` , not ` literal ` . - If you do not set ` glob ` for ` search_repo ` , the tool will default to < default_source_glob > for this case . Confirmed facts : < confirmed_facts_or_none > Recent trace : < recent_tool_trace > Target file code_before : < vulnerable_code_with_line_numbers > Available function tools : - read_bundle () - read_file ( path , start_line , end_line ) - search_repo ( pattern , mode , glob , limit ) - find_symbol ( name , include_target ) - finish_curating ( root_cause , constraints , selected_files ) Tool rules : - Use OpenAI - style function calls via the provided tools . - Do not write raw JSON in assistant content to simulate a tool call . - Finish by calling ` finish_curating ` , not by answering in plain text . - ` selected_files ` must contain at most 5 items . - Include at least one snippet from the target file . - The target file ` code_before ` is already provided in the prompt ; use tools mainly to inspect other repository files or to narrow supporting evidence . - In curator mode , ` find_symbol ` defaults to ` include_target = true ` if you do not specify it . - Lower ` priority ` means more important .

Figure 6: Prompt template for context retrieval 16

Patch Generator Prompt Template: You are a software vulnerability repair tool . Generate the smallest correct { language } fix for the target file based on the vulnerable code below . Your goal is to repair the actual vulnerability in the target code , not to imitate the reference patch mechanically . Rules : 1. Prioritize the concrete root cause visible in the target code . { reference_guidance } 4. Apply the smallest targeted fix that prevents the unsafe behavior while preserving existing logic . 5. Do not refactor , rename symbols , change formatting unnecessarily , or modify unrelated behavior . 6. Do not introduce new helper functions , macros , types , or dependencies unless clearly implied by the provided code context . 7. Reuse existing validation style , control flow , and error handling patterns when possible . 8. Ensure the result is syntactically valid and consistent with the surrounding code . Output rules : - Return only one ``` { code_fence } ``` code block and no other text . - Inside the code block , provide only the minimal fixed code snippet (s) for the target file . - Do not output a unified diff unless explicitly requested . { reference_output_rule } Target { source_label }: { case . target_filename } vulnerable_code : { case . buggy_code } cwe_description : { case . cwe_description } { reference_section } C / C ++ requirements : - Return the smallest plausible C / C ++ code replacement snippet (s) for the target file . - Do not invent classes , wrappers , namespaces , packages , or non - existent project abstractions . - Use existing variables , macros , and error paths where possible . - Add checks immediately before the unsafe access or operation they protect . - Do not introduce undefined labels , variables , or return values inconsistent with the surrounding function . Optional repository context : repo_context_curated_from_repository : { repo_context_prompt } revision context : previous_fix : { previous_fix } critic_feedback : { critic_feedback } Revision requirements : - Improve the previous fix using the critic feedback . - Correct the specific mistakes identified by the critic . - Do not repeat flaws from the previous fix . - If the previous fix conflicts with the actual vulnerable pattern in the target code , prioritize the target code and the critic feedback .

17 Figure 7: Prompt template for Patch Generator