---
title: Vulnerability Affected Versions Identification
url: https://www.emergentmind.com/topics/vulnerability-affected-versions-identification
type: topic
---

# Vulnerability Affected Versions Identification

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 [2408.07321]. 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 [2604.21111][2210.07482][2102.08172][2606.25863].

## 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 \(P\), and the set of released versions \(V=\{v_1, v_2, ..., v_n\}\), identify the subset of versions that retains vulnerable logic [2509.03876]. 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 \(F_v\); later feature or refactoring commits may transform it into a revised but still vulnerable form \(F_{vr}\); finally the patch commit produces a fixed function \(F_p\) [2408.07321]. In defect-life-cycle work, the same interval logic appears as \(AV = [IV, FV)\), where \(IV\) is the introducing version and \(FV\) the fixing version [2011.05531]. In cross-ecosystem evaluation, affectedness is made fully extensional through exact tuples \((e,c,v,u)\), where \(e\) is the ecosystem, \(c\) the component, \(v\) the exact version, and \(u\) the vulnerability identifier [2604.21111].

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 [2509.03876]. 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 [2606.25863]. 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 [2509.03876].

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 [2509.03876] | Fixing patch, backtracing, inducing-commit inference |
| Matching-based | ReDeBug, VUDDY, MOVERY, V1SCAN, FIRE, VULTURE [2509.03876] | Vulnerability signatures matched against historical code |
| Exploit-based | Cross-version exploit execution in Java libraries [2603.25997] | Reproduced exploit behavior across version history |
| Exact version-query ground truth | OSV-derived package-version tuples [2604.21111] | Query exact \((e,c,v)\) 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 [2509.03876]. 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** [2408.07321]. 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 [2408.07321]. 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 \(V_v = V_i - V_p\), where \(V_i\) are version tags reachable from the vulnerability-introducing commit and \(V_p\) 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 [2408.07321]. 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 [2509.03876].

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 [2309.01971]. 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 [2602.12500]. 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 [2509.15777]. 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 [2604.24398].

## 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%** [2603.25997]. 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 [2210.07482]. 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 [2102.08172]. 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** [2603.18693]. 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 [2606.25863]. 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** [2509.03876]. 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 [2408.07321]. 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 [1302.4133]. 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 [2408.07321]. 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 \((e,c,v,u)\) and builds them by enumerating exact package versions from registries, querying OSV for each version, and normalizing returned identifiers [2604.21111]. 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 [2509.03876]. 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 [2408.07321]. 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 [2603.25997]. 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 [2603.18693]. A product version may be labeled affected while only a small set of compile-time variants are actually exposed [2606.25863]. A dependency may be reported vulnerable at crate or package level while the actually resolved version graph excludes the flaw [2210.07482]. 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**” [2509.03876]. 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.

Source: https://www.emergentmind.com/topics/vulnerability-affected-versions-identification