Security teams face one new CVE every 7.4 minutes, yet only a fraction of vendor security advisories describe vulnerabilities with meaningful exploitation likelihood or exposure. This analysis maps the evidence separating genuine operational risk from advisory noise, for SOC teams, vulnerability management programmes, and security leadership responsible for prioritisation decisions.

Reading time 10 minutes

Executive Summary

Vendor security advisories are signals, not prioritisation decisions. Operational risk emerges from the combination of exploitation evidence, exploitability, exposure, asset criticality, potential impact and available controls. CVSS severity is an important input, but it is not a sufficient basis for deciding what to remediate first.

Advisory volume makes this harder to execute. The first half of 2026 produced 35,364 CVEs, a 49.5% increase over 2025 driven largely by expanded CNA reporting and automated vulnerability discovery. Only 0.24% of them reached CISA's Known Exploited Vulnerabilities catalog. With 42.2% of scored CVEs carrying High ratings and another 11.7% rated Critical, a CVSS 7+ policy flags over half of all published vulnerabilities as priority work. That math does not work in a live environment.

The operational problem sits in signal extraction. Teams treating every critical-severity advisory as urgent burn remediation capacity on low-exploitation-probability vulnerabilities, while higher-risk medium-severity vulnerabilities wait in the backlog.

Key takeaway: exploitation evidence, exploitability, exposure and asset criticality provide stronger operational signals than severity alone. Advisory detail can also provide defenders with important clues about how quickly exploitation may develop.

The Problem: Severity Became a Proxy for Risk

Most vulnerability management programmes inherited a simple rule. Patch everything CVSS 7 and above, defer the rest.

The rule made sense when advisory volume was manageable. It persists because auditors understand it, dashboards display it, and compliance frameworks reference it.

The 2026 data breaks the rule. As of mid-August 2026 (see table above), a CVSS 7+ policy now flags over half of all published vulnerabilities as priority work.

The central thesis: vendor security advisories are signals, not prioritisation decisions. Operational risk emerges from the combination of exploitation evidence, exploitability, exposure, asset criticality, potential impact and available controls. CVSS severity is an important input, but it is not a sufficient basis for deciding what to remediate first.

The Evidence

CVSS severity is not a prioritisation decision

CVSS Base measures vulnerability severity; it does not by itself determine operational risk. FIRST's CVSS framework explicitly separates Base severity from Threat and Environmental context. The operational mistake is not using CVSS. It is allowing a vulnerability attribute to become the remediation decision.

FIRST research illustrates the limitation of using CVSS severity alone for prioritisation: only a small proportion of CVSS 7+ vulnerabilities are observed being exploited, while a large population of vulnerabilities receives high-severity ratings. Severity therefore needs to be combined with exploitation intelligence and environmental context.

Exploit availability also demonstrates why severity alone is insufficient. Vulnerabilities with publicly available exploit code are not confined to the highest CVSS bands. CVSS Base describes the technical characteristics of a vulnerability; it does not tell defenders whether their particular instance is exposed, reachable, important to the business or currently being targeted.

The exploitation window inverted

Google Threat Intelligence research has documented negative Time-to-Exploit measurements, meaning that exploitation was observed for some vulnerabilities before public disclosure or patch availability. The important operational implication is not that attackers universally exploit vulnerabilities before disclosure, but that defenders cannot assume every disclosure creates a safe patching window.

Exploitation can also follow disclosure extremely quickly. The relevant defensive assumption is therefore that a subset of high-impact vulnerabilities may already be under exploitation when disclosure occurs, particularly where the affected product is internet-facing and widely deployed.

The Langflow RCE case illustrates the speed of this process. Exploitation was observed shortly after disclosure, demonstrating how quickly defenders may need to move from advisory review to exposure assessment, detection and mitigation.

💡 Advisory detail is dual-use intelligence. Vendor advisories can reduce the information required to reproduce or weaponise a vulnerability, making the advisory itself an operational input for both defenders and attackers.

KEV provides a high-confidence exploitation signal

CISA's Known Exploited Vulnerabilities catalog provides a high-confidence signal because entries represent vulnerabilities for which exploitation has been observed in the wild. KEV should therefore be a primary input to vulnerability prioritisation, but it is not a complete measure of risk: absence from KEV does not mean absence of exploitation or low risk.

Operational Analysis: Why Current Approaches Fail

Vulnerability remediation frequently operates on a much slower timescale than modern intrusion activity. Google/Mandiant has also documented extremely rapid hand-off between stages of ransomware operations. These measurements describe different stages of an intrusion and should not be interpreted as a direct comparison between vulnerability exploitation and ransomware deployment. The operational lesson is that defenders cannot assume that a long remediation window is harmless once exploitation or exposure is established.

The prioritisation failure compounds the speed failure. Picus research found that vulnerabilities with an EPSS score above 0.7 had an average remediation time of 109 days, compared with approximately 76 days for lower-probability vulnerabilities.

Remediation effort does not always align with exploitation likelihood. Where high-exploitation-probability vulnerabilities take longer to remediate than lower-probability vulnerabilities, organisations should investigate whether prioritisation, ownership, exposure, remediation complexity or compensating controls explain the gap.

Vendor patterns sharpen the picture (see table above): raw CVE volume and confirmed exploitation are different datasets, and neither vendor popularity nor output volume reliably predicts which one to worry about.

Volume and risk live in different datasets.

Visibility Gaps and Control Failures

Several structural blind spots keep advisory triage broken:

· Stale scoring. A vendor-provided CVSS Base score describes the vulnerability's technical severity, but does not automatically incorporate changes in exploitation activity, asset exposure, business criticality or local compensating controls. Organisations that rely on the original Base score without updating contextual assessment can therefore lose alignment with current risk.

· Catalog lag. runZero's kevology research documents commodity exploit tooling predating KEV additions by days, weeks, and years. One vulnerability received its CVE record, KEV entry, and public commodity tooling on the same day. KEV confirms exploitation, and confirmation arrives after the fact.

· Product-class blindness. Remote-access, network infrastructure and other edge technologies can provide valuable initial-access paths and therefore require explicit coverage in asset discovery and vulnerability prioritisation. The attack surface is broader than the products traditionally treated as enterprise-critical.

· Age assumptions. The age of a CVE is not a proxy for its relevance. The oldest 2026 KEV addition dates to 2008, demonstrating that vulnerabilities can remain operationally significant many years after disclosure when vulnerable systems remain deployed and reachable. Filtering primarily by publication date can therefore miss persistent exposure.

· Governance mismatch. Internal vulnerability policies and remediation SLAs can become anchored to CVSS thresholds, creating pressure to remediate severity-ranked vulnerabilities even when exploitation evidence, exposure or asset criticality indicate a different priority.

· Asset-to-CVE visibility. Knowing that a CVE affects a product is not enough. Defenders need to know whether the organisation actually has affected assets, who owns them, whether they are externally reachable, what business service they support, what attack path they expose and whether compensating controls exist. The operational chain is CVE → affected asset → exposure → business function → attack path → controls.

Common Questions

Q: Does a Critical CVSS score mean a vulnerability is an emergency?

No. CVSS Base measures technical severity, not operational risk. A Critical score indicates that the vulnerability has characteristics such as network exploitability and high impact potential, but it does not tell defenders whether the affected asset is present in the organisation, whether it is reachable, whether exploit code exists or whether exploitation is occurring. A Critical-rated vulnerability on an isolated, non-production system with no exploit code and no KEV entry requires a different response than a Medium-rated vulnerability on an internet-facing identity system with confirmed in-the-wild exploitation. Severity is one input. The remediation decision requires five.

Q: If a vulnerability is not in CISA's KEV catalog, does that mean it is safe to deprioritise?

No. KEV represents confirmed exploitation, not the complete universe of exploitation. Absence from KEV means exploitation has not been confirmed and added to the catalog at that point in time. It does not mean exploitation is not occurring, that exploit code does not exist or that the vulnerability carries low operational risk. A vulnerability with a high EPSS score, publicly available proof-of-concept code and an internet-facing affected asset may require urgent treatment regardless of KEV status. KEV is a high-confidence signal, not a safety boundary.

Q: How should vulnerability management teams prioritise when they cannot patch everything?

Prioritise by combining five signals: confirmed exploitation evidence, reachability of the affected asset, exploitation likelihood (EPSS, exploit maturity, PoC availability), potential impact if exploitation succeeds and asset criticality to the business. Where patching cannot proceed immediately, reduce attackability through compensating controls: segment the asset, restrict access, disable vulnerable functionality. The goal is not to patch the most vulnerabilities. It is to reduce the organisation's exposure to vulnerabilities that can materially change its risk position.

Decision Framework: Five Signals That Make an Advisory Matter

The remediation decision should not be determined by CVSS, KEV, or EPSS in isolation. Assess these five signals together to establish true operational risk.

Decision rule (aligning with SSVC frameworks):

Priority = exploitation evidence + reachability + exploitability + impact + asset criticality
(adjusted for existing controls and remediation constraints)

A vulnerability can therefore require urgent action without being in KEV, and a Critical CVSS score does not automatically make a vulnerability an emergency.

⚠️ Reassess continuously. KEV additions, new exploit code, changing exposure and new threat intelligence can move a vulnerability into a higher-priority category at any time.

Operational Outcomes

Adopting exploitation-anchored triage produces measurable shifts:

· Queue compression. Emergency remediation is reserved for vulnerabilities with strong exploitation, exposure or impact signals, while routine vulnerabilities remain within normal patch cycles.

· Better alignment. High-exploitation-probability vulnerabilities receive explicit scrutiny rather than waiting solely because their CVSS score is below an internal threshold.

· Exposure reduction. Where immediate patching is not possible, segmentation, access restriction, disabling vulnerable functionality and other compensating controls can reduce attackability while remediation proceeds.

· Resource honesty. Engineering effort is directed toward vulnerabilities that can materially change organisational exposure rather than toward raw CVE volume.

Workflow Integration Guidance

SOC teams: ingest KEV additions and credible exploitation intelligence as detection and investigation triggers. Where an advisory contains sufficient technical detail to reproduce exploitation, assess whether hunting or detection coverage should begin before patch deployment.

Vulnerability management: use CVSS as a severity input rather than the sole prioritisation rule. Combine exploitation evidence, EPSS, exploit maturity, exposure, asset criticality and business impact when assigning remediation priority.

Detection engineering: build detection coverage around products and vulnerability classes that can provide initial access, privilege escalation or access to critical services. Prioritise coverage according to actual exposure rather than vendor popularity.

Security engineering: where immediate patching is impossible, reduce attackability through exposure reduction, access restriction, segmentation, disabling vulnerable functionality and other compensating controls while remediation proceeds.

Security leadership: report exploitation-tier coverage, exposed critical vulnerabilities, remediation against defined risk-based deadlines and exceptions requiring compensating controls. Do not rely on raw patch counts as the primary measure of vulnerability risk reduction.

What you should do next

Ensure you understand operational related failures because failures are opportunities for learning and improving.

Further Reading

Vulnerability intelligence articles and deep dives.

Hackerstorm Analysis

The industry systematically underestimates the advisory itself as an operational security signal. A detailed vendor advisory can reduce the information required to reproduce or weaponise a vulnerability, while exploitation intelligence can reveal that attackers have already moved ahead of the disclosure process.

This changes the question defenders should ask.  The important question is not:  "How severe is this CVE?"

It is:  "Can an attacker exploit this vulnerability against something that matters to us?"

That requires connecting datasets that are often analysed separately: vulnerability severity, exploitation intelligence, exploitability, asset inventory, exposure, business criticality and existing controls.

Three structural observations follow.

First, KEV is high-confidence but retrospective. It tells defenders where exploitation has been confirmed, but confirmation necessarily arrives after evidence exists. KEV should therefore be treated as a priority signal, not as the boundary between dangerous and safe vulnerabilities.

Second, vulnerability age and vulnerability relevance are different things. An old vulnerability can remain operationally important when vulnerable assets remain deployed and reachable. Publication date should therefore never be used as a proxy for current risk.

Third, vulnerability volume and operational risk are different datasets. CVE counts describe the scale of the vulnerability population. They do not describe how many affected assets an organisation operates, how exposed those assets are, how exploitable the vulnerabilities are or what happens if exploitation succeeds.

HackerStorm's assessment: vulnerability management is entering a period in which signal integration matters more than severity thresholds. Organisations that connect exploitation evidence with exposure and asset criticality can reduce emergency workload without simply accepting greater risk.

The durable advantage is not patching more vulnerabilities, it is identifying which vulnerabilities can materially change the organisation's exposure. Those are the ones to act on first.

About This Report

Attribution Note

This analysis is based on publicly available reporting and security research summaries. Some technical details may change as additional information becomes available. 

Author Information

Timur Mehmet | Founder & Lead Editor

Timur is a veteran Information Security professional with a career spanning over three decades. Since the 1990s, he has led security initiatives across high-stakes sectors, including Finance, Telecommunications, Media, and Energy. Professional qualifications over the years have included CISSP, ISO27000 Auditor, ITIL and technologies such as Networking, Operating Systems, PKI, Firewalls. For more information including independent citations and credentials, visit our About page.

Contact: This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Standards

This article adheres to Hackerstorm.com's commitment to accuracy, independence, and transparency:

• Fact-Checking: All statistics and claims are verified against primary sources and authoritative reports
• Source Transparency: Original research sources and citations are provided in the References section below
• No Conflicts of Interest: This analysis is independent and not sponsored by any vendor or organization
• Corrections Policy: We correct errors promptly and transparently. Report inaccuracies to This email address is being protected from spambots. You need JavaScript enabled to view it.

Editorial Policy: Ethics, Non-Bias, Fact Checking and Corrections

Learn More: About Hackerstorm.com | FAQs

Source Transparency

· FIRST CVSS 4.0 User Guide, Base, Threat and Environmental metrics: https://www.first.org/cvss/user-guide

· FIRST Exploit Prediction Scoring System (EPSS) documentation: https://www.first.org/epss/

· CISA Known Exploited Vulnerabilities catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

· CISA Binding Operational Directive 26-04, Prioritising Security Updates Based on Risk (supersedes BOD 22-01, June 10, 2026): https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk

· NIST National Vulnerability Database (NVD): https://nvd.nist.gov/

· UK NCSC Vulnerability Management guidance, asset identification, risk assessment, prioritisation, active exploitation and compensating controls: https://www.ncsc.gov.uk/collection/vulnerability-management

· Google Cloud / Mandiant, attacker timelines and ransomware hand-off research: https://cloud.google.com/security/resources/threat-intelligence

· H1 2026 CVE publication analysis, Jerry Gamblin: https://jerrygamblin.com/2026/07/01/3528/

· 2026 CVE statistics, CVEToDo: https://cvetodo.com/cve-statistics

· Kevology research, runZero: https://www.runzero.com/resources/kevology/

· Langflow RCE exploitation reporting, CSO Online: https://www.csoonline.com/article/4151203/attackers-exploit-critical-langflow-rce-within-hours-as-cisa-sounds-alarm.html