Vulnerability Affected Versions Identification
- Vulnerability Affected Versions Identification is the process of pinpointing which released software versions retain vulnerable logic by analyzing patch history, commit traces, and dependency graphs.
- It employs tracing-based, matching-based, and exploit-based paradigms to reconstruct historical code changes and evaluate vulnerability impact across ecosystems.
- Recent methods achieve improved precision and recall by integrating multi-dimensional evidence, yet ensemble approaches remain essential due to inherent data-quality challenges.
Vulnerability Affected Versions Identification is the task of determining exactly which released software versions retain the vulnerable logic associated with a disclosed flaw. In repository-centered formulations, a version is affected if it contains the vulnerability-introducing logic and remains unfixed; operationally, vulnerable versions are those whose code history lies after the vulnerability-introducing commit and before the patch commit that fixes the flaw (Cheng et al., 2024). Across ecosystems, however, the problem extends beyond linear release ranges: it also includes exact package-version labeling, dependency-propagated affectedness, embedded library version detection, and, in highly configurable systems, variant-specific vulnerability scope defined by compile-time options rather than chronology alone (Mandl et al., 22 Apr 2026, Jia et al., 2022, Zhan et al., 2021, Paixão et al., 24 Jun 2026).
1. Definitions and analytical scope
At its core, the problem asks for the affected subset of released versions of a project. One precise formulation is: given a reported vulnerability in project , and the set of released versions , identify the subset of versions that retains vulnerable logic (Chen et al., 4 Sep 2025). This framing distinguishes the task from generic vulnerability detection: the question is not merely whether a flaw exists somewhere in the codebase, but which concrete releases should be labeled affected.
Several adjacent definitions appear in the literature. In patch-history reasoning for open-source C/C++, the vulnerable evolution of a function is modeled as an originally safe function modified by a vulnerability-introducing commit into a vulnerable function ; later feature or refactoring commits may transform it into a revised but still vulnerable form ; finally the patch commit produces a fixed function (Cheng et al., 2024). In defect-life-cycle work, the same interval logic appears as , where is the introducing version and the fixing version (Vandehei et al., 2020). In cross-ecosystem evaluation, affectedness is made fully extensional through exact tuples , where is the ecosystem, 0 the component, 1 the exact version, and 2 the vulnerability identifier (Mandl et al., 22 Apr 2026).
The field also distinguishes different units of analysis. At the vulnerability level, a method succeeds only if it predicts the entire affected-version set exactly; at the version level, each release is scored independently, so partial credit is possible even when the full range is wrong (Chen et al., 4 Sep 2025). This distinction is operationally important because many methods appear competent under per-version metrics while remaining unreliable for exact range reconstruction.
A further refinement arises in configurable systems. In Linux, FFmpeg, and PHP, the same chronological version can yield many compiled variants, so version-level labels are often too coarse. PatchLens formalizes this with the Vulnerability Impact Condition (VIC), a Boolean predicate over configuration options that denotes all variants that contained the original flaw (Paixão et al., 24 Jun 2026). This means that, in some settings, “affected version” is only a first approximation to the more precise notion of an “affected variant.”
2. Main methodological paradigms
Current research organizes the task around several evidence sources: patch and history reconstruction, code matching, exploit execution, exact version queries against vulnerability databases, and dependency- or provenance-aware resolution. The broadest comparative study groups tools into tracing-based and matching-based paradigms (Chen et al., 4 Sep 2025).
Before comparing them, it is useful to place the major paradigms side by side.
| Paradigm | Representative work | Core evidence |
|---|---|---|
| Tracing-based | VCCFinder, V-SZZ, Lifetime, SEM-SZZ, TC-SZZ, LLM4SZZ (Chen et al., 4 Sep 2025) | Fixing patch, backtracing, inducing-commit inference |
| Matching-based | ReDeBug, VUDDY, MOVERY, V1SCAN, FIRE, VULTURE (Chen et al., 4 Sep 2025) | Vulnerability signatures matched against historical code |
| Exploit-based | Cross-version exploit execution in Java libraries (Chen et al., 27 Mar 2026) | Reproduced exploit behavior across version history |
| Exact version-query ground truth | OSV-derived package-version tuples (Mandl et al., 22 Apr 2026) | Query exact 3 instances for vulnerability applicability |
Tracing-based methods inherit the logic of SZZ: start from a known fix, identify statements to trace, blame them backward through repository history, select an inducing commit, and infer all releases between introduction and fix as affected (Chen et al., 4 Sep 2025). Their strength is temporal context and typically stronger recall; their weakness is dependence on heuristics for statement selection, commit tracing, inducing-commit selection, and branch-aware version inference. Matching-based methods instead derive signatures of vulnerable logic and scan historical versions for code that looks equivalent. Their strength is often higher precision; their weakness is brittleness under refactoring, code movement, or semantic rewrites.
Other paradigms broaden the evidence base. Exploit-driven identification treats successful exploit execution as empirical confirmation that a version is affected. Exact version-query approaches reduce the problem to membership of concrete package-version tuples. Dependency-propagation studies ask whether a downstream version is affected because its resolved dependency tree includes a vulnerable upstream version. Provenance-aware approaches add another layer by distinguishing upstream version numbers from downstream distribution revisions or vendored artifacts.
A recurring misconception is that these paradigms are interchangeable. The literature suggests instead that they answer slightly different questions: tracing and matching reconstruct source-history boundaries, exploits confirm behavioral affectedness, and exact tuple or provenance approaches define affectedness at package or artifact level. This suggests that robust pipelines are likely to combine them rather than substitute one for another.
3. Patch- and history-based reconstruction
Patch-based reasoning remains the dominant formulation for repository-grounded affected-version identification. Vercation, designed for open-source C/C++, is an end-to-end pipeline with three phases: P1 vulnerable code extraction, P2 code changes detection / VIC localization, and P3 vulnerable version range delineation (Cheng et al., 2024). It begins from a vulnerability patch commit, uses bidirectional program slicing over the patched function to derive a reduced dangerous flow, prompts an LLM with CVE/CWE metadata plus that sliced code to identify vulnerability-relevant statements, backtraces those statements through git blame, and compares pre- and post-modification code with a two-stage clone test: syntactic prefilter followed by AST-based semantic comparison.
The semantic comparison in Vercation is explicitly structural rather than embedding-based. It uses function inlining or expansion, AST normalization such as switch-case to if-else, loop normalization, relational-operation normalization, and in-order traversal followed by edit distance (Cheng et al., 2024). Vulnerable statements are weighted unequally, with elevated weight for statements containing “dangerous functions,” and the final vulnerable version set is defined through Git reachability as 4, where 5 are version tags reachable from the vulnerability-introducing commit and 6 are those reachable from the patch commit.
The same paper is explicit about why simpler approaches fail. Prior methods often include vulnerability-irrelevant code in extracted features and rely heavily on syntactic-level clone detection, which breaks under refactoring, code movement, or semantics-preserving rewrites (Cheng et al., 2024). This diagnosis aligns with the large benchmark study’s stage taxonomy: tracing tools fail in statement selection, commit tracing, vulnerability-inducing commit selection, and affected-version inference; matching tools fail in coarse signature construction and rigid matching logic (Chen et al., 4 Sep 2025).
When the fixing commit itself is unknown, affected-version inference inherits upstream uncertainty from patch localization. This is the setting targeted by automated silent-fix identification and CVE-to-commit mapping. VFFINDER classifies commits as vulnerability-fixing commits using annotated ASTs and a Graph Attention Network, thereby acting as a front end for later release mapping rather than producing affected ranges itself (Nguyen et al., 2023). Favia similarly treats fixing-commit identification as the hard repository-forensics step before branch/tag containment analysis, using candidate ranking plus a ReAct-based LLM agent that evaluates whether a candidate commit causally aligns with the vulnerability root cause (Storhaug et al., 13 Feb 2026). A related study on vulnerability patch detection likewise frames patch localization as the precursor to affected-version identification and uses version-driven candidate filtering followed by LLM-based multi-round dialogue voting (Xu et al., 19 Sep 2025). MAS-SZZ extends this repository-history line by using a multi-agentic workflow to identify vulnerability-inducing commits from a known fix, again with the explicit motivation that VIC identification is foundational for affected version analysis (Cao et al., 27 Apr 2026).
4. Behavioral, dependency-aware, and artifact-aware evidence
A second major strand treats affectedness as an empirical or artifact-resolution problem rather than purely a source-history problem. The most prominent example is exploit-based identification. In Java libraries, disclosed exploits executed across historical version histories achieve 83.0% recall and 99.3% precision without modification, and manual exploit migration raises recall to 96.1% (Chen et al., 27 Mar 2026). The same study reports 796 confirmed missing affected versions added to the CPE dictionary. This directly weakens the long-standing assumption that disclosed exploits are too version-specific to support scalable affected-version identification.
Dependency-aware studies refine what it means for a version to be affected. In the Cargo ecosystem, the task is not only whether a crate version is directly vulnerable, but whether it is indirectly affected because Cargo’s dependency resolution selects a vulnerable upstream version. The resulting dependency-vulnerability knowledge graph contains 75,922 library nodes, 494,290 library_version nodes, 351 cve nodes, and 3,524,878 version_depends edges (Jia et al., 2022). The study reports 6,731 directly affected versions, 97,779 propagated affected versions, and 19.78% of all Cargo versions affected through propagation. Its central methodological point is that affectedness must be computed over resolved version relationships, not merely declared dependency ranges.
Artifact-level exactness matters equally in mobile and polyglot supply chains. ATVHunter targets Android applications and insists that library-level detection is insufficient because not all library versions are vulnerable. Its two-phase detection approach identifies exact third-party-library versions using CFGs as coarse-grained features and opcodes in each basic block as fine-grained features, yielding 90.55% precision and 88.79% recall at version level (Zhan et al., 2021). In Python, cross-ecosystem vulnerability analysis for native libraries goes further by resolving vendored binaries to exact OS package revisions or upstream releases. That provenance-aware method identifies 39 directly vulnerable packages and 312 indirectly vulnerable client packages, and reports up to 97% false positive reduction compared to upstream version matching (Alexopoulos et al., 19 Mar 2026). The key lesson is that version strings alone can be misleading when distribution maintainers backport fixes into older-looking upstream releases.
Highly configurable systems add a variant dimension orthogonal to chronology. PatchLens computes precise, human-readable VICs for 1,192 Linux kernel, 289 FFmpeg, and 100 PHP patches, without compiling any variant (Paixão et al., 24 Jun 2026). The predicates are compact, with average 1.84 variables for Linux, 3.23 for FFmpeg, and 1.04 for PHP. Only 6.24% of analyzed Linux vulnerabilities and 0% of analyzed FFmpeg vulnerabilities are system-wide, showing that version labels often hide a much smaller affected-variant space.
5. Empirical effectiveness and the data-quality problem
Despite rapid methodological growth, exact affected-version identification remains difficult. The most comprehensive benchmark to date evaluates 12 representative tools across 1,128 real-world C/C++ vulnerabilities from nine projects and finds that no evaluated individual tool exceeds 45.0% vulnerability-level accuracy (Chen et al., 4 Sep 2025). The best standalone tool, VCCFinder, reaches 44.9% vulnerability-level accuracy with version-level precision 79.0%, recall 76.6%, and F1 77.8%; the best voting ensemble reaches 55.0% vulnerability-level accuracy and 84.8% version-level F1. The paper’s central conclusion is therefore deliberately pessimistic: ensemble strategies improve results, but exact affected-version identification remains largely unsolved.
This result is not contradicted by stronger point solutions on narrower settings. Vercation, evaluated on a dataset of 74 CVEs, 11 C/C++ OSS projects, and 1,013 released versions, reports precision 0.892, recall 0.958, and F1 0.924, outperforming AG-SZZ, B-SZZ, V-SZZ, NVD, and V0Finder on that benchmark (Cheng et al., 2024). It also reports 1612 correct vulnerable versions and notes that 89 of 276 historical comparisons (32.2%) were refactoring commits with low syntactic but high semantic similarity. These numbers show that carefully engineered pipelines can perform strongly on curated settings, even though broad field-level robustness remains limited.
A parallel problem is the reliability of the labels used for evaluation and deployment. The long-standing Chrome/NVD study found that, among 167 verifiable NVD entries, 134 (81%) had errors in vulnerable-version assignments, and that even under the optimistic assumption that all unverifiable vulnerabilities were correct, more than 7% were still erroneous (Nguyen et al., 2013). The same paper introduced stretched-past error, where NVD marks a version as affected even though it predates the earliest verified vulnerable version. This diagnosis has reappeared in modern studies. Vercation reports 134 incorrect vulnerable OSS versions in NVD reports, while its application section says that, in a dataset of 342 CVEs from NVD, 134 CVEs (38.1%) had incomplete or inaccurate CPE information (Cheng et al., 2024). The wording is explicitly inconsistent between “versions” and “CVEs,” but the intended conclusion is consistent: public vulnerability metadata frequently misstates affected-version scope.
This is why ground-truth construction has become a research problem in its own right. One multi-ecosystem evaluation defines ground truth as exact tuples 7 and builds them by enumerating exact package versions from registries, querying OSV for each version, and normalizing returned identifiers (Mandl et al., 22 Apr 2026). Its Temporal Consistency Controlled Evaluation rebuilds the ground truth before and after tool execution and accepts a run only when dataset hashes match, thereby treating affected-version truth as a time-bounded snapshot rather than timeless fact. This suggests that disagreements among tools often reflect differences in data semantics and version-matching logic as much as differences in algorithm design.
6. Limitations, controversies, and current research directions
The literature converges on several structural limitations. First, patch-local evidence is often noisy. Add-only patches, multi-file patches, and multi-branch development degrade both tracing and matching tools (Chen et al., 4 Sep 2025). Vercation explicitly limits its scope to open-source C/C++ software, assumes a known Git patch commit, and focuses on vulnerabilities that can be localized within function-level code, making it less directly suited to complex interprocedural or architectural interactions (Cheng et al., 2024). Patch-based systems that reason over versions but not branches also only partially address backports and nonuniform patch propagation.
Second, empirical confirmation is powerful but incomplete. The Java exploit study is clear that exploit execution is a strong confirmation mechanism, not a complete substitute for databases and code-based analysis: databases still identify on average 2,070.8 correct affected versions that exploit execution misses, and the 96.1% recall figure requires manual migration of exploits for 1,885 failed cases (Chen et al., 27 Mar 2026). This makes exploit-assisted affected-version identification highly reliable as a positive signal, but labor-intensive when used for exhaustive enumeration.
Third, affectedness is increasingly recognized as multi-dimensional. A version may be vulnerable at source level but not as a package artifact because the fix was backported into a downstream revision (Alexopoulos et al., 19 Mar 2026). A product version may be labeled affected while only a small set of compile-time variants are actually exposed (Paixão et al., 24 Jun 2026). A dependency may be reported vulnerable at crate or package level while the actually resolved version graph excludes the flaw (Jia et al., 2022). These results suggest that the field is moving from coarse range labeling toward richer notions of provenance, resolution, and configuration.
Finally, the most comprehensive empirical study argues that incremental tuning is unlikely to solve the problem and calls for “fundamentally new approaches” (Chen et al., 4 Sep 2025). The concrete directions named across the literature include patch preprocessing to filter unrelated edits, root-cause localization tailored to vulnerability types, semantic presence verification instead of approximate structural matching, branch-aware and backport-aware inference, stronger release-graph models, exploit-assisted confirmation, and variant-aware enrichment of advisories. A plausible implication is that the mature form of vulnerability affected versions identification will be neither purely repository-mining nor purely database-driven, but a layered synthesis of source history, exact package-version evidence, exploit behavior, dependency resolution, artifact provenance, and configuration predicates.
