arXiv:2605.17444v1 [cs.SE] 17 May 2026
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair Simiao Liu
Li Zhang
Fang Liu∗
Beihang University Beijing, China [email protected]
Beihang University Beijing, China [email protected]
Beihang University Beijing, China [email protected]
Xiaoli Lian
Yang Liu
Yinghao Zhu
Beihang University Beijing, China [email protected]
Beihang University Beijing, China [email protected]
The University of Hong Kong Hong Kong, China [email protected]
Abstract
1
Modern software ecosystems face a rapidly growing number of disclosed vulnerabilities, increasing the need for automated repair techniques that can operate reliably at repository scale. Although Large Language Model (LLM)-based agents have recently shown promise for automated vulnerability repair (AVR), most existing systems still treat repair as a single generation step over the currently visible code context. As a result, they lack a persistent mechanism for reusing prior fixes or learning from failed validation attempts, which limits their effectiveness on complex, multi-file repair tasks. We present MemRepair, a memory-augmented agentic framework that formulates vulnerability repair as an iterative, experience-driven process. MemRepair combines three complementary memory layers, i.e., History-Fix, Security-Pattern, and Refinement-Trajectory memories, with a dynamic feedback-driven refinement loop. This design allows the agent to retrieve repositoryspecific repair conventions, apply reusable security defenses, and exploit prior “failure-to-success” trajectories to revise semantically invalid patches based on runtime evidence. We evaluate MemRepair on three representative repository-level vulnerability repair benchmarks: SEC-Bench, PatchEval (Python, Go, JavaScript), and the C++ subset of Multi-SWE-bench. MemRepair achieves stateof-the-art resolution rates of 58.0%, 58.2%, and 30.58%, respectively, outperforming strong general-purpose agents such as OpenHands and SWE-agent, as well as the specialized AVR tool InfCode-C++, while maintaining competitive repair cost. These results show that persistent, hierarchical repair memory can substantially improve the reliability of agentic vulnerability repair across diverse languages and repository settings. Our code and data are available at https://figshare.com/s/f2bbe7f7c8a759339368.
Nowadays, unprecedented levels of software vulnerabilities critically threaten the global software supply chain with severe risks [33]. Manual vulnerability repair is inefficient, high-cost, and thereby fundamentally unable to scale to the volume and velocity of modern vulnerability disclosures [9, 38]. As a result, the demand for scalable and reliable automated vulnerability repair (AVR) [16, 24] approaches is steadily increasing, emerging as a vital research frontier. To meet these demands, the paradigm of AVR has undergone substantial evolution. Early approaches relied on templates [26, 45] or simple translation models [11], and recently the field has progressed toward autonomous agents [6, 10, 15, 54] powered by Large Language Models (LLMs). These agents utilize external toolsets to augment reasoning, aiming to handle complex vulnerabilities, such as those requiring cross-file dependency understanding, in a stable and efficient manner. Despite these advancements, empirical evaluations [7, 40] indicate that existing approaches achieve only a relatively limited success rate in generating effective patches for real-world vulnerabilities. More critically, as noted in analyses of tools like jKali [32], many plausible patches introduce functional failures by simply deleting code or suppressing crashes without preserving semantics. To mitigate this, recent literature has explored augmenting agents with static knowledge [27, 56] or iterative feedback loops [43]. Yet, these methodologies fail to effectively synergize in repository-level environments. Specifically, naive retrieval strategies frequently overlook the intricate software context and interface specifications inherent in large repositories. As empirically demonstrated in recent studies on RAG integration [35, 55], this neglect causes retrieved generic patterns to clash with rigid project constraints, rendering the generated patches practically inapplicable. Furthermore, while feedback-driven frameworks [28, 43] can identify patch fails by test feedback, they lack the experiential memory to infer how to rectify it. Without the guidance of repair experiences, they treat feedback merely as rejection signals, leading to Cognitive Deficiency where agents oscillate between invalid solutions rather than generating a correct fix [39]. In contrast, security experts do not analyze code context in isolation when resolving vulnerabilities. Instead, they draw on multiple layers of accumulated experience: project-specific knowledge such as past fixes within the same repository, generalized security knowledge such as well-known defensive patterns like boundary checks,
CCS Concepts • Software and its engineering; • Computing methodologies → Artificial intelligence;
Keywords Automated Vulnerability Repair, Multi-Agent Frameworks, MemoryGuided Repair, Large Language Models
∗ Corresponding author.
Introduction
Liu et al.
and debugging experience from prior failed-then-successful repair attempts. By combining these complementary knowledge sources, experts can reliably diagnose root causes and produce robust fixes through experience-guided refinement. Motivated by the cognitive processes of security experts, we argue that, to achieve human-level reliability, autonomous agents require a memory-augmented architecture capable of explicit experience retrieval and continuous learning. Unlike current tools [3, 39, 46] that rely solely on the immediate context window, such an architecture maintains a knowledge base to store and recall verified solutions and debugging insights. Although prior work has begun to augment LLM-based repair with retrieval, these components are often loosely coupled, treating feedback as transient signals for the current attempt rather than consolidating it into persistently retained and reusable refinement experience. Consequently, these systems often repeat identical semantic errors across attempts or fail to generalize previously successful strategies to similar defects. To bridge this gap, we introduce MemRepair, a repository-level vulnerability repair framework designed to mimic the expert’s cognitive hierarchy. MemRepair employs a collaborative multi-agent system supported by a structured three-tier memory hierarchy, which is constructed to address the three corresponding cognitive barriers (i.e., lack of practical repair experience from humans, insufficient domain knowledge, and the absence of effective debugging insights.) • L1 History-Fix Memory retrieves similar historical fixes from the same project to ensure patches adhere to project-specific conventions. • L2 Security-Pattern Memory supplies generalized cross-project security knowledge (e.g., boundary checks) when local history is insufficient. • L3 Refinement-Trajectory Memory stores “failure-to-success” trajectories from prior repair sessions, guiding iterative patch refinement based on dynamic feedback. To evaluate the effectiveness of MemRepair, we conduct comprehensive experiments on three rigorous benchmarks: SEC-Bench [22] (C/C++ memory safety vulnerabilities), PatchEval [40] (multilanguage real-world vulnerabilities), and the C++ subset of MultiSWE-bench [49] (large-scale repository issues). Experimental results demonstrate that MemRepair achieves resolution rates of 58.0% on SEC-Bench and 58.2% on PatchEval, outperforming the previously best-performing agents by more than 20 percentage points. Furthermore, on the complex large-scale Multi-SWE-bench (C++), MemRepair achieves a resolution rate of 30.6%, exceeding the state-of-the-art specialize AVR tool InfCode-C++ (25.60%) [10] by 19%, validating its superior capability in navigating intricate codebases and resolving challenging bugs. In summary, this paper makes the following contributions: • Memory-Enhanced Framework: We propose MemRepair, the first repository-level AVR framework integrating a three-tier memory hierarchy (History-Fix, Security-Pattern, and RefinementTrajectory) that enables experience-grounded patch generation. • Feedback-Driven Refinement: We introduce a Locator-PatcherVerifier workflow with a closed feedback loop that converts runtime failure signals into corrective cues for iterative patch refinement.
• Extensive Evaluation: We evaluate on SEC-Bench [22], PatchEval [40], and Multi-SWE-bench [49], demonstrating state-of-the-art performance across four languages.
2
Motivation
We illustrate the core challenges of repository-level vulnerability repair with CVE-2023-0841, a critical integer overflow in the GPAC multimedia framework (a detailed walkthrough is available in our replication package). In reframe_mp3.c, the allocation size tag_size + 10 wraps around when tag_size approaches UINT_MAX, causing realloc to return a tiny buffer. A subsequent memcpy then writes the original large payload into this undersized buffer, triggering a heap buffer overflow. OpenHands (DeepSeek-v3.2) fixes the integer overflow at the allocation site but misses the dependency with the downstream memcpy, leaving the write path unguarded. This exemplifies a common failure mode: without cross-context reasoning, agents apply local syntax corrections that fail to propagate security constraints along data-flow dependencies. MemRepair bridges this gap through its multi-tier memory. It retrieves a generalized L2 insight that allocation-site validation alone is insufficient, together with an L3 “failure-to-success” trajectory showing that pointer updates require post-allocation verification. Guided by this experience, MemRepair injects a composite guard checking ctx->id3_buffer_size + bytes_to_drop before the write, preventing the unsafe path.
3 Proposed Framework 3.1 Problem Formulation Formally, let P denote the target repository and 𝐷𝑑𝑒𝑠𝑐 represent the vulnerability report. The system is also given a verification oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩, comprising a regression test suite T and a vulnerability Proof-of-Concept (PoC) 𝜏𝑣𝑢𝑙𝑛 . The goal is to synthesize a patch 𝛿 yielding a patched version P ′ = P ⊕ 𝛿 that satisfies two semantic constraints: (1) Functionality Preservation. The patch must maintain existing functionality, ensuring no regressions on passing tests: ∀𝑡 ∈ T : P (𝑡) = Pass =⇒ P ′ (𝑡) = Pass
(1)
(2) Vulnerability Mitigation. The patch must resolve the defect captured by the PoC 𝜏𝑣𝑢𝑙𝑛 (where P (𝜏𝑣𝑢𝑙𝑛 ) = Fail): P ′ (𝜏𝑣𝑢𝑙𝑛 ) = Pass
(2)
The vulnerability repair task is to find a 𝛿 satisfying Eq. (1) and Eq. (2), treating 𝜏𝑣𝑢𝑙𝑛 as the security target and T as the semantic boundary.
3.2
Framework Overview
Figure 1 presents an overview of our proposed MemRepair. Our framework mimics the iterative cognitive process of human experts, aiming to deliver robust and reliable vulnerability fixes. Rather than relying on a isolated generation pass, MemRepair orchestrates a dynamic repair lifecycle driven by a Hierarchical Memory System and a Feedback-Driven Refinement Loop to solve the task defined in Section 3.1.
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair
History-Fix Memory (L1)
Security-Pattern Memory (L2)
Refinement-Trajectory Memory (L3)
Hierarchical Memory System
experiences
failed (relocate)
Iter Grep
Code Edit
File Generation
Analyze Exception Report
failed (regenerte)
Code-Memory Integration
PoC Execution
experiences
Tools Log Parse
Vulnerability Description
Symbol Extraction
Root Analyse
Query Fixes
Repository Exploration
Extract values
Context Analysis
Rank Candidate
Apply Patch Build Project
Strategy Alignment
Confirm Root
Evaluate Strategy
Determine Strategy
Run Tests
Feedback Analysis
Collect Logs LLM-driven Verification
Patch Generation
Fault Localization
Experiences Distillation Final Patch
Buggy Program POC
Fuse Context
succeeded
aiohttp is an asynchronous HTTP client framework for asyncio and Python. In aiohttp before version 3.7.4, there is an open redirect vulnerability ...
Expolre Context
Analyse Chain
Runtime output
Target Object
Location and Logs
Error-Driven Structure-Aware Localization
Inputs
Code Synthesis Patch and Logs
L2 Memory
Experience-Augmented Patch Synthesis
Verification Iterative Control
L3 Memory
Feedback-Driven Refinement Loop
Figure 1: Overall architecture of MemRepair. MemRepair first runs vulnerability PoC 𝜏𝑣𝑢𝑙𝑛 to obtain runtime failure evidence (e.g., stack traces/sanitizer reports) and uses a structure-aware localizer tool (Iter_grep) to produce a localization object L𝑙𝑜𝑐 (target file, suspicious line range, and a concise trace). Conditioned on L𝑙𝑜𝑐 , the Patcher generates a candidate patch 𝛿 guided by hierarchical memory retrieval. Finally, the Verifier accepts 𝛿 only if it passes the oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩, otherwise it triggers Regenerate (revise 𝛿 at the same L𝑙𝑜𝑐 ) or Relocate (update L𝑙𝑜𝑐 with new runtime evidence), forming a closed feedback loop. Details of memory construction/retrieval and the refinement loop (including the algorithmic design and I/O interface of Iter_grep) are presented below. Table 1 summarizes the tool interface provided to the agent for interacting with the repository P, constructing L𝑙𝑜𝑐 , and validating candidate patches 𝛿 against the oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩.
3.3
Hierarchical Memory Construction
To support the cognitive processes described in Section 3.2, we formally define the data structures for the three-tier memory hierarchy. 3.3.1 Level 1: History-Fix Memory (𝑀𝐿1 ). The L1 memory is derived from CVEFixes [5], comprising 14,063 verified vulnerability-fixing entries collected up to 2024. These historical vulnerabilities are mined from the National Vulnerability Database (NVD) [2], a public U.S. vulnerability repository maintained by NIST that aggregates CVE records and detailed metadata on known software vulnerabilities, many of which also appear in widely used vulnerability repair benchmarks (including our evaluation benchmarks). As a result, this corpus can effectively serve as a source of repository-relevant historical fix experience. Formally, an L1 entry 𝑒𝐿1 is defined as a tuple: 𝑒𝐿1 = ⟨𝑃𝑝𝑟𝑜 𝑗 , 𝐾𝑐𝑤𝑒 , 𝐿𝑙𝑎𝑛𝑔 , 𝐼𝑖𝑑 , 𝐷𝑑𝑒𝑠𝑐 , 𝑃 𝑓 𝑖𝑥 ⟩
(3)
Table 1: Tool interface of MemRepair. Category
Command
Documentation
Localization
Iter_grep <symbol>
Returns top-k (default k=5) ranked locations to form L𝑙𝑜𝑐 : {file, line_range}.
File viewer
view <path>
Shows file content with line numbers; lists directory items (depth ≤2).
Search tools
search <pattern> <search_path>
Regex search via ripgrep; returns matches with context (default matches number=5).
File editing
create <path> <text>
Creates a new file (fails if path already exists).
str_replace <path> <old> <new>
Replaces an exact, unique match of old with new.
Command execution
bash <command> [restart]
Runs a command in a persistent shell session (restart=true resets).
Verification
check_vul
Runs ⟨ T, 𝜏𝑣𝑢𝑙𝑛 ⟩ on P ⊕𝛿; returns verdict + error logs.
Log compression
log_compress
Summarizes logs into a compact template for the next iteration.
Task sion
submit
Submits final result and extracted git diff.
submis-
• 𝑃𝑟𝑜 𝑗 , 𝐾𝑐𝑤𝑒 , 𝐿𝑎𝑛𝑔 (Retrieval Keys): The project identifier, vulnerability type, and target programming language, which collectively serve as the primary keys for precise experience retrieval. • 𝐼𝑖𝑑 (Instance ID): A unique vulnerability identifier (such as njs.cve-2022-32414), used to deduplicate entries and to filter out the target instance during retrieval (i.e., exclude 𝐼𝑖𝑑 (𝑒) = 𝐼𝑖𝑑 (𝑞)). We also use the CVE year and sequence (e.g., 2022-32414) as a time key for temporal constraints. • 𝐷𝑑𝑒𝑠𝑐 (Description): The detailed description of the vulnerability scenario.
Liu et al.
aiohttp is an asynchronous HTTP client framework for asyncio and Python. In aiohttp before version 3.7.4, there is an open redirect vulnerability ...
Priority 1 (P1): Intra-Project Experience Retrieval
History-Fix Memory (L1) SecurityPattern Memory (L2)
Same Project +
Vulnerability Description
Same CWE + Same Embedding model
Language
Inputs
Failed Patch
Project language CWE type
# candidates >= target
YES
Filter
RefinementRajectory Memory (L3)
NO
Priority 2 (P2): Cross-Project Generalization
Timestamp
Different Project
Project name
Timestamp
+ Same CWE + Same Language
Final Retrieved Experience
MetaData
Figure 2: Workflow of our experience retrieval mechanism. • 𝑃 𝑓 𝑖𝑥 (Solution): The concrete repair patch containing the exact code modifications that resolved the vulnerability. L2 and L3 memories share the same keys (𝑃𝑝𝑟𝑜 𝑗 , 𝐾𝑐𝑤𝑒 , 𝐿𝑙𝑎𝑛𝑔 , 𝐼𝑖𝑑 , 𝐷𝑑𝑒𝑠𝑐 ) as L1. Both are collected in real-time during the repair process. Below we describe only their unique fields. 3.3.2 Level 2: Security-Pattern Memory (𝑀𝐿2 ). Each L2 entry 𝑒𝐿2 represents a successful repair instance, extending the shared keys with: 𝑒𝐿2 = ⟨. . . , 𝑅𝑟𝑎𝑡𝑖𝑜𝑛𝑎𝑙𝑒 ⟩ (4)
This ensures that retrieved patches adhere to the project’s established naming conventions, error-handling idioms, and architectural constraints, while strictly targeting the specific vulnerability category. Priority 2 (P2): Cross-Project Generalization. Criteria: Different Project + Same CWE + Same Language. When P1 yields fewer than 𝑘 candidates (𝑘=2 in our setup), we extend retrieval to P2, which is particularly important for vulnerability categories whose fixes often rely on external defensive patterns absent in a local codebase [4, 57]. By incorporating cross-project repair knowledge, P2 guarantees non-empty and semantically meaningful retrieval even when samerepository history is limited. We quantify the semantic proximity between 𝐷𝑑𝑒𝑠𝑐 and candidate descriptions. We utilize the text-embedding-3-small model [30] to encode descriptions into dense vectors and rank candidates by their cosine similarity. To prevent data leakage, we exclude candidates with the same instance ID as the query (i.e., 𝐼𝑖𝑑 (𝑒) = 𝐼𝑖𝑑 (𝑞)). We further enforce a temporal constraint on intra-project retrieval by requiring𝑇𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 (𝑒) < 𝑇𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 (𝑞), where𝑇 𝑖𝑚𝑒𝑠𝑡𝑎𝑚𝑝 (·) is derived from 𝐼𝑖𝑑 (year and sequence number).
3.4 where 𝑅𝑟𝑎𝑡𝑖𝑜𝑛𝑎𝑙𝑒 (Insight) is a concise natural language description of why the patch worked. 3.3.3 Level 3: Refinement-Trajectory Memory (𝑀𝐿3 ). The L3 memory captures “failure-to-success” trajectories within a single repair session. Each entry extends the shared keys with: 𝑒𝐿3 = ⟨. . . , 𝑃 𝑓 𝑎𝑖𝑙 , Δ𝑑𝑖 𝑓 𝑓 , 𝐼𝑖𝑛𝑠𝑖𝑔ℎ𝑡 ⟩
(5)
• 𝑃 𝑓 𝑎𝑖𝑙 (Failure State): The patch that failed validation. • Δ𝑑𝑖 𝑓 𝑓 (Correction Delta): The modification that transformed the failed state into a successful one. • 𝐼𝑖𝑛𝑠𝑖𝑔ℎ𝑡 (Transition Rule): The learned rule for this transition. The size of the evaluation benchmarks naturally limits the scale of the stored experiences (e.g., 116 for L2 and 86 for L3 on SECBench). Since only successful fixes are accumulated, memory growth remains controlled in our current setting. To ensure scalability in long-running deployments across large-scale repositories, we adopt two lightweight management strategies: (1) deduplication, where entries whose descriptions and patches have a cosine similarity above 0.95 are merged to eliminate redundancy; and (2) recencyweighted pruning, where entries that have not been retrieved over a configurable window of recent tasks are periodically removed to keep the memory focused on actively useful knowledge. 3.3.4 Experience Retrieval Mechanism. MemRepair employs an experience retrieval mechanism to effectively leverage historical knowledge. The classic “plastic surgery hypothesis” [57] posits that repair ingredients are predominantly found within the same project, ensuring stylistic consistency. At the same time, to balance locality with generalization and to ensure robust retrieval under sparse project history, we propose a dynamic two-tier priority strategy (P1 and P2), as illustrated in Figure 2. Priority 1 (P1): Intra-Project Experience Retrieval. Criteria: Same Project + Same CWE + Same Language. We prioritize intraproject experiences to maximize stylistic and semantic consistency.
Feedback-Driven Refinement Loop
MemRepair operates through an iterative agentic loop anchored by tool-driven execution and feedback (Table 1), augmented by a multi-tier memory system (§3.3). Concretely, we first obtain dynamic failure evidence by invoking check_vul, which executes the oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩ on the current repository state and returns structured runtime evidence 𝑅𝑑 𝑦𝑛 such as stack traces/sanitizer reports and failing tests. For each failed attempt, we additionally invoke log_compress to summarize raw logs into a compact template, which is fed back to the next iteration to reduce context noise. Phase 1: Error-Driven Structure-Aware Localization. The Locator agent ingests 𝐷𝑑𝑒𝑠𝑐 and 𝑅𝑑 𝑦𝑛 , supplemented by project-specific priors from L1/L2 memories. To overcome the limitations of keywordbased search (existing agents rely on grep and return many unranked matches including comments and unused code), we implement Iter_grep, a structure-aware tool that returns the top-5 code locations most relevant to the error stack trace in 𝑅𝑑𝑦𝑛 . Given a symbol name (e.g., variable names from 𝐷𝑑𝑒𝑠𝑐 or function names from 𝑅𝑑 𝑦𝑛 ), Iter_grep parses the repository AST to locate all definitions and use sites, then ranks them by proximity to the error location in 𝑅𝑑 𝑦𝑛 . It prioritizes matches within the files present in the 𝑅𝑑 𝑦𝑛 call stack, ranking frames closer to the crash site higher by their logical distance to the crash point. The Iter_grep output is a structured localization object ⟨𝑓 , ℓ⟩, where 𝑓 is the ranked file path, ℓ is the critical line. This object serves as the deterministic target for subsequent patch synthesis. For example, given a heap-bufferoverflow in utils.c:45 inside function safe_copy(src, len), querying Iter_grep(len) returns: • Rank 1: utils.c:45 (Crash site: memcpy(dst, src, len)). • Rank 2: utils.c:40 (Function signature definition). • Rank 3: main.c:102 (Caller site: safe_copy(buf, user_input_size)). Finally, this phase produces a structured localization object L𝑙𝑜𝑐 , encapsulating the file path, critical line number, and localization reasons.
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair
Phase 2: Experience-Augmented Patch Synthesis. Conditioned on L𝑙𝑜𝑐 from Phase 1, MemRepair proceeds to the Patcher Agent. Similar to the Locator, this agent is initialized with project-specific patterns from L1 and L2 memories to ensure the generated code adheres to existing stylistic and security conventions. It is worth noting that the L3 refinement-trajectory memory is activated only after a failed verification cycle. Given a failed candidate 𝛿, we embed the failed patch and retrieve the most similar 𝑃 𝑓 𝑎𝑖𝑙 entries from L3 under the same priority strategy. The retrieved “failure→success” deltas provide explicit corrective guidance, which the Patcher uses to revise 𝛿 in the subsequent iteration. Phase 3: Verification Iterative Control. The Verifier applies the candidate patch 𝛿 produced in Phase 2 to the repository and executes the verification oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩ (via check_vul) to validate both functionality preservation and vulnerability mitigation. Based on the execution feedback, it triggers a tri-state transition: • Success: Terminates the lifecycle. The Verifier extracts the successful repair session to update L2, and if applicable, captures the “failed → success” transition to update L3. • Relocate: Backtracks to Phase 1 if the vulnerability persists, indicating an incorrect root cause diagnosis. • Regenerate: Loops back to Phase 2 if the patch fixes the vulnerability but introduces functional regressions. To keep the next iteration focused and reduce token consumption, we perform context compression: the Verifier summarizes the failed trajectory from raw tool logs using log_compress into a fixed template containing only (i) visited files/line ranges, (ii) applied diff hunks, and (iii) verification failure log (including sanitizer traces, or compilation errors). We then roll back the environment for the subsequent refinement cycle.
4 Experimental Setup 4.1 Research Questions We evaluate the effectiveness of MemRepair by comparing it with the state-of-the-art baselines and focus on the following research questions: • RQ1: Overall Performance - How does MemRepair compare to state-of-the-art automated vulnerability repair techniques and general-purpose LLM agents in fixing real-world vulnerabilities? • RQ2: Ablation Study - What is the contribution of each memory component and the feedback-driven refinement loop to the overall repair performance? • RQ3: Generalizability Analysis - Can MemRepair generalize effectively across different programming languages (Python, Go and JavaScript) and varying levels of repository complexity?
4.2
Baselines
To validate the performance of MemRepair, we compare it against two categories of state-of-the-art approaches. First, for generalpurpose autonomous software engineering, we select representative agents including OpenHands [39], SWE-agent [46], Aider [3], and Agentless. Specifically, OpenHands is evaluated using both DeepSeek-v3.2 and Claude-3.7-Sonnet backbones, while SWE-agent utilizes Claude-3.7-Sonnet and Gemini-2.5. These
frameworks represent the current state-of-the-art in agentic planning and code editing strategies, operating without domain-specific customization. we exclude prior learning-based AVR approaches (including both DL models [11, 18] and non-agentic LLM applications [31, 42, 50]) as they are predominantly restricted to functionlevel synthesis with pre-isolated context and static evaluation such as CodeBLEU [34]. These are incompatible with our end-to-end repository-level setting, which demands autonomous localization and rigorous dynamic security verification. Furthermore, on the Multi-SWE-bench (C++ subset), we benchmark against InfCode-C++ [10]. We prioritize this comparison as InfCode-C++ epitomizes the structural-retrieval paradigm, employing intent-guided search and deterministic AST-based navigation to resolve C++ complexities and achieve state-of-the-art performance. This comparison directly evaluates whether MemRepair’s experience-driven memory hierarchy surpasses a system deeply engineered with language-specific static analysis. Additionally, while recent dynamic agents like VulDebugger [28] show promise, they are excluded due to reproducibility constraints regarding their closed-source datasets. Besides, to verify generalizability beyond C++, we additionally incorporate PatchEval for multi-language evaluation (Go, Python, JavaScript).
4.3
Benchmarks and Metrics
To comprehensively evaluate the effectiveness of MemRepair across different vulnerability types, programming languages, and repository scales, we employ three distinct benchmarks: (1) SEC-Bench [22], a rigorous framework designed to validate broad security capabilities, specifically targeting C/C++ memory safety tasks by utilizing sanitizer feedback to evaluate agents on vulnerability patching; (2) PatchEval [40], a specialized benchmark for real world vulnerabilities including Go, Python, and JavaScript, which employs rigorous security and regression tests to verify that fixes effectively mitigate vulnerabilities without breaking functionality; and (3) the C++ subset of Multi-SWE-bench [49], representing the complex large-scale repository-level issue resolution, where we benchmark against InfCode-C++ [10]. We restrict this comparison to Multi-SWE-bench (C++) because InfCode-C++ is C++-specific and its runnable implementation is not publicly available, making it infeasible to reproduce it under the SEC-Bench. We employ the following metrics to evaluate both the vulnerability repair performance as well as the cost: • Success Rate (% Resolved): The percentage of tasks where the generated patch successfully passes both the vulnerability reproduction test (𝜏𝑣𝑢𝑙𝑛 ) and the existing regression test suite (T ). • Location Accuracy: We evaluate localization at file levels. Following Yang et al. [46], we consider the location correct if the locations modified by the generated patch include all locations in the ground truth patch. • Cost: The average monetary cost per task (in USD), calculated based on the token usage.
4.4
Implementation Details
We primarily utilize DeepSeek-v3.2 and DeepSeek-v3 as the foundational reasoning backbones for MemRepair. These models were
Liu et al.
Table 2: Performance comparison on SEC-Bench and MultiSWE-bench (C++). Tool
LLM
% Res.
Cost ($/Task)
% Cor. Loc.
DeepSeek-v3.2 DeepSeek-v3.2 Claude-3.7 Claude-3.7 Claude-3.7
58.00% 38.50% 34.00% 31.50% 23.50%
0.26 0.18 0.61 1.29 0.44
60.00% 63.00% 65.00% 67.50% 46.00%
30.58% 15.08% 25.60% 13.20% 14.70% 11.60% 3.90%
0.32 0.22 0.18 0.43
53.72% 38.89% 55.10% 39.53% 23.26% 17.05%
SEC-Bench MemRepair OpenHands* OpenHands SWE-agent Aider
Multi-SWE-bench (C++) MemRepair MemRepair InfCode-C++ [10] InfCode-C++ [10] MOpenHands MSWE-agent MAgentless
DeepSeek-v3.2 DeepSeek-v3 GPT-5 DeepSeek-v3 Claude-3.7 Claude-3.7 Claude-3.7
selected for their balance between performance and computational cost. For hyperparameter configuration, we follow DeepSeek’s official recommendation for coding/math tasks and set the temperature to 0.0 to encourage deterministic patch generation [14]. We cap the refinement loop at 3 failed patch attempts based on a small-scale pilot study, as most successful cases converge within the first few iterations while additional retries mainly increase cost. Regarding the baselines, we also reproduce OpenHands (denoted as OpenHands*). Specifically, to ensure a rigorous and fair comparison with our framework, we augment the standard OpenHands agent with a specialized validation tool function named check_vul and modify the system prompt to explicitly instruct the agent to invoke this tool whenever it is confident that a fix has been achieved. Upon invocation, check_vul executes the evaluation script on the current state of the repository and returns the execution results to the agent, thereby enabling a validation feedback loop.
5 Results and Analysis 5.1 RQ1: Overall Performance To answer this RQ, we evaluate MemRepair against state-of-the-art baselines on SEC-Bench and Multi-SWE-bench (C++ subset), both of which focus on C++ repositories. 5.1.1 Overall Performance Comparison (RQ1.1). As shown in Table 2, MemRepair achieves state-of-the-art performance, substantially outperforming both general-purpose agents and specialized tools. Specifically, on SEC-Bench, MemRepair resolves 58% of issues, surpassing OpenHands* by nearly 20 percentage points (58.0% vs. 38.5%). Crucially, both systems use the identical DeepSeek-v3.2 backbone and share the same check_vul verification tool, confirming that the performance improvement is attributable to our memory-guided architecture rather than differences in LLM capability or tool access. In terms of localization, MemRepair achieves slightly lower localization accuracy than several baselines, this difference largely reflects a limitation of the localization metric rather than the system’s true effectiveness. Specifically, MemRepair exhibits a substantially higher conversion rate from localization to successful repair. In contrast, baseline methods frequently fail to produce valid repairs even when the bug location is correctly
identified (see §5.1.2 for a detailed analysis). Regarding cost efficiency, MemRepair maintains a highly competitive average cost of $0.26/task, comparable to OpenHands* ($0.18) and significantly lower than SWE-agent ($1.29). On the more challenging Multi-SWE-Bench (C++), MemRepair achieves 30.58%, outperforming InfCode-C++ (25.6% with GPT-5) despite using a weaker backbone. When controlling for the same DeepSeek-V3 backend, MemRepair (15.08%) also exceeds InfCodeC++ (13.20%) and general agents such as MOpenHands (14.70%) and MSWE-agent (11.60%). Answer to RQ1.1: MemRepair establishes a new state-of-the-art in vulnerability repair, substantially outperforming both generalpurpose agents and specialized tools on SEC-Bench and MultiSWE-bench. Notably, MemRepair surpasses these specialized baselines while maintaining superior cost-efficiency, demonstrating that a memory-augmented architecture is critical for resolving complex repository-level vulnerabilities. 5.1.2 Localization-to-Repair Gap (RQ1.2). To further analyze the gap between vulnerability localization and successful repair, we visualize the localization-to-repair flow using the Sankey diagram in Figure 3. On SEC-Bench, baselines such as SWE-agent exhibit a seemingly superior localization rate of 67.5% (135/200) compared to MemRepair (60.0%). However, high localization accuracy does not necessarily translate into more effective repair. Since the localization metric considers a prediction successful as long as the modified files include the ground-truth vulnerable locations, a high score can sometimes reflect an unfocused editing strategy where the agent applies extensive edits across multiple files. While such aggressive edits increase the statistical likelihood of covering the buggy lines, they substantially raise the risk of introducing functional regressions or inconsistent fixes. The Sankey flow corroborates this observation: among the vulnerabilities successfully localized by SWE-agent, 63% (85 out of 135) ultimately fail to be repaired. In contrast, MemRepair demonstrates a higher conversion rate from localization to resolution. Out of the 120 instances it successfully localizes, 86 are correctly repaired, yielding a conversion rate of 71.6%. By leveraging memory experiences, MemRepair is guided toward generate precise, surgical fixes rather than broad and unfocused modifications. This advantage becomes even more pronounced on the large-scale Multi-SWE-Bench (C++) benchmark. As illustrated in Figure 3b, OpenHands exhibits a low localizationto-repair conversion rate: it resolves only 27.5% of the localized issues, leaving 72.5% unresolved. MemRepair maintains a robust conversion rate (45.5%), demonstrating its capability to handle the noise and dependency complexity of large-scale software. Answer to RQ1.2: High localization accuracy does not guarantee repair success. Baselines exhibit a significant “Localization-toRepair” gap, failing to resolve over 60% of the bugs they successfully localize. In contrast, MemRepair demonstrates a superior conversion rate from localization to valid repair, validating the effectiveness of memory-guided surgical repair. 5.1.3 Solution Uniqueness and Overlap (RQ1.3). Finally, we analyze whether MemRepair simply replicates existing capabilities
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair Tool Performance Analysis
Tool Performance Analysis
MemRepair + DeepSeek V3.2
MemRepair + DeepSeek V3.2
(Loc:60% (Loc:60% Fix:62%) Fix:62%)
OpenHands + Claude 3.7
(Loc:53.7% (Loc:53.7% Fix:30.1%) Fix:30.1%)
Successfully Located
Successfully Resolved
InfCode-C++ + GPT-5
(Loc:65% (Loc:65% Fix:34%) Fix:34%)
(Loc:55.0% (Loc:55.0% Fix:25.6%) Fix:25.6%)
OpenHands + DeepSeek V3.2
OpenHands + Claude 3.7
(Loc:60% (Loc:60% Fix:38%) Fix:38%)
(Loc:39.5% (Loc:39.5% Fix:14.7%) Fix:14.7%)
SWE-agent + Claude 3.7 (Loc:68% (Loc:68% Fix:32%) Fix:32%)
Not Located
SWE-agent + Claude 3.7
Unresolved
(Loc:23.3% (Loc:23.3% Fix:11.6%) Fix:11.6%)
Aider + Claude 3.7
AgentLess + Claude 3.7
(Loc:46% (Loc:46% Fix:24%) Fix:24%)
(Loc:17.1% (Loc:17.1% Fix:3.1%) Fix:3.1%)
(a) Results on SecBench.
Successfully Located
Successfully Resolved
Not Located
Unresolved
(b) Results on Multi-SWE-Bench (C++).
Figure 3: Issue localization-to-repair flow on SecBench and Multi-SWE-Bench (C++). contribution of the next best baseline (SWE-agent: 8). This confirms that MemRepair offers distinct capabilities, effectively resolving intractable vulnerabilities that remain out of reach for general-purpose baselines.
5.2
Figure 4: Venn diagram of the number pf resolved issues on SEC-Bench. or addresses previously unsolvable problems. Figure 4 illustrates the intersection of resolved issues on SEC-Bench for MemRepair and leading baselines. Collectively, the union of all evaluated tools resolved 154 distinct vulnerabilities. MemRepair alone covers 116 of these (approx. 75.3%), demonstrating its role as the dominant contributor to the combined success pool. More importantly, as seen in the figure, MemRepair uniquely resolves 29 issues (25% of its total successes). In sharp contrast, the baselines exhibit much narrower unique capabilities, with SWE-agent and OpenHands uniquely resolving only 8 and 6 issues, respectively. This indicates that MemRepair does not merely improve upon general agents by a small margin but possesses a distinct capability profile capable of solving a class of problems that are currently out of reach for general-purpose LLMs. Answer to RQ1.3: MemRepair resolves 29 difficult vulnerabilities that no other agents could fix—more than 3× the unique
RQ2: Ablation Study
To investigate the individual contribution of each memory component, i.e., L1/L2/L3 memory, we conducted an ablation study on SEC-Bench. We compared the full MemRepair framework against configurations where only a single memory tier was activated. Table 3 details the success rates and the breakdown of localizationrepair outcomes. Impact of Refinement-Trajectory Memory (L3). The results highlight that L3 Refinement-Trajectory Memory is the most critical driver of repair success. When operating with L3 alone, the system achieves a success rate of 50.5%, significantly outperforming the OpenHands baseline (38.5%). More importantly, L3 drastically improves the quality of the generated patches. As shown in the 𝐿✓ 𝐹 × column (correct location, failed fixing), the baseline OpenHands fails to resolve 66 cases even after correctly locating them. In contrast, the L3-only configuration reduces this failure count to 30, and the full model further suppresses it to 26. This reduction demonstrates that the “failure-to-success” trajectories stored in L3 effectively guide the agent to rectify semantic errors that would otherwise lead to invalid patches, thereby bridging the localizationrepair gap. Impact of Security-Pattern (L2) and History-Fix (L1) Memories. Both L1 and L2 memories contribute to performance improvements over the baseline, but with varying degrees of impact. L2 Security-Pattern Memory alone achieves a 48% success rate, surpassing L1 History-Fix Memory (42.0%). This result highlights that treating historical fixes as reusable code snippets, rather than as sources of abstract security knowledge, offers limited benefits for vulnerability repair. For security vulnerabilities, generalized abstract patterns (e.g., “check bounds before write”) are more transferable and effective than raw, project-specific code snippets retrieved by L1. Impact of Feedback Loop (MemRepair Loop Only). The Loop Only variant disables all memory retrieval (L1–L3) and retains
Liu et al.
Table 3: Ablation study results on SecBench. 𝐿✓/× denotes successful/failed localization, while 𝐹 ✓/× denotes successful/failed fixing. Location Breakdown Configuration
Base Model
% Resolved
Cost ($/Task)
𝑳 ✓ 𝑭✓
𝑳✓ 𝑭 ×
𝑳 × 𝑭✓
𝑳 × 𝑭×
MemRepair (Full: L1+L2+L3)
DeepSeek-v3.2
58.0%
0.26
86
34
30
50
MemRepair (L3: Only) MemRepair (L2 Only) MemRepair (L1 Only) MemRepair (Loop Only)
DeepSeek-v3.2 DeepSeek-v3.2 DeepSeek-v3.2 DeepSeek-v3.2
50.5% 48.0% 42.0% 36.0%
0.19 0.20 0.20 0.21
66 77 63 57
30 38 41 43
35 19 21 15
69 66 75 85
OpenHands*
DeepSeek-v3.2
38.5%
0.18
65
61
12
62
only the feedback-driven control logic in the Verifier. Importantly, the Verifier in this setting provides only coarse-grained signals, i.e., Relocate or Regenerate, to indicate whether the next attempt should change the localization target or revise the patch at the same location, without supplying any additional experience cues or refinement strategies. As shown in Table 3, Loop Only variant achieves a success rate of 36.0%, which is lower than OpenHands* (38.5%) and substantially worse than any memory-enabled configuration (42.0%–50.5%). This result indicates that without memory-based guidance, the agent struggles to correct semantic mistakes, even after locating the correct region. This is reflected in the high 𝐿✓ 𝐹 × count (43), where the system fails to generate a valid fix despite identifying the correct location. Effect of Hierarchical Memory. The Full MemRepair configuration yields the highest success rate of 58.0%, which is superior to any single-component setup. This indicates a synergistic effect: L1 and L2 provide the necessary context and search space reduction during the initial generation, while L3 acts as a semantic filter and refinement engine during the feedback loop. Furthermore, the cost analysis reveals that this performance gain is achieved economically. The full model incurs only a marginal cost increase ($0.26/task) compared to the baseline ($0.18/task), proving that augmenting LLMs with a structured memory hierarchy is a cost-effective strategy for enhancing automated vulnerability repair. Answer to RQ2: The ablation study reveals that RefinementTrajectory Memory (L3) stands out as the most significant individual contributor to repair success. While generalized security patterns (L2) prove more effective than raw historical snippets (L1), the full hierarchical synergy yields the highest performance. Besides, the “Loop Only” variant underperforms the baseline, proving that coarse feedback signals are insufficient without memory context.
5.3
RQ3: Generalizability Analysis
In this RQ, we investigate whether MemRepair generalizes effectively across programming languages. We evaluate MemRepair on PatchEval [40], which contains real-world vulnerabilities spanning Python, JavaScript, and Go, and validates fixes using a strict oracle ⟨T , 𝜏𝑣𝑢𝑙𝑛 ⟩ (security reproduction + regression tests). To adapt to the benchmark, we only use generic text-based search utilities (standard grep or ripgrep), excluding the language-dependent AST
Table 4: Generalizability results on PatchEval (Python/JavaScript/Go). Setting
# Cases
% Located
% Resolved
Python JavaScript Go
65 75 85
70.8% 88.0% 72.9%
46.2% 74.7% 53.0%
Total
225
77.3%
58.2%
– –
37.80% 35.60%
MemRepair (DeepSeek-v3.2)
Baselines reported in PatchEval SWE-agent (Gemini-2.5 pro) OpenHands (Gemini-2.5 pro)
– –
analyzer (Iter_grep) used in the C++ experiments. As shown in Table 4, MemRepair achieves an overall repair success rate of 58.2% on PatchEval across three languages, comparable to its performance on SEC-Bench, indicating that the proposed memory-guided synthesis and feedback-driven refinement are not confined to C/C++ project scenarios but transfer to diverse languages (The total number of this benchmark is 230, but five docker images failed to build locally, so they were excluded.). Performance varies across languages: JavaScript achieves the highest repair rate (74.7%) with an 81.8% localization-to-repair conversion, while Python is the most challenging (46.2%, 60.9% conversion). A notable portion of tasks fall into the 𝐿 × 𝐹 ✓ category, indicating that MemRepair produces behaviorally equivalent fixes at alternative locations (e.g., upstream sanitization) rather than modifying the exact ground-truth lines. Besides, MemRepair substantially outperforms strong baselines reported by the benchmark: SWE-agent (Gemini-2.5 pro) at 37.80% and OpenHands (Gemini-2.5 pro) at 35.60% (Detailed location breakdown is omitted for these baselines as their specific generated patches were not open-sourced by PatchEval [40]). Moreover, MemRepair is notably more cost-efficient, achieving a lower average cost of 0.25 compared to 2.39 and 4.64 per task for SWE-agent and OpenHands, respectively. Answer to RQ3: MemRepair demonstrates robust generalizability across diverse programming languages, substantially outperforming strong baselines while reducing operational costs by over 3×. The consistent performance across Python, JavaScript,
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair
but crashes only after propagating to the bytecode interpreter (src/njs_vmcode.c). The human patch sanitizes at the source— the Promise handler—before the value enters the VM:
and Go confirms that the proposed memory-driven architecture is language-agnostic and effectively transfers to varying syntax and logic paradigms. 1
6 Discussion 6.1 Analysis of Repair Patterns In this section, we present a comprehensive analysis of the generated patches for successfully resolved issues, focusing on their complexity—measured by the average number of modified files and lines—relative to human-written patches. Table 5 compares the complexity of generated patches (Gen) by MemRepair against human-written ground truth (GT). We observe distinct behavioral patterns across different benchmarks: • Compact Fixes in Complex Repositories: On large-scale C++ repositories (Multi-SWE-bench), human patches are extensive (Avg. 70.16 lines changed across 2.24 files), often involving header restructuring or code cleanups. In contrast, MemRepair generates highly compact, “surgical” fixes (Avg. 24.24 lines across 1.16 files). This suggests that in emergency response scenarios, the agent prioritizes minimal modification to resolve the vulnerability, minimizing the risk of collateral regressions. • Verbose Fixes for Memory Safety Issues: Conversely, in the domain of memory safety (SEC-Bench), MemRepair tends to be more verbose than humans (NLA: 17.03 vs. 10.48). This stems from the MemRepair, which encourages the injection of explicit guard clauses (e.g., redundant null checks) to block exploit paths. While less elegant than human refactoring, this strategy effectively enforces security invariants.
6.2
Qualitative Analysis of Localization Mismatch
In the analysis presented in Section 5, we observed a phenomenon: a considerable prevalence of the 𝐿 × 𝐹 ✓ category, where MemRepair successfully repairs the vulnerability despite failing standard localization metrics (i.e., the modified files do not match the humanwritten ground truth). To further investigate this phenomenon, we conducted a manual analysis and identified two distinct repair patterns where the agent discovers behaviorally equivalent paths that differ spatially from the human-written ground truth: • Location Divergence: While human experts often modify a lowlevel utility function (callee) to handle edge cases generically, MemRepair tends to intercept the invalid input at the specific call site (caller) or within a higher-level handler. Structurally different, this effectively blocks the vulnerability trigger path for the tested scenario. • Scope Divergence: Human commits frequently encompass nonfunctional files such as header definitions. Since localization metrics require the predicted file set to be a superset of the ground truth, omitting these results in zero scores. MemRepair, driven by the verification oracle, acts as a surgical agent, modifying only the core implementation files required to mitigate the crash. We illustrate these two patterns through specific real-world case studies below. Case 1: Functional Equivalence (CVE-2022-32414). An invalid object originates in the Promise handler (src/njs_promise.c)
2 3 4 5 6 7
// [ Logic ] Check validity BEFORE passing data to the iterator + if (! njs_is_valid ( value ) ) { + // Sanitize invalid input to undefined + value = njs_value_arg (& njs_value_undefined ); + } // Pass the sanitized ' value ' to the function call ret = njs_function_call ( vm , pargs - > function , ... , value , ...) ;
Ground Truth: src/njs_promise.c MemRepair, guided by the runtime stack trace, instead guards at the destination—the VM interpreter—intercepting the corrupted state before dereference: 1 2 3 4 5 6 7 8
// [ Logic ] Switch source : Read from stable 'vm -> retval ' instead of unstable register - next = value2 - > data . u . next ; + next = vm - > retval . data . u . next ; // [ Logic ] Defensive Check : Abort if the iterator is corrupted + if ( njs_slow_path ( next == NULL next - > array == NULL )) { + njs_internal_error ( vm , " invalid iterator "); + goto error ; + }
MemRepair: src/njs_vmcode.c Although spatially distinct, the agent’s patch creates a behaviorally equivalent safety invariant that effectively blocks the exploit path. Case 2: Scope Divergence (CVE-2019-13309, ImageMagick). The human expert performed a multi-file repair, addressing memory leaks in both the primary command handler (operation.c) and the utility module (mogrify.c). MemRepair correctly fixed the leak in operation.c—the path exercised by the PoC—but missed the corresponding leaks in mogrify.c, whose code paths were not triggered by the test oracle. This illustrates a limitation of testdriven repair: the agent resolves the active exploit path but may miss latent vulnerabilities in unexercised code.
6.3
Threats to Validity
Internal Validity. A primary concern is data leakage, including leakage during retrieval and leakage from the LLM’s pretraining data. To mitigate the impact of the former as much as possible, we enforced strict constraints during experience retrieval: we rigorously excluded any historical instances sharing the same unique CVE identifier and utilized timestamps to filter out any future code committed after the target vulnerability’s disclosure. As for the latter, although we cannot participate in model pretraining to effectively eliminate this factor, we avoid its impact on comparative results by using a consistent backbone LLM. Spefically, in RQ1, we utilize the identical DeepSeek-v3.2 backbone, thereby ensuring that performace improvements are attributable to our memoryguided architecture rather than model-inherent knowledge. External Validity. This concerns the generalizability of our framework across languages and toolchains. A potential limitation is our reliance on the C++-specific Iter_grep tool. However, our evaluation on PatchEval (RQ3) demonstrates that MemRepair maintains
Liu et al.
Table 5: Comparison of complexity between human-written (GT) and MemRepair generated (Gen) patches. # Changed Files Benchmark
# Changed Lines
# Successful Cases Added GT
SEC-Bench Multi-SWE (C++) PatchEval
116 37 131
1.28 2.24 1.01
state-of-the-art performance across Python, JavaScript, and Go even when Iter_grep is replaced with standard text search, suggesting that effectiveness derives from the memory-guided mechanism rather than language-specific static analysis. Regarding PoC dependence, MemRepair’s refinement loop requires a vulnerability PoC for feedback. This is a standard AVR assumption rather than one we introduce: recent SoK studies [24] identify the PoC as the canonical input distinguishing AVR from general-purpose APR. All baselines in our evaluation share this requirement, and we grant OpenHands* the identical check_vul tool to ensure equal PoC access.
7 Related Work 7.1 Automated Vulnerability Repair The paradigm of Automated Vulnerability Repair (AVR) has evolved significantly to address the increasing complexity of software defects. Early efforts primarily relied on template-based [17, 45] or constraint-based [13, 26, 36, 53] techniques. While these methods prioritized semantic correctness, they suffered from the “path explosion” problem and struggled with complex logic flaws lacking formal specifications [52]. Subsequent data-driven approaches, such as VRepair [11], treated repair as a Neural Machine Translation (NMT) task but were often limited by dataset noise and shallow semantic understanding. Recently, LLMs have reshaped the landscape, demonstrating exceptional proficiency in vulnerability detection, root cause analysis, and repair [12, 20, 25, 29, 37]. To enhance LLM performance, literature has explored two primary directions. One field focuses on augmenting context with static knowledge. Representative approaches like VulMaster [56] inject expert knowledge (e.g., CWE [1] relationships) into the prompt to guide reasoning, while retrievalbased methods like CRepair [27] retrieve similar historical patches to serve as few-shot references. Others focus on abstracting patch patterns [8] to improve generalization. The other prioritizes dynamic validation. Earlier works utilized iterative feedback loops [43] to filter invalid patches, while recent advancements like VulDebugger [28] employ agents to actively inspect runtime program states, mimicking human debugging to pinpoint root causes. However, existing methodologies often fail to effectively integrate retrieved knowledge with runtime feedback in repository-level environments, limiting their efficacy on resolving rigorous and complex repositorylevel vulnerabilities.
7.2
Deleted
Total
Gen 1.18 1.16 1.45
GT
Gen
GT
Gen
GT
Gen
10.48 33.00 13.99
17.03 16.76 13.14
5.44 37.16 4.95
9.49 7.49 3.57
15.92 70.16 18.94
26.53 24.24 16.71
GenProg [21] and template strategies like TBar [26], to advanced approaches driven by LLMs [6, 44, 48, 51]. Recently, the introduction of SWE-bench [19], which evaluates systems on real-world GitHub issues, has catalyzed a paradigm shift toward repository-level resolution. Driven by this benchmark, contemporary methodologies predominantly bifurcate into two architectures: interactive agents and fixed workflows. Interactive agents, such as representative OpenHands [39], SWE-agent [47] and Aider [3]), employ LLMs as autonomous planning agents that perform end-to-end issue resolution through iterative interaction with development environments, tools, and codebases. These systems dynamically adapt their strategies based on execution feedback, enabling flexible problem-solving. Fixed workflows (e.g., Agentless [41] and PatchPilot [23]) that rely on structured localization-repair pipelines with predefined stages. By decomposing the resolution process into explicit phase, such as issue understanding, fault localization, and patch generation, to resolve issues. While effective for general functional bugs, these general-purpose resolvers often lack the domain-specific security priors required for vulnerability repair, failing to enforce critical defensive patterns—a limitation our framework addresses through memory-augmented reasoning.
8
Conclusion
In this paper, we proposed MemRepair, a memory-guided agentic framework for repository-level vulnerability repair. By mimicking expert reasoning through a three-tier memory hierarchy and a feedback-driven refinement loop, our framework enables agents to recall historical patterns and learn from runtime trajectories. Extensive evaluation on SEC-Bench (C/C++), PatchEval (Python, Go, JavaScript), and Multi-SWE-bench (C++) demonstrate that MemRepair achieves state-of-the-art vulnerability repair performance while effectively controlling computational cost, validating the efficacy of memory-guided reasoning for resolving complex, repository-level vulnerabilities across diverse programming languages. Looking ahead, we plan to explore more robust memory acquisition and consolidation strategies to further improve the robustness, scalability, and adaptability of agentic vulnerability repair systems.
Data Availability Statement Our code and data are available at https://figshare.com/s/ f2bbe7f7c8a759339368.
Automated Issue Resolution References
Automated Program Repair (APR) has evolved significantly from traditional heuristics, such as encompassing search-based methods like
[1] 2026. Common Weakness Enumeration. https://cwe.mitre.org/. 2026-01-15.
Accessed:
MemRepair: Hierarchical Memory for Agentic Repository-Level Vulnerability Repair
[2] 2026. National Vulnerability Database (NVD). https://nvd.nist.gov/. Accessed: 2026-01-15. [3] Aider. 2024. Introducing Aider. https://aider.chat/ Accessed: 2026-01-15. [4] Alfred Asare Amoah and Yan Liu. 2025. Explainable Recommendation of Software Vulnerability Repair Based on Metadata Retrieval and Multifaceted LLMs. Machine Learning and Knowledge Extraction 7, 4 (2025). doi:10.3390/make7040149 [5] Guru Bhandari, Amara Naseer, and Leon Moonen. 2021. CVEfixes: automated collection of vulnerabilities and their fixes from open-source software. In Proceedings of the 17th International Conference on Predictive Models and Data Analytics in Software Engineering. 30–39. [6] Islem Bouzenia, Premkumar Devanbu, and Michael Pradel. 2024. Repairagent: An autonomous, llm-based agent for program repair. arXiv preprint arXiv:2403.17134 (2024). [7] Quang-Cuong Bui, Ranindya Paramitha, Duc-Ly Vu, Fabio Massacci, and Riccardo Scandariato. 2024. APR4Vul: an empirical study of automatic program repair techniques on real-world Java vulnerabilities. Empirical software engineering 29, 1 (2024), 18. [8] Xiansheng Cao, Junfeng Wang, and Peng Wu. 2025. Enhancing vulnerability repair through the extraction and matching of repair patterns. Journal of Systems and Software (2025), 112528. [9] Cyware. 2024. 6 Vulnerability Management Challenges (and How To Overcome Them). https://cyware.com/ Accessed: 2026-01-12. [10] Qingao Dong, Mengfei Wang, Hengzhi Zhang, Zhichao Li, Yuan Yuan, Mu Li, Xiang Gao, Hailong Sun, Chunming Hu, and Weifeng Lv. 2025. InfCode-C++: Intent-Guided Semantic Retrieval and AST-Structured Search for C++ Issue Resolution. arXiv:2511.16005 [cs.SE] https://arxiv.org/abs/2511.16005 [11] Michael Fu, Chakkrit Tantithamthavorn, Trung Le, Van Nguyen, and Dinh Phung. 2022. VulRepair: a T5-based automated software vulnerability repair. In Proceedings of the 30th ACM joint european software engineering conference and symposium on the foundations of software engineering. 935–947. [12] Michael Fu, Chakkrit Kla Tantithamthavorn, Van Nguyen, and Trung Le. 2023. Chatgpt for vulnerability detection, classification, and repair: How far are we?. In 2023 30th Asia-Pacific Software Engineering Conference (APSEC). IEEE, 632–636. [13] Xiang Gao, Bo Wang, Gregory J Duck, Ruyi Ji, Yingfei Xiong, and Abhik Roychoudhury. 2021. Beyond tests: Program vulnerability repair via crash constraint extraction. ACM Transactions on Software Engineering and Methodology (TOSEM) 30, 2 (2021), 1–27. [14] Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Yu Wu, YK Li, et al. 2024. DeepSeek-Coder: When the Large Language Model Meets Programming–The Rise of Code Intelligence. arXiv preprint arXiv:2401.14196 (2024). [15] Jing Hou, Jiaxuan Han, Cheng Huang, Nannan Wang, and Lerong Li. 2025. LineJLocRepair: A line-level method for Automated Vulnerability Repair based on joint training. Future Generation Computer Systems 166 (2025), 107671. doi:10. 1016/j.future.2024.107671 [16] Yiwei Hu, Zhen Li, Kedie Shu, Shenghua Guan, Deqing Zou, Shouhuai Xu, Bin Yuan, and Hai Jin. 2025. SoK: Automated Vulnerability Repair: Methods, Tools, and Assessments. arXiv:2506.11697 [cs.SE] https://arxiv.org/abs/2506.11697 [17] Zhen Huang, David Lie, Gang Tan, and Trent Jaeger. 2019. Using safety properties to generate vulnerability patches. In IEEE Symposium on Security and Privacy (SP). [18] Nan Jiang, Thibaud Lutellier, and Lin Tan. 2021. Cure: Code-aware neural machine translation for automatic program repair. In 2021 IEEE/ACM 43rd International Conference on Software Engineering (ICSE). IEEE, 1161–1173. [19] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2023. Swe-bench: Can language models resolve real-world github issues? arXiv preprint arXiv:2310.06770 (2023). [20] Sungmin Kang, Bei Chen, Shin Yoo, and Jian-Guang Lou. 2023. Explainable automated debugging via large language model-driven scientific debugging. arXiv preprint arXiv:2304.02195 (2023). [21] Claire Le Goues, ThanhVu Nguyen, Stephanie Forrest, and Westley Weimer. 2011. Genprog: A generic method for automatic software repair. Ieee transactions on software engineering 38, 1 (2011), 54–72. [22] Hwiwon Lee, Ziqi Zhang, Hanxiao Lu, and Lingming Zhang. 2025. SEC-bench: Automated Benchmarking of LLM Agents on Real-World Software Security Tasks. arXiv:2506.11791 [cs.LG] https://arxiv.org/abs/2506.11791 [23] Hongwei Li, Yuheng Tang, Shiqi Wang, and Wenbo Guo. 2025. PatchPilot: A CostEfficient Software Engineering Agent with Early Attempts on Formal Verification. arXiv:2502.02747 [cs.RO] https://arxiv.org/abs/2502.02747 [24] Ying Li, Faysal hossain shezan, Bomin wei, Gang Wang, and Yuan Tian. 2025. SoK: Towards Effective Automated Vulnerability Repair. arXiv:2501.18820 [cs.CR] https://arxiv.org/abs/2501.18820 [25] Fang Liu, Simiao Liu, Yinghao Zhu, Xiaoli Lian, and Li Zhang. 2025. SecureReviewer: Enhancing Large Language Models for Secure Code Review through Secure-aware Fine-tuning. arXiv:2510.26457 [cs.SE] https://arxiv.org/abs/2510. 26457 [26] Kui Liu, Anil Koyuncu, Dongsun Kim, and Tegawendé F Bissyandé. 2019. TBar: Revisiting template-based automated program repair. In Proceedings of the 28th
ACM SIGSOFT international symposium on software testing and analysis. 31–42. [27] Penghui Liu, Yingzhou Bi, Jiangtao Huang, Xinxin Jiang, and Lianmei Wang. 2024. CRepair: CVAE-based Automatic Vulnerability Repair Technology. arXiv preprint arXiv:2411.05540 (2024). [28] Zhengyao Liu, Yunlong Ma, Jingxuan Xu, Junchen Ai, Xiang Gao, Hailong Sun, and Abhik Roychoudhury. 2025. Agent That Debugs: Dynamic State-Guided Vulnerability Repair. arXiv:2504.07634 [cs.SE] https://arxiv.org/abs/2504.07634 [29] Ansong Ni, Miltiadis Allamanis, Arman Cohan, Yinlin Deng, Kensen Shi, Charles Sutton, and Pengcheng Yin. 2024. NExT: Teaching Large Language Models to Reason about Code Execution. arXiv preprint arXiv:2404.14662 (2024). [30] OpenAI. 2024. Text Embedding Models: text-embedding-3-small. https://platform. openai.com/docs/guides/embeddings. Accessed: 2026-01-13. [31] Hammond Pearce, Benjamin Tan, Baleegh Ahmad, Ramesh Karri, and Brendan Dolan-Gavitt. 2023. Examining zero-shot vulnerability repair with large language models. In 2023 IEEE Symposium on Security and Privacy (SP). IEEE, 2339–2356. [32] Zichao Qi, Fan Long, Sara Achour, and Martin Rinard. 2015. An analysis of patch plausibility and correctness for generate-and-validate patch generation systems. In Proceedings of the 2015 international symposium on software testing and analysis. 24–36. [33] Recorded Future. 2025. H1 2025 Malware and Vulnerability Trends. https: //www.recordedfuture.com/ Accessed: 2026-01-12. [34] Shuo Ren, Daya Guo, Shuai Lu, Long Zhou, Shujie Liu, Duyu Tang, Neel Sundaresan, Ming Zhou, Ambrosio Blanco, and Shuai Ma. 2020. CodeBLEU: a Method for Automatic Evaluation of Code Synthesis. arXiv:2009.10297 [cs.SE] https://arxiv.org/abs/2009.10297 [35] Yuchen Shao, Yuheng Huang, Jiawei Shen, Lei Ma, Ting Su, and Chengcheng Wan. 2025. Are LLMs Correctly Integrated into Software Systems? arXiv:2407.05138 [cs.SE] https://arxiv.org/abs/2407.05138 [36] Tianqi Shen, Shaohua Liu, Jiaqi Feng, Ziye Ma, and Ning An. 2025. TopologyAware 3D Gaussian Splatting: Leveraging Persistent Homology for Optimized Structural Integrity. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 39. 6823–6832. [37] Shailja Thakur et al. 2024. VRPilot: Larger Language Models for Automated Vulnerability Repair. arXiv preprint (2024). [38] Vicarius. 2024. Vulnerability Remediation: Complete Process, Challenges, and Automated Best Practices. https://www.vicarius.io/ Accessed: 2026-01-12. [39] Xingyao Wang, Boxuan Li, Yufan Song, Frank F Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, et al. 2024. Openhands: An open platform for ai software developers as generalist agents. arXiv preprint arXiv:2407.16741 (2024). [40] Zichao Wei, Jun Zeng, Ming Wen, Zeliang Yu, Kai Cheng, Yiding Zhu, Jingyi Guo, Shiqi Zhou, Le Yin, Xiaodong Su, et al. 2025. PATCHEVAL: A New Benchmark for Evaluating LLMs on Patching Real-World Vulnerabilities. arXiv preprint arXiv:2511.11019 (2025). [41] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2025. Demystifying llm-based software engineering agents. Proceedings of the ACM on Software Engineering 2, FSE (2025), 801–824. [42] Chunqiu Steven Xia, Yifeng Ding, and Lingming Zhang. 2023. The plastic surgery hypothesis in the era of large language models. In 2023 38th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 522– 534. [43] Chunqiu Steven Xia and Lingming Zhang. 2024. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using chatgpt. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 819–831. [44] Chunqiu Steven Xia and Lingming Zhang. 2024. Automated program repair via conversation: Fixing 162 out of 337 bugs for $0.42 each using ChatGPT. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 819–831. [45] Jifeng Xuan, Matias Martinez, Favio Demarco, Maxime Clement, Sebastian Lamelas Marcote, Thomas Durieux, Daniel Le Berre, and Martin Monperrus. 2016. Nopol: Automatic repair of conditional statement bugs in java programs. IEEE Transactions on Software Engineering 43, 1 (2016), 34–55. [46] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652. [47] John Yang, Carlos E Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. Swe-agent: Agent-computer interfaces enable automated software engineering. Advances in Neural Information Processing Systems 37 (2024), 50528–50652. [48] Xin Yin, Chao Ni, Shaohua Wang, Zhenhao Li, Limin Zeng, and Xiaohu Yang. 2024. Thinkrepair: Self-directed automated program repair. In Proceedings of the 33rd ACM SIGSOFT International Symposium on Software Testing and Analysis. 1274–1286. [49] Daoguang Zan, Zhirong Huang, Wei Liu, Hanwu Chen, Linhao Zhang, Shulin Xin, Lu Chen, Qi Liu, Xiaojian Zhong, Aoyan Li, et al. 2025. Multi-swe-bench: A multilingual benchmark for issue resolving. arXiv preprint arXiv:2504.02605
Liu et al.
(2025). [50] Chenyuan Zhang, Hao Liu, Jiutian Zeng, Kejing Yang, Yuhong Li, and Hui Li. 2024. Prompt-enhanced software vulnerability detection using chatgpt. In Proceedings of the 2024 IEEE/ACM 46th International Conference on Software Engineering: Companion Proceedings. 276–277. [51] Jiayi Zhang, Kai Huang, Jian Zhang, Yang Liu, and Chunyang Chen. 2025. Repair Ingredients Are All You Need: Improving Large Language Model-Based Program Repair via Repair Ingredients Search. arXiv preprint arXiv:2506.23100 (2025). [52] Yufeng Zhang, Zhenbang Chen, Ziqi Shuai, Tianqi Zhang, Kenli Li, and Ji Wang. 2020. Multiplex symbolic execution: Exploring multiple paths by solving once. In Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering. 846–857. [53] Yuntong Zhang, Xiang Gao, Gregory J Duck, and Abhik Roychoudhury. 2022. Program vulnerability repair via inductive inference. In Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA). [54] Yuntong Zhang, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. Autocoderover: Autonomous program improvement. In Proceedings of the 33rd
ACM SIGSOFT International Symposium on Software Testing and Analysis. 1592– 1604. [55] Yicong Zhao, Shisong Chen, Jiacheng Zhang, and Zhixu Li. 2025. ReCode: Improving LLM-based Code Repair with Fine-Grained Retrieval-Augmented Generation. arXiv:2509.02330 [cs.SE] https://arxiv.org/abs/2509.02330 [56] Xin Zhou, Kisub Kim, Bowen Xu, DongGyun Han, and David Lo. 2024. Large Language Model as Synthesizer: Fusing Diverse Inputs for Better Automatic Vulnerability Repair. CoRR abs/2401.15459 (2024). https://doi.org/10.48550/arXiv. 2401.15459 [57] Tingwei Zhu, Tongtong Xu, Kui Liu, Jiayuan Zhou, Xing Hu, Xin Xia, Tian Zhang, and David Lo. 2024. An Empirical Study of Automatic Program Repair Techniques for Injection Vulnerabilities. In 2024 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 25–37.
Received 20 February 2007; revised 12 March 2009; accepted 5 June 2009