PaperlayerView exact revision on arXiv

Source-linked AI summary

GitHub Engagement Signals for CVE Prioritization: The GitHub Popularity Metric (GPM)

Jafar Akhoundali, Kristian Rietveld, Olga Gadyatskaya

arXiv:2609.31004v1cs.CR

TL;DR

Prioritizing likely exploited vulnerabilities is an important challenge. The paper proposes GPM, a metric based on the popularity of CVE exploits on GitHub. It reports predictive signals and overlooked CVEs, while noting that coverage is limited.

  • Problem

    Prioritizing vulnerabilities likely to be exploited is an important problem.

    Source: §8 · p. 25

  • Method

    GPM prioritizes vulnerabilities using the popularity of CVE exploits published on GitHub.

    Source: §8 · p. 25

  • Results

    GPM is reported as predictive rather than reactive and offers insights into important CVEs potentially overlooked by vulnerability lists such as CISA KEV.

    Source: §1 · p. 2, §8 · p. 25

  • Takeaways & Limitations

    GPM was incorporated into EPSS version 5 with modifications.

    Source: §8 · p. 25

    GPM coverage is limited: only 2.5% of CVEs have proof-of-concept repositories on GitHub.

    Source: §7 · p. 24

Abstract

from arXiv · show

Attackers can compromise multiple systems with a single vulnerability, while defenders need to fix all security weaknesses in their systems. This asymmetry puts defenders at a disadvantage. Security vulnerabilities are found at an alarming rate, and patching vulnerabilities is costly and time-consuming; thus, vulnerability prioritization is a must and a time-critical challenge. Many prioritization metrics, such as the CVSS, EPSS, KEV, and SSVC, are currently used, each with different pros and cons, such as openness, degree of automation, time-criticality, coverage, and need for expert input. In this work, we propose the GitHub Popularity Metric (GPM), a fully open, publicly computable prioritization metric based on the popularity of exploits in GitHub repositories. We use GitHub features such as the number of stars, forks, and related unique users to create a metric that indicates the popularity of CVEs across different time frames, both relative to the current time and historically. We compare the proposed metric with various existing vulnerability prioritization metrics and known exploited vulnerabilities and demonstrate that it provides tangible insights for defenders, identifying unique CVEs and inconsistencies in existing methods. The GPM was integrated into the EPSS version 5. \noindent\textbf{Note.} A demonstration based on this work has been accepted to the demo track of the ACM Conference on Computer and Communications Security (CCS) 2026.

1 Introduction

Because defenders must triage costly patching while vulnerabilities differ in exploitability, prioritization is time-critical. The introduction presents GPM as an open, numeric signal from public GitHub exploit repositories and reports predictive value alongside established approaches.

1 Introduction

  • CVSS has been criticized for requiring substantial expert effort and for inconsistent scores, while not correlating with vulnerabilities exploited in the wild.The same person may assign different scores months apart.Source: §1 · pp. 1–2
  • EPSS may underestimate exploitation probability and uses some nontransparent data sources, while exploited-vulnerability lists can be delayed by manual work.The introduction also notes restrictions that have diminished social-media exploitation signals.Source: §1 · p. 2
  • GPM measures CVE popularity through interactions with public GitHub repositories hosting exploit proof-of-concept code, using historical data to produce a numeric value.The metric relies on publicly available GitHub data and can be computed by anyone for free.Source: §1 · p. 2
  • The authors frame GPM as a complementary prioritization signal that can improve patch management and expose critical exploited CVEs overlooked by other sources.They also report that it proposes tangible improvements to SSVC.Source: §1 · p. 2
  • The paper compares GitHub exploit popularity with other platforms, exploit-publication timing, known exploited CVEs, and established prioritization approaches.Its questions also ask whether GPM identifies overlooked CVEs and what advantages and disadvantages it has relative to existing approaches.Source: §1 · p. 2
  • GPM is reported as predictive rather than reactive to CISA KEV additions, aligns strongly with EPSS, and identifies unique CVEs not visible in other reputable sources.The authors also report that the work was merged into EPSS version 5 with modifications.Source: §1 · pp. 2–3

2 Background and Related Work

This section surveys public vulnerability and exploit data and established exploitation signals for CVE prioritization, noting their limitations and positioning GPM as a public measure of GitHub engagement over time. It also reports additional exploited CVEs identified through threat-intelligence review.

2.1 Vulnerabilities and Exploits

  • 94,568 of 332,207 CVEs were marked “DEFERRED” in the NVD, and 975 remained under review while 28,394 awaited analysis.NIST also announced it would limit enrichment to KEV-listed CVEs, federal-government software, and critical software.Source: §2.1 · p. 3
  • GitHub has become a popular public venue for sharing exploits, which can help defenders develop patches while exploit repositories and tools remain available.The paper considers publicly available data because access to private exploit evidence is challenging.Source: §2.1 · p. 4

2.2 Reputable CVE Prioritization Sources

  • CVSS does not incorporate rich exploitation data, and its exploitability sub-score had maximum precision of about 0.19, with over 80% of flagged vulnerabilities never exploited.The passage notes that CVSS v4.0 adds an exploit-maturity metric, but it has not yet seen widespread adoption.Source: §2.2 · p. 4
  • EPSS predicts exploitation probability for the next 30 days, but its pipeline data are not fully public, its model is a black box, and it does not account for exploit popularity [15].Its evidence is constrained by manual reports, honeypots, detection rules, and a bias toward network attacks; it also applies only to fully accepted, published CVEs.Source: §2.2 · pp. 4–5
  • CISA KEV covers only 1,513 CVEs, is updated manually with possible weekend delays, and provides binary membership rather than a ranking.VulnCheck KEV covers 4,599 CVEs but is a private, nontransparent data source.Source: §2.2 · p. 5
  • CVE descriptions often lack exploitation details [47] [48] [49].The supplied passage introduces SSVC but does not describe its approach or findings.Source: §2.2 · p. 5
  • SSVC provides information on exploit availability and evidence of exploitation, while OTX pulses can connect community threat intelligence to specific CVEs.OTX is a free, community-driven threat-intelligence platform.Source: §2.2 · p. 5
  • Manual review of available OTX pulses for CVEs with GitHub exploits found 14 exploited CVEs absent from KEVs as of Aug 2025.The authors collected available pulses for these CVEs and checked them manually.Source: §2.2 · pp. 5–6
  • The authors lacked access to Shadowserver and GreyNoise data and received no response to a request for artifacts from the expected exploitability study.The unavailable threat-intelligence sources include public scanning and notification data and actionable insights.Source: §2.2 · p. 6

2.3 Related Work

  • Prior work used such models as early signals and sources to identify vulnerabilities exploited in the wild [17] [21].After X deleted its free API tier, social-media visibility fell; free authenticated users can search GitHub repositories for actionable insights in reasonable time with optimizations, though rate limits apply.Source: §2.3 · pp. 6–7
  • GPM uses GitHub repository engagement dynamics as a continuous, time-varying popularity signal, rather than binary PoC availability or signals combined from private sources.This distinction contrasts with LEV’s PoC-based exploitability prediction and approaches combining social media, GitHub, dark-web, and CVSS signals.Source: §2.3 · p. 7
  • GitHub exploit-code repositories exceed ExploitDB and Metasploit in coverage, real-world exploits, and timeliness, while those sources emphasize credibility and trustworthiness and GPM focuses on popularity.GitHub mining also faces fake exploits; a star classifier achieved 96% precision but 27% recall.Source: §2.3 · p. 7

3 Dataset

This section assembles the data sources and collection pipeline, then analyzes exploit-sharing platforms and the timing of GitHub exploits relative to CVE publication.

3.1 Data Sources

  • The dataset combines MITRE cve.org CVEs and GitHub exploit repositories with NVD, KEV variants, Metasploit, Nuclei, Exploit-DB, OTX, ransomware, and daily EPSS data.The authors included CVEs with different publication statuses, since CVE publication can be delayed and CVEs may sometimes be incorrectly rejected.Source: §3.1 · p. 8

3.2 Data Collection

  • To address GitHub Search API's 1,000-result cap, the collection process recursively partitioned searches by repository creation-date boundaries.Queries used the exact phrase “CVE-{YEAR}-” with fork:false; CVE IDs were sought in repository title, description, topics, and README.Source: §3.2 · pp. 8–9
  • By default, GPM metric calculation and evaluation considered only repositories mentioning a single CVE, because the contribution of each CVE to repository popularity is ambiguous.Source: §3.2 · p. 9

3.3 Data Analysis

  • The collection identified 19,572 GitHub repository references and 8,453 unique CVEs with GitHub exploit repositories, approximately 2.5% of all CVEs.Of 19,572 repositories, 19,024 (97.20%) were associated with exactly one CVE.Source: §3.3 · p. 9
  • GitHub became the leading CVE exploit-sharing source from 2018 onward, after Exploit-DB dominated from 2006–2010; only 2.5% of CVEs have a public GitHub exploit.The platform shift is reflected in 28,330 of 59,504 exploit-tagged references (48%) for CVEs issued between 2018 and 2025.Source: §3.3 · p. 10
  • The authors combined mined GitHub exploit repositories with CVE references and categorized GitHub links to examine where exploits are shared.They describe files, issues, and repositories as three major locations for sharing exploits.Source: §3.3 · pp. 11–12
  • The median lag between CVE publication and the first related GitHub exploit was 6 days in 2023 and 2024, then 1 day in 2025.The section reports that the gap between exploit availability and CVE publication narrows each year.Source: §3.3 · p. 12
  • A manual review of 200 repositories found a 1% noise ratio, and the authors conclude that the collection largely reflects CVE-related content and can indicate interest in particular CVEs.Two reviewed repositories contained CVE typos; the remaining reviewed cases included removed repositories and suspicious code.Source: §3.3 · p. 13

4 The GitHub Popularity Metric (GPM)

The GitHub Popularity Metric (GPM) counts distinct GitHub users interacting with repositories linked to a CVE. The paper evaluates threshold-based use of this metric and compares exploit popularity before and after CISA KEV inclusion.

4.1 The GPM Metric Definition

  • Distinct user identifiers interacting with a CVE-linked repository define its popularity, with each user counted at most once regardless of interactions or repositories.The default analysis limits repositories to associations with one CVE and includes repositories created after the corresponding CVE.Source: §4.1 · p. 13

4.2 Evaluation Metrics

  • A GPM threshold of 12 yields the best F1 score; historical thresholds from 12 to 27 produce only a consistently small performance drop.The authors report that F1 remains robust despite the range of optimal thresholds.Source: §4.2 · p. 14, Table 3 · p. 15

4.3 Exploit Popularity vs Addition to KEV

  • CVEs known to be exploited have noticeably higher GPM scores than CVEs not flagged as exploited.The comparison is based on GPM scores for KEV CVEs versus other CVEs.Source: §4.3 · p. 15
  • Exploit repositories for known exploited CVEs tend to be more popular, and GPM popularity shows no increase after CISA KEV addition.The authors conclude that GPM can serve as an independent predictive signal for exploited CVEs without post-treatment bias.Source: §4.3 · pp. 16–17

5 Coverage and Insights from thw GPM

GPM adds CVEs not covered by other sources and its scores align with EPSS and CVSS patterns. The comparison with SSVC also relates GPM ranking to SSVC exploitability and technical-impact fields.

5 Coverage and Insights from thw GPM

  • GPM identifies 658 CVEs with scores of at least 12 that are absent from the other datasets, while each source contributes unique CVEs.Only 193 CVEs appear across all sources, indicating that no single source covers the full set.Source: §5 · p. 17, Figure 8 · p. 19
  • GPM is significantly correlated with EPSS version 3 in 95.2% of cases and version 4 in 89.4% of cases.About 60% of samples were excluded because EPSS or GPM data were too sparse for rank correlation, or a variable was constant.Source: §5 · p. 20, Table 8 · p. 21
  • In the GPM-based ranking, SSVC Exploitability is the most important factor and Technical Impact serves as a tie-breaker; Automation shows no meaningful correlation.The compared CVEs were sorted by mean GPM interaction count, and the SSVC decision tree used generally available fields.Source: §5 · p. 21

6 Case Studies

Case studies show GPM signals associated with exploited CVEs, including some initially rejected or unpublished CVEs. The reported examples and timing comparisons indicate that GitHub exploit signals can precede CVE publication.

6 Case Studies

  • CVE-2023-44976 had GPM 117, and a ransomware group used it on the CVE publication day before MITRE published it on 2025-08-01.The paper reports that the researchers provided MITRE with reports and the GitHub repository.Source: §6 · p. 22
  • CVE-2022-38694, the most popular rejected-status CVE in the dataset, had GPM 496 before it was published on 2025-09-01.The authors requested an update from MITRE on 2025-08-26.Source: §6 · p. 22
  • The authors conclude that GPM can flag important vulnerabilities before common security software that relies on published CVEs is aware of them.They report that GPM can identify exploited CVEs overlooked by existing sources, sometimes providing earlier signals.Source: §6 · pp. 22–24
  • For 1,603 CVEs, a public GitHub exploit was available at least one day before CVE publication, and for 561 it appeared on the publication date.The paper notes that its 359 unpublished CVEs were unpublished at the time of writing.Source: §6 · p. 23

7 Discussion

The GPM offers a public, automated signal that can flag important CVEs earlier than some existing sources, but its GitHub dependence limits coverage and introduces data and service constraints. Its results also informed integration into EPSS version 5, with modifications.

7 Discussion

  • The GPM is free and publicly available, has high correlation with KEV CVEs, and can complement other CVE scoring methods such as EPSS.It was integrated into EPSS version 5 after the authors shared their dataset and metric description with the EPSS team.Source: §7 · p. 24
  • Only 2.5% of CVEs have GitHub PoC repositories, and decentralized hosting means the GPM cannot guarantee that every CVE is represented.The paper identifies low CVE coverage as the metric’s key disadvantage.Source: §7 · p. 24
  • The EPSS-integrated GPM counts total stars, forks, and watches without accounting for unique users.The authors attribute this change to technical reasons.Source: §7 · p. 24
  • The GPM can flag important CVEs early using public data, with predictive rather than reactive value and less lag for defenders than KEV.Unlike KEV, it is not limited to manual human verification.Source: §7 · p. 24
  • The KEV evaluation used 4,610 exploited CVEs, compared with 12,243 in the EPSS paper, and the authors note that the GPM threshold can change.The study also could not systematically use AlienVault OTX as a KEV source, leaving its included CVEs limited and creating false negatives.Source: §7 · p. 24
  • Private exploits, unexamined sources, and exploitation before CVE publication can leave cases unobserved or make the GPM lag, as with KEV and EPSS.The authors also note that vulnerabilities may be exploited before receiving a CVE.Source: §7 · p. 24
  • Public GitHub data may include irrelevant repositories, malware, fake exploits, or fake stars, and some repositories provide a PoC rather than a working exploit.The authors report relatively low noise in a random sample but say it cannot be fully eliminated; a single user can increase the GPM by at most one point.Source: §7 · pp. 24–25
  • GitHub’s change preventing checks of which user IDs starred a repository may alter results when newer GPM data are calculated without unique users.The paper also notes GitHub indexing lag and the possibility of third-party service downtime or instability.Source: §7 · pp. 24–25

8 Conclusions

The paper presents GPM as an open metric based on the popularity of CVE exploits on GitHub. It reports that the metric surfaced CVEs missed by other systems, informed MITRE status changes, and was integrated into EPSS version 5 with modifications.

8 Conclusions

  • GPM measures the popularity of CVE exploits published on GitHub and is open-source, transparent, and free.The authors report that it is independent of known exploited vulnerability lists such as CISA KEV.Source: §8 · p. 25
  • GPM surfaced important CVEs that might be overlooked by other systems, and its insights led MITRE to change several CVE statuses to published.The authors say publication made those CVEs more visible to defenders.Source: §8 · p. 25
  • GPM was merged into EPSS version 5 with modifications.The authors describe the metric as useful to practitioners despite its limited CVE coverage.Source: §8 · p. 25

Ethical Considerations

The authors describe safeguards for research involving public GitHub and vulnerability data, including limiting dataset release. They identify defenders and researchers as potential beneficiaries and assess the additional risk from the GPM service as negligible.

Ethical Considerations

  • To address privacy and potential harms, the authors stored collected data securely and limited its release, including restricting PoC data.They say data sharing with other researchers would be based on individual verified requests.Source: Ethical Considerations · pp. 28–29
  • The authors identify repository owners who are security researchers or defenders as potential beneficiaries of learning about GPM.They describe GPM as an accessible and repeatable prioritization method for third-party system owners.Source: Ethical Considerations · pp. 28–29
  • The authors consider the GPM web service’s additional risk negligible because public exploited-vulnerability sources already exist and GPM does not aid attackers in finding vulnerabilities in third-party systems.They also state that no significant risks to the research team were identified.Source: Ethical Considerations · p. 29
  • The study collected publicly accessible GitHub data and examined properties of hosted exploits without running them or intrusively testing third-party systems.The authors state that no third-party systems were penetration-tested, exploited, or examined intrusively.Source: Ethical Considerations · pp. 28–29

Open Science

The authors outline plans to make GPM usable and reproducible through shared code, controlled dataset access, and a local platform option.

Open Science

  • The authors intend to publicly share source code for collecting data and calculating GPM values.They state that the code allows data collection in a reasonable time.Source: Open Science · p. 29
  • The authors plan to share the dataset with other researchers upon individual verified requests.Source: Open Science · p. 29
  • The authors plan to provide a Docker image for running the GPM platform locally.A screenshot of the platform UI is shown in Figure 11.Source: Open Science · p. 29

Disclaimer

The disclaimer limits use of referenced data-source names and marks to descriptive and identification purposes and disclaims organizational involvement or endorsement.

Disclaimer

  • Referenced data-source names, trademarks, service marks, and logos are used solely for descriptive and identification purposes.Source: Disclaimer · p. 29
  • The respective organizations did not participate in, review, or endorse the work’s preparation, findings, or conclusions.Source: Disclaimer · p. 29
  • Fig. 11 is a web panel based on GPM data.Source: Figure 11 · p. 30
Loading 2609.31004v1…