CVSS v4.0 Exploit Maturity Metrics Are Leading to Artificially Deflated Vulnerability Scores
The CVSS version 4.0 framework introduced by the Forum of Incident Response and Security Teams is shifting how vulnerability severity gets measured across the industry. Under this standard, vendors assign a base severity score representing the technical ceiling of a flaw, which is subsequently adjusted using dynamic threat metrics like exploit maturity. When a vulnerability has no known active exploitation or public proof-of-concept, the calculated threat-adjusted score drops significantly below the base technical score. Security leaders note that this design aims to give vulnerability management teams a standardized method to de-prioritize bugs that currently lack weaponized tooling. However, researcher Kevin Beaumont highlighted that vendors serving as CVE Numbering Authorities, including major players like Cisco, Microsoft, and Palo Alto Networks, can define consumer-oriented threat metrics during initial disclosure. By tagging exploit maturity as 'Unreported' rather than leaving it 'Not Defined'—which historically assumed worst-case conditions—vendors can effectively prevent critical unauthenticated remote code execution bugs from scoring above an 8.0. This structural shift risks misclassifying critical flaws as mere high-severity items on disclosure day, creating blind spots for operational patching workflows. Practitioners warn that vendors rarely return to update these CVSS threat vectors once weaponized exploits surface publicly, leaving downstream organizations with deflated scores unless internal teams continuously re-evaluate external intelligence against their assets.
Commentary
Relying on a single numeric CVSS score as a gating metric for patching SLAs is a long-standing failure mode, and CVSS v4.0's implementation quirks make that practice even more hazardous. When CNAs assign an `Unreported` (`E:U`) exploit maturity flag at patch release time, an unauthenticated RCE that would traditionally trigger emergency 24-hour remediation windows under CVSS 3.1 suddenly sits quietly under the `8.0` threshold. For security operations teams tied to rigid compliance mandates—where only scores `9.0` and above require immediate out-of-band rollouts—this creates significant organizational blind spots. Vendors have zero incentive to continuously update CVE vectors in national databases when public exploit scripts hit GitHub a week after patch Tuesday. Vulnerability management teams must decouple technical severity from static threat metrics. Security teams should parse full CVSS vector strings to isolate the Base metric group (focusing heavily on attack vector, complexity, and privileges required) and pair it with real-time exploit feeds such as CISA's KEV catalog and EPSS (Exploit Prediction Scoring System), rather than trusting threat-adjusted scores supplied by the vendor at day zero.
The Quote to Remember
“The new CVE scoring system basically lets vendors set exploit maturity for every vuln to unreported, as there's almost always no exploits before patch - which means you never get a CVE score above 8 for unauth RCEs any more as a vendor”
“A vendor may publish a 9.3 Base score for an unauthenticated RCE, while a threat-enriched assessment of that same CVE may currently be 8.1 because nobody has demonstrated exploitation. If exploit code appears tomorrow, that threat assessment changes.”