---
title: 'Abacus-cve: Fine-Tuned CVE Repair Model'
url: https://www.emergentmind.com/topics/abacus-cve
type: topic
---

# Abacus-cve: Fine-Tuned CVE Repair Model

Abacus-cve is the fine-tuned code-security model introduced in "CVE-Factory: Scaling Expert-Level Agentic Tasks for Code Security Vulnerability" [2602.03012]. It is the paper’s security-specialized variant of Qwen3-32B, released as the open-source checkpoint `Luoberta/LA-Coder` on Hugging Face, and trained with full-parameter supervised fine-tuning on synthetic executable vulnerability-repair trajectories produced by CVE-Factory. Its stated purpose is to improve an LLM or code agent’s ability to repair real-world CVEs in executable environments, with generalization also shown on non-security agent tasks such as Terminal Bench. Within the paper’s broader system, Abacus-cve is coupled to CVE-Factory, LiveCVEBench, a released training dataset, and a leaderboard, so it is best understood as the model component of a larger executable-CVE training and evaluation pipeline [2602.03012].

## 1. Definition and model lineage

Abacus-cve is built from **Qwen3-32B** and is described as the paper’s **fine-tuned model** linked to the released training corpus and benchmark resources [2602.03012]. The model is not presented as a generic code assistant. Its training objective is explicitly to learn from executable CVE reproduction and repair trajectories generated by CVE-Factory, with the aim of strengthening agentic vulnerability repair and executable task completion in realistic code and security environments.

The surrounding paper frames this specialization as a response to a bottleneck in evaluating and improving code agents for security work: existing vulnerability tasks rely on costly, unscalable manual reproduction and suffer from outdated data distributions. CVE-Factory is introduced as the first multi-agent framework to achieve expert-level quality in automatically transforming sparse CVE metadata into fully executable agentic tasks, and this automation is what makes Abacus-cve’s training corpus possible [2602.03012].

The model therefore occupies a specific position in the code-security stack. It is neither a static CVE lookup system nor merely a benchmark participant. It is a full-parameter adaptation of a frontier-scale base model to executable vulnerability repair, grounded in synthetic but executable CVE tasks.

## 2. Synthetic executable training corpus

The training data for Abacus-cve came from **over 1,000 executable training environments** synthesized by CVE-Factory [2602.03012]. The paper states that **770 CVEs** from the PatchEval training set were used as a starting point and that CVE-Factory created executable environments for them for the first time. It also states that an additional **300 CVEs** were sampled from CVElistV5 with **no overlap with any test set**. The resulting training corpus is described as **over 1,000 CVEs / executable tasks**.

Trajectory collection was performed by running **Mini-SWE-Agent with Claude Opus 4.5** on each reproduced task and recording the full interaction traces [2602.03012]. Two fine-tuning scales were then reported: **3k trajectories** from PatchEval reproductions, and **4k trajectories** including the additional CVElistV5 reproductions. The corresponding result-table names are **Qwen3-32B**, **Qwen3-32B + CVE (3k)**, and **Qwen3-32B + CVE (4k)**.

This training design is central to the model’s identity. The paper’s abstract describes the larger corpus as the **first large-scale scaling of agentic tasks in code security**, and the same abstract links that scale to the construction of **LiveCVEBench**, a continuously updated benchmark of **190 tasks spanning 14 languages and 153 repositories** that captures emerging threats including **AI-tooling vulnerabilities** [2602.03012]. A plausible implication is that Abacus-cve is trained not on static vulnerability labels, but on multi-step repair behavior in executable environments.

## 3. Fine-tuning configuration

The appendix gives the exact fine-tuning setup for the Abacus-cve training runs [2602.03012]. Training used **full-parameter training** on **64 H100 GPUs** for **5 epochs**. The **base model** was **Qwen3-32B**. The reported precision was **BFloat16**, the **learning rate** was **1e-5**, **weight decay** was **0.1**, and the **warmup ratio** was **0.001**.

The maximum sequence length was **65,536**. The optimizer was **AdamW**. The attention implementation was **FlashAttention-2**. **RoPE scaling** used **YaRN**. Parallelism was reported as **DeepSpeed ZeRO-3 + SP (size=2)** [2602.03012].

These details matter because the model is not described as a lightweight adapter or partial-update specialization. It is a full-parameter fine-tune of a 32B base model on long-horizon executable trajectories. That configuration is consistent with the paper’s emphasis on interaction traces, verification behavior, and environment-aware repair rather than short-form code completion.

## 4. Benchmark performance and comparative standing

The paper evaluates the fine-tuned model with **Mini-SWE-Agent** on **LiveCVEBench (LCB)**, **PatchEval (PE)**, and **Terminal Bench (TB)** [2602.03012]. The reported headline result is that fine-tuned Qwen3-32B improves from **5.3% to 35.8%** on LiveCVEBench, and that gains generalize to Terminal Bench from **12.5% to 31.3%** in the abstract. The details section clarifies that the **31.3%** Terminal Bench figure corresponds to the **3k CVE** setting, while the **4k CVE** setting reaches **28.75%**.

| Model | LCB / PE / TB | Avg |
|---|---|---|
| Qwen3-32B baseline | 5.29% / 5.66% / 12.50% | 7.82% |
| Qwen3-32B + SETA (4k) | 21.69% / 14.62% / 27.50% | 21.27% |
| Qwen3-32B + CVE (3k) | 31.05% / 19.81% / 31.25% | 27.37% |
| Qwen3-32B + CVE (4k) | 35.79% / 23.58% / 28.75% | 29.37% |

Relative to the unfine-tuned baseline, the **4k CVE-finetuned model** improved **LiveCVEBench: 5.29% → 35.79%**, **PatchEval: 5.66% → 23.58%**, and **Terminal Bench: 12.50% → 28.75%** [2602.03012]. The strongest security-benchmark result in the table is therefore the **4k** variant on **LiveCVEBench** and **PatchEval**, while the best Terminal Bench score is the **3k** variant.

The paper also compares the model to frontier systems on the same benchmarks. On **LiveCVEBench**, the reported scores are **Claude Sonnet 4: 20.11%**, **Claude Sonnet 4.5: 34.39%**, **Claude Opus 4.5: 41.27%**, and **Qwen3-32B + CVE (4k): 35.79%** [2602.03012]. This makes the statement that the model **surpasses Claude 4.5 Sonnet** consistent with the table value **35.79% > 34.39%**. At the same time, the paper’s own table shows that it **does not surpass Claude Opus 4.5**, which remains highest at **41.27%** on LiveCVEBench.

On **PatchEval**, the reported values are **Claude Sonnet 4.5: 28.77%**, **Claude Opus 4.5: 32.08%**, and **Qwen3-32B + CVE (4k): 23.58%** [2602.03012]. On **Terminal Bench**, the reported values are **Claude Sonnet 4.5: 45.00%**, **Claude Opus 4.5: 48.75%**, **Qwen3-32B baseline: 12.50%**, **Qwen3-32B + CVE (3k): 31.25%**, and **Qwen3-32B + CVE (4k): 28.75%**. The comparative picture is therefore mixed: Abacus-cve substantially improves over its base model and exceeds Claude Sonnet 4.5 on LiveCVEBench, but remains below the strongest frontier models on PatchEval and Terminal Bench.

## 5. Design comparisons, learned behavior, and limitations

The paper does not present a dedicated ablation section for the fine-tuning itself, but it provides several comparisons and observations that function as design analyses [2602.03012]. The clearest data-source comparison is between **SETA (4k)** and **CVE-Factory synthetic CVE data**. With approximately matched scale, the CVE data performs better across the reported benchmarks: **LCB: SETA 21.69% vs CVE 31.05% / 35.79%**, **PE: SETA 14.62% vs CVE 19.81% / 23.58%**, and **TB: SETA 27.50% vs CVE 31.25% / 28.75%**. The paper uses this to support the claim that **high-fidelity executable CVE tasks are better training data than terminal-only tasks**.

The comparison between **3k** and **4k** CVE trajectories exposes a more specific tradeoff. The **3k CVE** setting is better on **Terminal Bench (31.25%)** than the **4k** version **(28.75%)**, while the **4k CVE** setting is best on **LiveCVEBench (35.79%)** and **PatchEval (23.58%)** [2602.03012]. This suggests a tradeoff: more CVE data improves security benchmarks, while the smaller CVE set may transfer slightly better to terminal-only tasks.

The paper also reports qualitative behavioral changes after fine-tuning. The fine-tuned model **increases average interaction length from 15.88 steps to 57.54 steps**, **stops submitting fixes without verification**, and **performs more active exploration and test-based validation** [2602.03012]. These observations are important because they describe not only score changes but also a learned repair policy that is more agentic and more verification-oriented.

The limitations identified in the paper are tied directly to reproduction quality. Some reproduced tasks still contained **mock implementations** and **static tests** despite explicit constraints. In real-world CVE reproduction, some failures came from **parser limitations**, **retry-limit exhaustion**, and **network/timeouts** [2602.03012]. The training data quality is therefore bounded by CVE-Factory’s reproduction quality and by the possibility of false positives in generated environments.

## 6. Position within CVE-based vulnerability analysis

Abacus-cve is a model for executable CVE repair, but its significance becomes clearer when placed against adjacent CVE-analysis literature. "Software Vulnerability Analysis Using CPE and CVE" reports a **lack of synchronization between both datasets** and argues that **fully automated CPE assignment is prone to errors due to the CPE and CVE shortcomings**; its proposed alternative is a prioritized list of CPE candidates with user confirmation and adaptation [1705.05347]. This establishes a baseline difficulty for any CVE-driven workflow: the mapping from software inventory to known vulnerabilities is itself fragile.

"CVE Breadcrumbs: Tracking Vulnerabilities Through Versioned Apache Libraries" adds a temporal dimension by treating CVE presence as a version-aware lifecycle rather than a single event [2512.02259]. It analyzes **24,285 Apache libraries, 1,285 CVEs, and 157 CWEs**, and frames exposure in terms of introduction, disclosure, and remediation windows. This suggests that executable CVE tasks are most informative when they are tied to exact version histories rather than to static vulnerability labels alone.

"ASSEMBLAGE-DEEPHISTORY: A Cross-Build Binary Dataset with Temporal Coverage" extends the same broad movement into binary analysis by combining **cross-build diversity, cross-version history, and CVE labels** in a queryable database of **73,610 binaries spanning 248 open-source projects** [2605.21615]. The shared theme across these works is that high-quality vulnerability analysis increasingly depends on queryable structure, version awareness, and executable or build-grounded context.

Within that landscape, Abacus-cve can be read as the model counterpart to a broader infrastructure shift. A plausible implication is that its gains arise not only from scale, but from the fact that the training signal is an executable repair trajectory attached to a concrete environment rather than a decontextualized text description of a CVE.

The associated resources are explicitly open-sourced. The paper lists **CVE-Factory** at `https://github.com/livecvebench/CVE-Factory`, **LiveCVEBench Preview** at `https://github.com/livecvebench/LiveCVEBench-Preview`, the **Abacus-cve model** at `https://huggingface.co/Luoberta/LA-Coder`, the **training dataset** at `https://huggingface.co/datasets/Luoberta/cve_train`, and the **leaderboard** at `https://livecvebench.github.io/` [2602.03012]. In that sense, Abacus-cve is not only a reported result, but a released checkpoint tied directly to a synthetic CVE training set and to an executable benchmark ecosystem.

Source: https://www.emergentmind.com/topics/abacus-cve