EvoRepair: Self-Evolving AVR Framework

• EvoRepair is an experience-based, self-evolving framework for automated vulnerability repair that accumulates and reuses repair trajectories.
• It integrates an experience bank with retrieval, quality scoring, and iterative updates to guide repairs across multiple vulnerabilities.
• Empirical results on benchmarks like PATCHEVAL and SEC-bench demonstrate high fix rates and significant improvements over traditional LLM-based methods.

EvoRepair most specifically denotes an experience-based, self-evolving framework for automated vulnerability repair (AVR) with LLMs, introduced as a mechanism for accumulating, refining, and leveraging domain-specific knowledge across long-horizon repair episodes (Hu et al., 28 May 2026). It augments a vanilla ReAct-style repair agent with an explicit experience bank, a retrieval module, and a quality-aware update cycle that turns prior repair trajectories into reusable security repair knowledge. In a broader interpretive sense, the label also appears as a useful way to think about several evolutionary or iterative “repair” systems in adjacent domains, including all-in-one image restoration, multi-hunk automatic program repair, system-level package repair, and block-based learner-program repair (Ma et al., 4 Dec 2025).

1. Conceptual basis and problem setting

EvoRepair addresses a failure mode of LLM-based AVR in which repair attempts remain largely stateless both within and across vulnerabilities. The motivating deficiencies are twofold: the lack of intra-vulnerability experience accumulation and the lack of cross-vulnerability experience reuse. In that setting, an agent may repeatedly make similar mistakes during iterative repair and may underutilize repair knowledge from historical vulnerabilities. EvoRepair reframes AVR as a cyclic learn-and-repair process in which repair traces are not treated as disposable logs, but as structured experience to be retrieved, scored, and updated over time (Hu et al., 28 May 2026).

The target task is real vulnerability repair under repository-level execution constraints. Benchmark instances provide source code, reproducible environments, vulnerability descriptions, and validation scripts. On PATCHEVAL, EvoRepair operates on the 230 Docker-based instances drawn from a 1,000-CVE benchmark and uses oracle localization. On SEC-bench, it handles 200 C vulnerabilities across 29 projects in poc-desc mode, i.e., end-to-end from CVE and PoC description without oracle localization. The framework is therefore not limited to localized patch generation; it integrates diagnosis, code modification, validation, and iterative reuse of prior security-specific repair knowledge (Hu et al., 28 May 2026).

The central abstraction is the experience bank. Rather than storing raw transcripts, EvoRepair stores structured experiences that encode vulnerability analysis, repair strategy, trajectory analysis, reusable rules, and reflection. This design makes past repairs available as guidance for both the same vulnerability and similar vulnerabilities of related CWE or behavioral class. The result is a shift from isolated trial-and-error to experience-guided repair.

2. Architecture and repair loop

The framework comprises four main components: an experience bank, an experience retrieval module, a vanilla repair agent called “Vulnerability Repair,” and an experience construction, scoring, and update stage (Hu et al., 28 May 2026). The repair agent itself is intentionally minimal. It is a Mini-SWE-style code agent powered by the base LLM and a Bash tool, operating in a Docker container with task-specific skills: Understand Vulnerability, Reproduce PoC, Locate Vulnerability, Verify Patch, and Reset Environment. The action space includes shell execution and a special SUBMIT action.

Operationally, EvoRepair runs over turns. For each still-unfixed vulnerability $q$, the system retrieves relevant experiences from the bank, injects them together with CVE/CWE information and other task context, runs the vanilla agent under a bounded ReAct loop, validates the resulting patch, extracts a new experience from the trajectory, and updates the bank. Vulnerabilities fixed in a given turn are removed from the unresolved set. The process continues until the turn-level yield falls below a threshold or the set is exhausted. Within each individual vulnerability run, the attempt budget is capped at 100 steps or \$3 LLM cost (Hu et al., 28 May 2026).

The turn-level stopping rule is formalized through cumulative successful repair rate $R_n$ and cumulative cost $C_n$. EvoRepair defines growth rates

$\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$

and

$\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$

then computes the yield rate

$\alpha = \frac{\beta}{\gamma}.$

When $\alpha$ falls below a threshold, empirically $0.15$–$0.25$, further turns are stopped because additional cost does not produce sufficient additional fixes (Hu et al., 28 May 2026).

The agent’s memory structure is organized as a $2 \times 2$ matrix spanning successful versus failed attempts and self versus other sources. This explicitly separates intra-vulnerability memory from cross-vulnerability memory and gives failed attempts a formal role as negative experience rather than mere discarded history.

3. Experience representation, retrieval, and self-evolution

EvoRepair’s experience schema has five dimensions. Dimension A, Vulnerability Introduction and Analysis, records type, location, reproduction steps, root cause, impact, and affected components. Dimension B, Repair Strategy, records the remediation method, rationale, expected effectiveness, and alternatives considered. Dimension C, Trajectory Analysis, stores both positive and negative trajectory evidence. Dimension D, Experience Summary, turns the trajectory into reusable rules with applicability conditions, goals, guidance, and minimal examples. Dimension E, Reflection and Improvement, records residual limitations and future strategy adjustments (Hu et al., 28 May 2026).

Retrieval is embedding-based but not similarity-only. Given a query vulnerability $R_n$0 and bank entries $R_n$1, EvoRepair first computes $R_n$2, using bge-large-en-v1.5 embeddings over experience content plus meta-data such as CVE and CWE. It then filters the top-$R_n$3 experiences by similarity,

$R_n$4

and combines similarity with an intrinsic experience score:

$R_n$5

The final injected set is

$R_n$6

A notable rule is that a vulnerability’s own past experiences are always included, ensuring intra-vulnerability accumulation even when cross-vulnerability similarity is weak (Hu et al., 28 May 2026).

Experience scoring is quality-aware. An LLM-as-a-Judge, adopted as Qwen3-Max after the strongest Pearson correlation with human ratings, scores each entry along $R_n$7 and $R_n$8. The combined score is

$R_n$9

with $C_n$0 in the experiments. Pearson correlation is written as

$C_n$1

Each experience is scored three times and averaged to reduce variance (Hu et al., 28 May 2026).

The update rule is explicitly evolutionary. For each vulnerability, experiences form a linked sequence $C_n$2. If a new entry scores lower than its predecessor, it is discarded; if it scores higher, it replaces the predecessor; if scores tie, both are fused into a polished experience. Experiences are stored as Markdown files in a hierarchical directory tree and as embeddings in Chroma, producing a bank that evolves toward higher-quality and more transferable repair knowledge (Hu et al., 28 May 2026).

4. Empirical performance and transfer behavior

On PATCHEVAL, EvoRepair fixes 215 of 230 vulnerabilities, reaching $C_n$3. On SEC-bench, it fixes 174 of 200, reaching $C_n$4. Across both benchmarks, it fixes 389 of 430, reaching $C_n$5 overall. These are the best reported results among the compared methods and exceed the latest LLM-based baseline LoopRepair by $C_n$6 on PATCHEVAL and $C_n$7 on SEC-bench, surpass IntentFix by $C_n$8 and $C_n$9, and exceed the recent self-evolving agent Live-SWE-Agent by $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$0 overall (Hu et al., 28 May 2026).

The baseline landscape is broad. On the combined 430 vulnerabilities, Live-SWE-Agent fixes 359, the Vanilla Agent 349, LoopRepair 231, ChatRepair 218, IntentFix about 125, and PailGen about 133. Learning-based systems remain much weaker: VulRepair and VulMaster reach at most $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$1–$\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$2 combined. These comparisons place EvoRepair not merely above single-shot repair, but above iterative, agentic, and prior self-evolving alternatives (Hu et al., 28 May 2026).

Ablation studies isolate the role of experience engineering. Retrieval using only similarity degrades performance for all tested models; on PATCHEVAL, GPT-5-mini improves from 205 to 215 fixes when experience scoring is included, and Qwen3.5-Plus improves from 208 to 220. Example-driven experience construction is also important: removing minimal concrete examples and retaining only natural-language summaries reduces GPT-5-mini from 215 to 209 and Qwen3.5-Plus from 220 to 207. The number of retrieved experiences is approximately bell-shaped, with $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$3 near-optimal, best on three of five tested models and second-best on the other two (Hu et al., 28 May 2026).

Cold-start behavior is asymmetric. On PATCHEVAL with GPT-5-mini, “Standard Patch” warm-up worsens repair from 78 to 57, whereas “Pre-repair” raises it to 105. Similar patterns hold across other models, suggesting that trajectory-derived experiences with analysis and reflection are materially more useful than raw historical patches (Hu et al., 28 May 2026).

Transfer experiments on VUL4J further test generality. Experiences learned on PATCHEVAL with Qwen3.5-Plus improve Java vulnerability repair from the no-transfer setting to 34 of 79 for same-model transfer and 25 of 79 for cross-model transfer, corresponding to $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$4 and $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$5 improvement. EvoRepair thereby outperforms NTR, VRPILOT, APR4Vul, ChatRepair, and TSAPR on that benchmark as well (Hu et al., 28 May 2026).

5. Broader uses of the “EvoRepair” idea

The term “EvoRepair” also functions as a broader conceptual label for evolutionary or iterative repair systems outside vulnerability repair. In the materials considered here, it is applied not as a single unified framework, but as a recurring design pattern that combines adaptive internal representations with adaptive optimization or evidence reuse.

Usage	Domain	Central mechanism
EvoRepair	Vulnerability repair	Experience-based self-evolution with an experience bank (Hu et al., 28 May 2026)
“EvoRepair” as a useful way to think about EvoIR	Image restoration	Frequency-Modulated Module and Evolutionary Optimization Strategy (Ma et al., 4 Dec 2025)
“Harnessing evolution” for multi-hunk repair	Automatic program repair	Evolutionary siblings and simultaneous repair in Hercules (Saha et al., 2019)
“Very close in spirit” to EvoRepair	System-level package repair	Evidence-preserving iterative build-guided repair in EvidenT (Zhao et al., 9 May 2026)
GenProg-style evolutionary APR re-engineered for Scratch	Block-based learner programs	Population-based search, fault localization refinements, and fix sources in RePurr (Schweikl et al., 16 Apr 2025)

In image restoration, “EvoRepair” is presented as a useful way to think about EvoIR: an evolutionary, frequency-aware engine that repairs images corrupted by many different and possibly mixed degradations within a single model. The two central mechanisms are the Frequency-Modulated Module, which explicitly separates high- and low-frequency branches, and the Evolutionary Optimization Strategy, which evolves loss weights over training to balance structural fidelity and perceptual quality (Ma et al., 4 Dec 2025).

In classical APR, the notion appears in Hercules through “evolutionary siblings”: similar-looking code in similar contexts with similar edit histories that are expected to undergo similar changes. Hercules uses test-suite spectrum, code similarity, and revision history to discover such siblings and then repair them simultaneously, correctly fixing 49 Defects4J bugs, including 15 multi-hunk bugs and 13 bugs not fixed by any other technique in that comparison (Saha et al., 2019).

In system-level package repair, EvidenT is described as very close in spirit to EvoRepair because it treats builds as iterative, evidence-driven repair problems. Its controller preserves build feedback, repair history, cached findings, and knowledge context across iterations, and on 219 real-world RISC-V package build failures it repairs 118 packages, or $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$6, outperforming agentic baselines and direct LLM-based repair by large margins (Zhao et al., 9 May 2026).

In educational APR, RePurr is explicitly characterized as a GenProg-style evolutionary program repair system re-engineered for Scratch. It adapts representation, operators, fitness, and fault localization to the block-based setting and shows that APR can effectively improve and sometimes fully fix learners’ programs, thereby enabling automated generation of hints and feedback (Schweikl et al., 16 Apr 2025).

6. Limitations and open directions

Within AVR proper, EvoRepair inherits several limitations acknowledged in the primary study. Benchmark dependence remains significant: the evaluated experience distribution is shaped by PATCHEVAL, SEC-bench, and VUL4J. Test-suite adequacy is another structural constraint, because success is defined by PoC and unit tests; this may underapproximate true security correctness. Cost and scalability are nontrivial as well, since experience extraction and scoring require extra LLM calls and the experience bank grows over time. Model dependence also persists: although EvoRepair is designed to be framework-agnostic, some gains rely on the reasoning strength of the underlying LLM (Hu et al., 28 May 2026).

The cost analysis is not uniformly favorable across backbones. On PATCHEVAL, total cost across five models is essentially unchanged between vanilla and EvoRepair, but the distribution varies: DeepSeek-v3.1 incurs $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$7 cost, while Qwen3.5-Plus shows $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$8, because stronger models converge faster when guided by experience. Early-stop thresholds for $\beta = \frac{R_n - R_{n-1}}{R_{n-1}}$9 between $\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$0 and $\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$1 reduce cost by $\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$2–$\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$3 with only $\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$4–$\gamma = \frac{C_n - C_{n-1}}{C_{n-1}},$5 loss in fix rate, indicating that the framework’s self-evolution also requires explicit cost-governance policies (Hu et al., 28 May 2026).

The relation to other self-evolving agents is complementary rather than exclusive. The reported combination of EvoRepair with Live-SWE-Agent’s tool-evolving prompt does not dramatically raise final fix counts but improves convergence speed, suggesting a division in which tool evolution primarily affects efficiency while experience evolution primarily affects the performance ceiling. This suggests that future work may combine persistent experience banks with richer tool synthesis, static or dynamic analysis, cross-language experience alignment, or multi-agent experience sharing (Hu et al., 28 May 2026).

Taken in the narrow sense, EvoRepair is a security-focused, experience-based self-evolving AVR framework whose defining contribution is the conversion of repair trajectories into scored, retrievable, and continuously refined repair knowledge. Taken in the broader sense visible across adjacent literature, it names a family resemblance among systems that treat repair as an adaptive evolutionary process: they preserve and reuse task-relevant structure—whether experiences, histories, evidence, or frequency decompositions—to guide subsequent repair more effectively.