One Is Not Enough: The Untold Story of Multiple Security Patches for One Vulnerability

1 Introduction

• A vulnerability may need successive patches for overlooked cases or newly exposed vectors, or distinct patches across maintained versions and related repositories.Incomplete records can leave attack surfaces exposed, delay patch deployment, or encourage patch porting across incompatible contexts.Source: §1 · p. 2
• Existing approaches rank commits, trace links, or use surface-level signals to group patches, but do not model deeper semantic dependencies among SPs.The paper argues that understanding why multi-SP vulnerabilities arise and how patches relate is essential for improving patch coverage.Source: §1 · p. 2
• After manual ground-truth verification, SPectre achieves 0.927 recall for same-repository cases and 0.873 recall for cross-repository cases, recovering additional related patches beyond representative ranking-based baselines.The study also reports 28 previously unreported SPs across recent CVEs.Source: §1 · p. 2
• The study merges four vulnerability databases, analyzes semantic relationships among patches, and derives a two-level taxonomy with 6 categories and 16 sub-categories.It operationalizes these findings in SPectre and evaluates patch discovery against existing baselines.Source: §1 · p. 2

2 Background and Research Problem

• A Security Patch (SP) is a code commit that fixes a vulnerability, as often referenced in vulnerability databases.A Multi-SP Vulnerability is a disclosed vulnerability explicitly associated with more than one SP in vulnerability databases.Source: §2 · p. 2
• The study asks how prevalent multi-SP vulnerabilities are, why one CVE corresponds to multiple SPs, and whether empirical insights support identifying related patches.It also asks whether unreported SPs can be discovered for recent CVEs.Source: §2 · p. 2

3 Data Collection Methodology

• The authors merged and deduplicated SP records per CVE across four vulnerability databases to construct SPDB.The four-source collection extends a prior multi-SP dataset that used NVD and Snyk.Source: §3 · pp. 2–3
• The collection covered CVE entries and references from 2005 to 2026, extracting links that contained “commit” and a commit hash.The sources were NVD, Snyk, GHSA, and OSV.Source: §3 · p. 2
• 6,053 multi-SP CVEs—20.6% of 29,445 collected CVEs with SPs—were associated with 16,260 SPs in the resulting dataset.CVEs with one SP were filtered out; the multi-SP dataset is named SPDB.Source: §3 · p. 3

4 Empirical Study

• RQ1 asks how prevalent multi-SP vulnerabilities are in existing vulnerability databases, while RQ2 asks why one vulnerability is associated with multiple SPs.Source: §4 · p. 3
• RQ3 asks to what extent the empirical findings support effective identification of multiple SPs.Source: §4 · p. 3
• RQ4 asks whether SPectre can find unreported SPs for recent CVEs.Source: §4 · p. 3

• The top-10 CWE lists share 8 entries; resource-throttling and authorization enter only the multi-SP list, unlike out-of-bounds read and SQL injection.Source: Figure 2 · p. 3, §4.1 · p. 3
• 20.6% of CVEs with SPs involve multiple SPs, rising from 15.9% in 2020 to 24.5% in 2024.Source: §4.1 · p. 3
• 64.4% of multi-SP CVEs have exactly two SPs, while 6.7% have five or more.Source: §4.1 · p. 3, Figure 3 · p. 4
• 36-55% more multi-SP CVEs are recognized after merging four databases than by any single source.NVD shows the largest gain, at +55.1%.Source: §4.1 · p. 3, Table 1 · p. 4

4.2 RQ2: Reasons of Multi-SP Phenomenon

• For 4,208 multi-SP CVEs from 2005–2024, each date-ordered consecutive patch pair asks why the later SP remains necessary after the earlier one.The resulting 6,809 patch pairs are the unit of analysis.Source: §4.2.1 · p. 4

4.2.1 Taxonomy Construction.

• LLM-assisted card sorting yielded 62 candidate sub-categories, then authors consolidated them by patch scope and semantic distinctness into 6 categories and 16 sub-categories.Source: §4.2.1 · p. 4, §4.2.2 · p. 4

4.2.2 Taxonomy Overview.

• Version-control artifacts duplicate fixes (816 CVEs); other pairs include non-security commits and dataset noise.Source: §4.2.2 · p. 6

4.2.3 Reliability Validation.

• Two authors classified 200 patch pairs with Cohen’s κ of 0.95; adjudication yielded 96.0% precision (192/200).Source: §4.2.3 · p. 6

4.2.2 Taxonomy Overview.

• 6 categories and 16 sub-categories organize multi-SP reasons; cross-branch fixes dominate (1,645 CVEs, 39.09%), followed by same-branch fixes (1,382 CVEs, 32.84%).Source: §4.2.3 · p. 6
• Same-branch fixes (1,382 CVEs, 32.84%) include incomplete, incorrect, and staged fixes; incomplete fixes leave part of the attack surface exposed.Source: §4.2.2 · pp. 4–5, §4.2.3 · p. 6
• Cross-branch porting is dominant (1,645 CVEs, 39.09%); cross-repository fixes affect 454 CVEs across components, dependencies, mirrors, versions, forks, and independent implementations.Source: §4.2.2 · p. 5, §4.2.3 · p. 6

4.3.1 Design of SPectre.

• SPectre organizes discovery into seed intelligence, multi-phase candidate discovery, and LLM-agent determination, guided by same-branch, cross-branch, and cross-repository taxonomy categories.Only candidates receiving a positive determination are retained; uncertain and negative candidates are excluded.Source: §4.3.1 · pp. 6–7
• Seed intelligence gathers commit leads from vulnerability references, resolves pull requests, and searches repository history for CVE mentions, filtering non-code-only changes.The tool focuses on commits that modify source files, excluding documentation-, test-, build-configuration-, and lock-file-only changes.Source: §4.3.1 · p. 6
• Candidate discovery searches same-branch, cross-branch, and related repositories using signals such as commit-message similarity, cherry-picks, shared issue identifiers, and overlapping code changes.For cross-repository searches, SPectre uses previously observed repository relationships or falls back to fork-related repositories.Source: §4.3.1 · pp. 6–7
• The LLM agent applies scenario-specific taxonomy criteria and exclusion rules, retaining a candidate only when positive evidence links it to the seed patch and target CVE.Temporal proximity, shared authorship, overlapping files, or similar bug class alone are insufficient evidence of a shared CVE.Source: §4.3.1 · p. 7

4.3.2 Effectiveness Evaluation of SPectre.

• The evaluation sampled 300 multi-SP CVEs and manually validated 719 ground-truth patches after reviewing 800 candidates.Two authors independently reviewed candidates (Cohen’s κ=0.945), with disagreements resolved by a third author.Source: §4.3.2 · p. 8
• Manual review confirmed 335 previously unrecorded patches, including 315 discovered by SPectre; 206 of the missing patches were cross-repository fixes.Cross-repository fixes accounted for 61.5% of the 335 additions.Source: §4.3.2 · pp. 8, 10, Table 4 · p. 9
• After manual ground-truth expansion, SPectre achieves 0.927 same-repo recall and 0.873 cross-repo recall, exceeding every baseline at K=50.SPectre's recall and precision on same-repo cases rise from 0.910 to 0.927 and 0.510 to 0.725, respectively.Source: §4.3.2 · p. 9, Table 2 · p. 9
• SPectre still misses 90 verified patches, and 92% of these never enter its candidate pool because observable links to the seed are lacking.Only 8% of missed patches are generated as candidates but rejected during LLM determination.Source: §4.3.2 · p. 9

4.4 RQ4: Discovering Unreported Multiple SPs

• Manual review confirmed 28 previously unreported security patches across 20 of 100 recent single-patch CVEs, or 20% of the sample.SPectre identified 48 candidates across 25 CVEs; 28 candidates were confirmed as genuine security patches.Source: §4.4 · p. 10
• The authors caution that the 20% sample result likely underestimates prevalence because follow-up patches for early-2026 disclosures may not yet have been released.Source: §4.4 · p. 10
• Of the confirmed unreported patches, 89.28% were same-branch fixes that further hardened the vulnerability fix.The paper notes that applying only a database-recorded patch often leaves residual attack surface unaddressed.Source: §4.4 · p. 10

5.1 Threats to Validity

• The merged dataset may still contain incorrect patch links and omit valid ones, and the study focuses on GitHub-hosted commit links.Only 3.3% of collected multi-SP CVEs had patches exclusively outside GitHub, but platform-specific distribution shifts cannot be ruled out.Source: §5.1 · p. 10
• SPectre can miss patches without observable candidate-discovery evidence, while repository relations absent from its learned table may also be missed.The authors found 3.0% of patch pairs lacked strong observable patterns; disabling the repository-relation table affected 7 of 61 CVEs and reduced recall and precision by 5.5 and 1.2 percentage points.Source: §5.1 · p. 10

5.2.1 Lesson 1: Missing Recorded Patches for Multi-SP CVEs Are Dangerous.

• Unlinked corrective or branch-specific patches can obscure the full fixing scope, delay deployment, and leave downstream users with a patch unsuitable for their software.This includes incomplete or incorrect fixes and fixes needed in another branch or repository.Source: §5.2.1 · p. 10

5.2.2 Lesson 2: Effective Multi-SP Tracing Needs Relation-Aware and Cross-Source Analysis.

• CVE-to-commit relevance alone is insufficient; accounting for relations across time, branches, and repositories can improve tracing effectiveness.The discussion identifies temporal proximity, commit-message similarity, and overlapping code changes as useful relation-aware signals.Source: §5.2.2 · p. 10

5.2.3 Lesson 3: Directions for Community and Ecosystem Enhance-

• Because no single vulnerability database comprehensively covers multi-SP CVEs, the authors call for coordinated, standardized metadata linking related commits and describing how vulnerabilities are fixed.They also recommend balancing recall gains from larger top-K lists against their added manual-validation cost.Source: §5.2.3 · pp. 10–11

6.1 Empirical Study of Patch Management

• Prior patch-management studies cover latency, propagation, effectiveness, automation, and fork coordination, but do not systematically examine multi-SP prevalence and causes.The resulting taxonomy guides SPectre in discovering comprehensive SP sets for a CVE.Source: §6.1 · p. 11

6.2 Tracing Security Patches for Disclosed Vulnerabilities

• Earlier SP-localization work ranks candidate commits using handcrafted signals,,,, [49], while newer methods add PLMs/LLMs and contextual cues, [10], [16],, [50],,.These approaches typically identify SPs for a disclosed vulnerability by ranking candidates.Source: §6.2 · p. 11
• SPV locates branch variants from a known reference SP, while SHIP models multiple commits but treats their scenarios uniformly and relies on surface similarities and ranking.SHIP does not distinguish the different scenarios in which multiple SPs arise for one vulnerability.Source: §6.2 · p. 11
• The paper instead uses a two-level taxonomy to guide SPectre: candidate-discovery patterns bound the search without a top-K cutoff, and an LLM-Agent judges whether candidates are genuine SPs.Existing ranking-based approaches lack a principled top-K cutoff that guarantees patch coverage.Source: §6.2 · p. 11

6.3 Identifying Silent Security Patches

• Silent-patch research progresses from neural commit-message, code-difference, and issue models [18] [42] [45] to graph and LLM representations,, [43],, [52], but targets fixes without CVE linkage.That differs from this work's focus on multi-SPs for disclosed CVEs.Source: §6.3 · p. 11

• The two-level taxonomy has 6 categories and 16 sub-categories; the findings call for greater multi-SP awareness among database maintainers, tool builders, and security practitioners.Source: §7 · p. 11