Abacus-cve: Fine-Tuned CVE Repair Model
- Abacus-cve is a fine-tuned security model derived from Qwen3-32B, designed for repairing executable CVEs using synthetic repair trajectories.
- The model leverages a training corpus of over 1,000 synthesized CVE tasks to achieve significant improvements on benchmarks like LiveCVEBench and PatchEval.
- Full-parameter fine-tuning on executable tasks enhances agentic vulnerability repair, promoting active exploration and test-based validation in realistic environments.
Abacus-cve is the fine-tuned code-security model introduced in "CVE-Factory: Scaling Expert-Level Agentic Tasks for Code Security Vulnerability" (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026).
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 (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026).
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 (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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) (Luo et al., 3 Feb 2026).
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) (Luo et al., 3 Feb 2026). 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% (Luo et al., 3 Feb 2026). 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% (Luo et al., 3 Feb 2026). 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% (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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%) (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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 (Luo et al., 3 Feb 2026). 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 (Sanguino et al., 2017). 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 (Garcia et al., 1 Dec 2025). 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 (Liu et al., 20 May 2026). 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/ (Luo et al., 3 Feb 2026). 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.