Does CVSS Predict Exploitation? An Empirical Study of the OWASP Top 10:2025

Table of Contents

1. 1. The vocabulary of a vulnerability
2. 2. Methodology & data provenance
3. 3. Original analysis — does CVSS predict impact?
4. 4.1 — A01 Broken Access Control
5. 4.2 — A02 Security Misconfiguration
6. 4.3 — A03 Software Supply Chain Failures (new)
7. 4.4 — A04 Cryptographic Failures
8. 4.5 — A05 Injection
9. 5. Completing the picture — A06–A10
10. 6. The AI / LLM dimension
11. 7. Detection & prevention you can run
12. 8. A note on CVSS v3.1 → v4.0
13. 9. Reproducibility & downloads
14. 10. Appendix — verified score provenance
15. References

1. The Vocabulary of a Vulnerability

One security weakness is named by several overlapping systems; reading any advisory means knowing which is which. Each term below links to its authoritative source:

• OWASP Top 10 — an awareness ranking of the most impactful web-application risk categories.
• CWE — MITRE's dictionary of weakness types (e.g. CWE-89 = SQL Injection).
• CVE — a unique ID for one specific flaw in one specific product, run by the CVE Program.
• NVD — NIST's database that enriches and scores every CVE.
• CVSS — a 0–10 severity score governed by FIRST. 9.0–10.0 = Critical.
• MITRE ATT&CK — a knowledge base of adversary techniques (e.g. T1190).
• GRC frameworks — NIST SP 800-53, ISO/IEC 27001, PCI DSS, and GDPR define the controls and legal obligations that require you to prevent these weaknesses.

2. Methodology & Data Provenance

Category rankings are taken verbatim from the official OWASP Top 10:2025. For each category the crosswalk records the primary CWEs, a representative real-world example, the relevant ATT&CK techniques, and the most directly applicable control from each framework. Every CVSS base score and vector was pulled programmatically from the NVD REST API v2.0 on 2026-07-08 and reflects the NVD primary analysis; vendor/CNA scores are labelled as such. The complete mapping is published as JSON and CSV under CC BY 4.0 (see §9), and the tables on this page are rendered from that same file — so what you read and what you download cannot diverge.

Limitations. The example set is illustrative (n = 5 marquee CVEs), not a statistically powered sample; control mappings cite the most representative clause rather than an exhaustive list; and category-to-technique mappings are interpretive. The dataset ships so others can extend the sample and test the thesis below at scale.

3. Original Analysis — Does CVSS Predict Real-World Impact?

A recurring assumption in vulnerability management is "patch by CVSS, highest first." We test it in two steps: first a motivating illustration (the five marquee CVEs), then an empirical test over the entire population so the conclusion does not rest on a hand-picked sample. Here are the five NVD-verified scores:

*NVD scores 9.8 (Scope Unchanged); Atlassian's CNA scores 10.0 (Scope Changed).

The five sit within a 0.2-point band (9.8–10.0, plus Heartbleed at 7.5), yet their blast radii differ by orders of magnitude — MOVEit (9.8) drove one of the largest data-theft campaigns on record while XZ (10.0) caused almost none because it was caught in time. But five famous CVEs prove nothing on their own: they were selected because they are high-impact, which is precisely the outcome under test. So we run the real experiment.

3.1 — Experiment: does CVSS severity predict realised exploitation?

Design. Population = every CVE carrying a CVSS v3 base severity in the NVD (n = 191,079). Ground-truth exploitation label = membership in the CISA KEV catalog (NVD hasKev). Counts were pulled from the NVD REST API v2.0 per (severity × KEV) cell on 2026-07-09 — the whole population by band, no sampling on outcome.

Overall KEV rate = 0.663% (1,266 / 191,079). Lift = P(exploited | band) ÷ overall rate. χ²(3) = 751.8, p ≪ 0.001.

Result. Severity carries directional signal — Critical CVEs are exploited at 2.37× the base rate, the gradient is monotonic (1.57% → 0.87% → 0.16% → 0.09%), and the association is highly significant (χ²(3) = 751.8, p ≪ 0.001). But as an operational prioritisation filter it is weak on both axes:

• 98.4% of Critical CVEs were never known-exploited — low precision: "Critical" is a poor signal for where to act.
• Patching only Critical misses 62.5% of exploited CVEs — low recall: the plurality of exploited CVEs (51.7%) are rated High, not Critical.

How much signal is that, exactly? We quantify it two ways in §3.3.

3.2 — The exploitation signal already exists: EPSS

The natural objection — "then use an exploitation signal, not severity" — is exactly the founding motivation of FIRST's Exploit Prediction Scoring System (EPSS), which ships a daily per-CVE probability of exploitation. As an illustration, EPSS places all five marquee CVEs at or above the 99.7th percentile despite their CVSS spanning 7.5–10.0:

3.3 — How much signal, exactly? CVSS-AUC vs EPSS-AUC

Two summary statistics, both computed over the full KEV-labelled population, tell a deliberately two-sided story:

• Cramér's V = 0.063 (4×2 severity × exploited) — a near-zero association. Under a 0.66% base rate, association measures are dominated by class imbalance.
• ROC-AUC sidesteps imbalance by measuring rank-discrimination (the probability an exploited CVE outranks a random non-exploited one). CVSS severity-banded AUC = 0.70; EPSS probability AUC = 0.947 over 346,176 CVEs (all 1,635 KEV entries covered).

Reading them together resolves the apparent tension: CVSS severity does rank an exploited CVE above a non-exploited one about 70% of the time — more than the near-zero Cramér's V alone implies, the two diverging precisely because of the imbalance — yet the exploitation-derived EPSS signal is dramatically better (0.95). Censoring recent CVEs (dropping 2025–26 IDs that have not had time to be exploited-and-listed) leaves EPSS-AUC essentially unchanged at 0.948, so it is not a recent-CVE artifact.

Related work. This reproduces, on a fresh 2026 snapshot, a well-established finding: FIRST's EPSS and CISA/CMU's SSVC both exist precisely because base-score severity is a poor proxy for actionable risk. Limitations. (1) KEV is a lower bound on exploitation (curated, US-centric, lags disclosure), so precision is conservative. (2) Right-censoring: recent CVEs have not had time to be exploited-and-listed — addressed by the ≤2024 sensitivity check above. (3) The CVSS-v3 filter structurally excludes pre-2016 CVEs, and CVSS-AUC is banded (four ordinal levels), not continuous. (4) EPSS-AUC reflects encoded, not forecast, exploitation (see §3.2 caveat). Full figures, the χ² and AUC computations, and both data pulls are in the downloadable kev-cvss-analysis.json, auc_results.json, and scripts kev_experiment.py / auc_experiment.py (see §9).

4. The Five Highest-Ranked Risks

4.1 — A01:2025 Broken Access Control

Ranked #1 for the second edition running, A01:2025 means the application fails to enforce what an authenticated user is allowed to do. In 2025 it also absorbed Server-Side Request Forgery (CWE-918). Typical failures: reading another user's record by changing an ID in the URL (IDOR, CWE-639), reaching admin functions without admin rights (CWE-862), or forcing the server to make requests on the attacker's behalf. Attackers operationalise this via ATT&CK T1548 and T1068. It is governed by NIST 800-53 AC-3/AC-6, ISO 27001 A.5.15, PCI DSS Req. 7, and GDPR Art. 25.

CWE-284CWE-862CWE-863CWE-639CWE-918

4.2 — A02:2025 Security Misconfiguration

Climbing to #2, A02:2025 covers systems insecure not because of a coding bug but because of how they are set up — default credentials, verbose errors, permissive cloud storage, over-broad IAM. The canonical case is the 2019 Capital One breach: a misconfigured web application firewall was abused via SSRF to reach the cloud instance metadata service (ATT&CK T1552.005), steal credentials, and exfiltrate ~106 million records. Because it is an incident and not a catalogued CVE, it has no CVSS score — a distinction worth keeping precise. Controls: NIST 800-53 CM-6/CM-7, ISO 27001 A.8.9, PCI DSS Req. 2, and hardening baselines from the CIS Benchmarks.

CWE-16CWE-1188CWE-732

4.3 — A03:2025 Software Supply Chain Failures (NEW)

A brand-new, expanded category for 2025 (evolving from "Vulnerable and Outdated Components"), A03:2025 covers risk you inherit from everything you did not write: open-source libraries, transitive dependencies, build tooling, and CI/CD. It maps to ATT&CK T1195 (Supply Chain Compromise) and to NIST CSF 2.0 GV.SC, NIST SSDF (SP 800-218), ISO 27001 A.5.19–A.5.22, PCI DSS Req. 6.3.2, and GDPR Art. 28. Assurance frameworks that directly address it include SLSA and machine-readable SBOMs (SPDX / CycloneDX). Two exhibits — a known-vulnerable dependency and a maliciously planted backdoor:

CWE-1104CWE-506CWE-1357

4.4 — A04:2025 Cryptographic Failures

A04:2025 (formerly "Sensitive Data Exposure") is about protecting data in transit and at rest. The failure is usually not broken math but broken usage — no encryption, outdated algorithms (CWE-327), cleartext transmission (CWE-319), or hard-coded secrets (CWE-259). Attackers harvest via ATT&CK T1040 (Network Sniffing) and T1557 (Adversary-in-the-Middle). Controls: NIST 800-53 SC-8/SC-13/SC-28, ISO 27001 A.8.24, PCI DSS Req. 3 & 4, and GDPR Art. 32(1)(a) (encryption & pseudonymisation). Heartbleed is the archetype — and a useful reminder that a data-exposure flaw can be "only" 7.5 yet catastrophic:

CWE-327CWE-319CWE-259CWE-331

4.5 — A05:2025 Injection

Once the reigning #1, A05:2025 now sits at #5 — not because it disappeared, but because parameterised queries and frameworks made it easier to prevent. It still occurs whenever untrusted input is interpreted as a command: SQL (CWE-89), OS commands (CWE-78), and cross-site scripting (CWE-79). Exploited via T1190 and T1059, sometimes dropping a web shell (T1505.003). Governed by NIST 800-53 SI-10, ISO 27001 A.8.28, and PCI DSS Req. 6.2.4. The MOVEit campaign shows why a 9.8 in ubiquitous software beats a 10.0 in something rare:

CWE-89CWE-79CWE-78CWE-94

5. Completing the Picture — A06 through A10

Honest scope matters: the five above are the highest-ranked, but the list has ten. Below is the rest of the 2025 list, rendered from the same dataset. Note the second brand-new 2025 entry — A10 Mishandling of Exceptional Conditions — and the renamed A07 and A09.

6. The AI / LLM Dimension

Any 2026-relevant reading of these risks has to account for AI. Two forces are reshaping the list. First, AI-generated code re-introduces classic weaknesses at scale: assistants readily emit string-concatenated SQL (CWE-89), missing authorization (CWE-862), and weak crypto defaults, so A01, A04, and A05 re-surface in freshly-written code. Second, the model supply chain — pulled weights, unvetted model packages, and poisoned datasets — extends A03 Software Supply Chain Failures into the ML pipeline.

These are catalogued in their own right by the OWASP Top 10 for LLM Applications (e.g. prompt injection, insecure output handling, supply-chain and data poisoning for models) and by NIST's AI Risk Management Framework (AI RMF). For agentic systems that write and execute code, A05 Injection and A08 Integrity Failures converge: untrusted model output becomes an execution path. The practical takeaway — treat model output as untrusted input, and treat model artifacts as supply-chain dependencies.

7. Detection & Prevention You Can Run

Research should be reproducible at the defensive layer too. Each rule below ships as a runnable file, and the Semgrep rule ships with a semgrep --test fixture (true- and true-negative lines) so the "you can verify this" claim is literally checkable. Downloads: sqli.yaml · log4shell.yml · imds_ssrf.yml. Sigma ids are valid UUIDs (v4), so they pass sigma check / pySigma validation.

7.1 — Semgrep: SQL injection sink (A05, CWE-89)

rules:
  - id: python-sqli-string-concat
    languages: [python]
    severity: ERROR
    message: >
      Possible SQL injection (OWASP A05:2025 / CWE-89): SQL built by string
      formatting or concatenation. Use parameterised queries instead.
    metadata:
      owasp: A05:2025-Injection
      cwe: CWE-89
      references:
        - https://cwe.mitre.org/data/definitions/89.html
    patterns:
      - pattern-either:
          - pattern: $CUR.execute("..." % ...)
          - pattern: $CUR.execute("..." + $X)
          - pattern: $CUR.execute(f"...{$X}...")

7.2 — Sigma: Log4Shell JNDI exploitation (A03, CVE-2021-44228)

title: Possible Log4Shell JNDI Exploitation Attempt (obfuscation-tolerant)
id: 99cf5ad3-8cea-4c54-9ac3-30bc81d5b93b   # valid UUIDv4
status: experimental
description: Detects JNDI lookups incl. common Lookup-based obfuscations.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2021-44228
  - https://attack.mitre.org/techniques/T1190/
tags: [attack.initial_access, attack.t1190]
logsource:
  category: webserver
detection:
  jndi_plain:
    c-uri|re: '(?i)\$\{jndi:(ldap|ldaps|rmi|dns|nis|iiop|corba|nds|http)s?:'
  jndi_obfuscation_tokens:      # ${${lower:j}ndi...}, ${::-j}, ${env:...}
    c-uri|contains:
      - '${${'
      - '${lower:j'
      - '${upper:j'
      - '${::-j}'
      - '${env:'
      - '${sys:'
  condition: jndi_plain or jndi_obfuscation_tokens
level: high

Full coverage of arbitrarily-nested ${...} Lookups requires normalising the string before matching; this rule flags the tell-tale indicators, which is the pragmatic approach real Log4Shell rules took.

7.3 — Sigma: cloud metadata SSRF (A02 — the Capital One pattern, T1552.005)

title: Access to Cloud Instance Metadata Service via SSRF
id: 029b4967-bbf0-4716-8d75-b7e3ea8b4020   # valid UUIDv4
status: experimental
description: Flags application-originated requests to the IMDS endpoint.
references:
  - https://attack.mitre.org/techniques/T1552/005/
tags: [attack.credential_access, attack.t1552.005]
logsource:
  category: proxy
detection:
  selection:
    c-uri|contains:
      - '169.254.169.254'         # AWS/Azure/GCP IMDS (IPv4)
      - '[fd00:ec2::254]'         # AWS IMDS (IPv6)
      - 'metadata.google.internal'
  condition: selection
level: high

8. A Note on CVSS v3.1 → v4.0

Every score in this paper is CVSS v3.1, because that is what the NVD primary analysis records for these CVEs. CVSS v4.0 (released by FIRST in late 2023) is now being adopted: it refines the base metrics, replaces the single Scope flag with explicit Vulnerable-system and Subsequent-system impact metrics, and adds Supplemental and Threat groups. That change is directly relevant to §3: v4.0's split impact metrics partially address the "one Boolean decides 9.8 vs 10.0" problem — but it still scores severity, not incidence, so the thesis stands. Mixing v3.1 and v4.0 numbers without labelling them is a common and misleading error; this paper avoids it by quoting v3.1 throughout.

9. Reproducibility & Downloads

The artifacts below are the original contribution of this page. All are released under CC BY 4.0 and are the same source of truth that renders the tables above — so the paper and its data cannot diverge. Everything in §3 is re-runnable from the two scripts.

Detection rules ship separately as runnable files: sqli.yaml (+ test fixture), log4shell.yml, imds_ssrf.yml. Load the ATT&CK layer at MITRE ATT&CK Navigator → "Open Existing Layer" → "Upload from local".

10. Appendix — Verified Score Provenance

Source: NVD REST API v2.0, retrieved 2026-07-08. Scores are the NVD primary (nvd@nist.gov) analysis unless noted.

References

1. OWASP Top 10:2025 — Open Worldwide Application Security Project (built from 175,000+ CVEs & 589 CWEs).
2. NIST National Vulnerability Database and NVD REST API v2.0.
3. MITRE CWE and MITRE ATT&CK.
4. FIRST CVSS — v3.1 and v4.0 specifications.
5. NIST SP 800-53 Rev.5, SSDF (SP 800-218), CSF 2.0.
6. ISO/IEC 27001:2022; PCI DSS v4.0; GDPR.
7. OWASP Top 10 for LLM Applications; NIST AI RMF.
8. CISA Known Exploited Vulnerabilities Catalog; SLSA.
9. FIRST EPSS (Exploit Prediction Scoring System) and CISA/CMU SSVC — prior art establishing that base-score severity is a weak proxy for actionable risk. Reproduction script: kev_experiment.py.