Introduction

Key Takeaways

  • CVE volumes have reached levels the industry was never designed to handle. H1 2026 produced 35,364 CVEs, one every 7.4 minutes. AI assisted development is one factor adding to this pressure. AI assisted code produces 2.74x more security issues than human written code and the current volume trend shows no immediate sign of easing.
  • Confirmed exploitation remains rare. Only 0.24% of H1 2026 CVEs had appeared in CISA's Known Exploited Vulnerabilities catalog at the time of the analysis, i.e, only 85 of the 35,364 CVEs were exploited by attackers. Hence, the vulnerability scanner output and the actual risk queue are not the same thing.
  • The window to respond is shrinking or has collapsed. The mean time to exploit was 63 days in 2018, and has now reached minus 7 days in 2025. So, periodic reviews and fixed weekly patch cycles alone may not be sufficient to remediate the vulnerabilities where exploitation window did not just sink, but is inverted.
  • The widening remediation gap. Though there is a drop in exploitation window, the median time to fully remediate a critical vulnerability rose to 43 days in 2026, when compared to 32 days in 2025. This is due to complex modern environments, and the AI code volume boom, resulting in alert fatigue for security teams.
  • Prioritization is the only operationally sustainable response. High volume, low exploitation rate, and collapsing response windows make it impossible to treat every CVE equally. Security teams need to identify the right vulnerabilities to fix first, before attackers do.

ManageEngine Vulnerability Manager Plus gives your team one score to act on. The AI/ML-driven risk prioritization model combines CVSS 4.0, EPSS probability, CISA KEV status, exploit availability, and asset context into a single composite priority order, updated continuously as threat data changes.The vulnerability management problem changed shape in 2026.

For years, the challenge was volume: too many findings, but, not enough time to patch. Security teams built processes around CVSS scores, weekly scanner reports, and patch cycles that assumed a relatively stable rate of new disclosures.

Two things are challenging that model this year. First, the rise of AI assisted code generation is adding new vulnerability volume pressure. The NVD is now handling volumes it was never designed to enrich at the same pace, with 195 new CVE disclosures per day in H1 2026. Second, AI is helping attackers find and exploit vulnerabilities faster.

Risk prioritization is no longer about managing a long queue more efficiently. It is about identifying the vulnerabilities most likely to become a real threat, before attackers can exploit them.

What Is Risk Prioritization?

A vulnerability with CVSS 9.8 on an air gapped internal test server carries very different real world risk than the same vulnerability on a publicly accessible payment processing server. Two teams running identical scans against identical software can produce different but equally correct priority orders, because their environments differ.

Risk prioritization is the process of identifying vulnerabilities by their actual likelihood of exploitation, business impact, and real-world attack activity, so security teams can focus on vulnerabilities that matter most.

Three related concepts are often confused:

  1. Vulnerability scanning discovers what is present in your environment.
  2. Risk assessment evaluates what could happen at a specific point in time.
  3. Risk prioritization continuously ranks what to fix first, given your specific environment, and business context.

Why is CVSS not enough for vulnerability prioritization?

CVSS was designed to describe the technical characteristics of a vulnerability. It was never designed to predict whether attackers would use it in the wild. CVSS tells security teams how severe a vulnerability could be, while EPSS estimates how likely it is to be exploited based on current threat signals. The difference matters when prioritizing vulnerabilities.

In a 2024 study by the Cyentia Institute, an EPSS based approach captured 92.5% of observed exploitation activity, compared with 37.4% for vulnerabilities with CVSS scores of 9.0 or higher, when the same proportion of vulnerabilities was selected for remediation. The takeaway here is that high severity does not necessarily mean high exploitation risk. Effective vulnerability prioritization therefore needs to consider both the severity of a vulnerability and the likelihood that attackers will exploit it.

How is AI changing the vulnerability landscape in 2026?

AI is increasing pressure on vulnerability management in two ways. It is contributing to the increase in volume of vulnerable code while also helping attackers identify and exploit vulnerabilities faster.

 

AI Generated Code and the CVE Surge

H1 2026 produced 35,364 CVEs, one new vulnerability every 7.4 minutes, a 49.5% increase over the same period in 2025 (JerryGamblin, July 2026). At the current pace, 2026 will close at approximately 71,000 to 72,000 CVEs, roughly 2.5 times the total from 2023.

AI assisted code produces 2.74x more security issues than human written code and the current volume trend shows no immediate sign of easing (Cloud Security Alliance, 2026). As AI coding tools become more common across development teams, the potential for additional vulnerabilities grows alongside productivity gains.

NIST announced in April 2026 that it will now immediately enrich only CVEs appearing in CISA's KEV catalog, software used within federal government systems, or software designated as critical under Executive Order 14028. All other CVEs will be listed in the NVD but not immediately enriched. For tools that rely on NVD enrichment data to match CVEs to affected products and generate severity scores, a significant portion of new disclosures will have limited metadata. With more CVEs, less metadata on arrival, and faster exploitation, severity based queues fail harder under these conditions than ever before.

 

CVE Volume Is Up. Confirmed Exploitation Is Not.

Despite the CVE surge, confirmed exploitation remains rare. At the time of the July 2026 analysis, only 85 of the 35,364 CVEs published in H1 2026 had appeared in CISA's Known Exploited Vulnerabilities catalog, representing 0.24% of that cohort (JerryGamblin, July 2026). The remaining 99.76% had not appeared in the KEV catalog at the time of the analysis, meaning confirmed exploitation was concentrated to a very small fraction of newly disclosed CVEs.

Some of the reasons might be because many of these CVEs are purely theoretical, and exist only in test environments. Security tools flag them as AI assisted code scanners help identify very minute flaw in a software code.

 

The Exploitation Window Is Collapsing

The mean time to exploit was 63 days in 2018, and has now reached minus 7 days in 2025 as per Mandiant's 2026 reports. A negative mean time to exploit means that, on average, exploitation was occurring before a patch was available, leaving defenders with little or no conventional remediation window. In other words, attackers could be exploiting some vulnerabilities before organizations had an official fix to deploy. So, periodic reviews and fixed weekly patch cycles alone may not be sufficient to remediate the vulnerabilities where exploitation window did not just sink, but is inverted.

IBM's Cost of a Data Breach Report 2026 recorded a 56% year over year increase in AI driven attacks and set a new record for average global breach cost: $4.99 million, a 12% increase over 2025. AI is the acceleration engine on both sides, generating more vulnerable code and helping attackers find and exploit it faster.

What Signals Help Assess Vulnerability Risk?

Understanding which signals to use is more important than building a complex scoring formula. CVSS gives security teams, how theoretically dangerous the bug is. EPSS adds exploitation likelihood, KEV adds evidence of active exploitation, and asset context shows how much the vulnerability matters in a specific environment.

 

CVSS: A starting point, Not the destination

The Common Vulnerability Scoring System scores the technical characteristics of a vulnerability: attack vector, privileges required, user interaction needed, and the potential impact. It does not score exploitation activity, attacker interest, and an organization's asset exposure. It can be used as a baseline filter, not as a final priority. A CVSS 9.8 vulnerability on an isolated internal server up for decommission next month is not an urgent item, while, a CVSS 6.5 vulnerability on an externally accessible authentication platform, with active KEV listing, is.

 

EPSS: Exploitation probability that updates every day

The Exploit Prediction Scoring System, developed and maintained by FIRST, estimates the probability that a specific CVE will be actively exploited in the wild within the next 30 days. Scores range from 0 to 1 and update every day as new vulnerability, exploit, threat intelligence, and community signals become available.

Unlike CVSS, EPSS is predictive. It uses vulnerability characteristics and current threat signals to estimate how likely a vulnerability is to be exploited, rather than scoring how severe the flaw theoretically is. All else being equal, a CVE with CVSS 9.8 and EPSS 0.003 has a lower exploitation likelihood than a CVE with CVSS 6.5 and EPSS 0.87.

 

CISA KEV: Confirmed exploitation

CISA's Known Exploited Vulnerabilities catalog is a curated list of CVEs confirmed to be under active exploitation in the wild. Any CVE in the KEV catalog should be treated as an immediate remediation priority regardless of its CVSS score.

 

Asset Context: The same CVE, Two different priorities

Combine EPSS and KEV with asset context and you have a genuinely actionable signal. Asset context means: is this system externally accessible or isolated? Does it hold regulated or sensitive data? Is it critical to operations or revenue? Are compensating controls already in place?

A vulnerability with EPSS 0.85, not yet in KEV, on a publicly accessible server handling customer data is an immediate remediation priority. The same vulnerability on an isolated development workstation with no external exposure is a next sprint item. No formula replaces this judgment, but a well designed composite score attributes it systematically.

How Should Vulnerabilities Be Prioritized?

Testing the signals to work with a repeatable process that holds across team sizes, industries, and environments:

Step 1: Know Your Assets Before You Score Your Vulnerabilities

Step 2: Apply Signals in Combination

Signal priority order:

  1. CISA KEV listing: immediate remediation regardless of CVSS or EPSS
  2. High EPSS (above 0.7) on a critical or exposed asset: urgent, within 24 to 48 hours
  3. Medium EPSS (0.3 to 0.7) combined with CVSS 7.0 or above: high priority, within 7 days
  4. Low EPSS, no KEV, CVSS below 7.0: manage in regular patch cycle

These thresholds are starting points. Other factors include vulnerability age, exposure duration, historic exploit behaviour patterns, affected systems, and operational constraints.

Step 3: Automate re-scoring as conditions change

EPSS scores update daily. CISA adds KEV entries continuously. At 195 CVEs per day, a prioritization decision made on Monday may be outdated by Friday. Continuous re-scoring, automatically adjusting priority when there is an increase in EPSS, or when a CVE is added to the KEV, or when the asset inventory changes, helps in due diligence.

Step 4: Close the loop between prioritization and remediation

Prioritization without integrated remediation leaves the gap between “what to fix” and “fixed” to manual hand-offs and follow up cycles. When the platform that identifies and prioritizes the risk, can also deploy patches, confirm remediation, and track coverage, it helps reduce the mean time to remediate (MTTR) window.

ManageEngine Vulnerability Manager Plus was designed for exactly this connection: from AI/ML-powered risk prioritization to built-in automated patch deployment in one console.

How Does Vulnerability Management Support Compliance?

Across the frameworks discussed below, a common pattern is risk based cybersecurity management, vulnerability handling, documented processes, and evidence of security controls or risk treatment. The exact obligations, scope, and evidence requirements differ by framework and jurisdiction.

NIS2 (EU Network and Information Security Directive 2) (applicable from October 2024)

Requires organizations in critical sectors across the EU to implement risk based cybersecurity measures, maintain vulnerability management processes, and report significant incidents.

DORA (EU Digital Operational Resilience Act) (applicable from January 2025)

Applies to financial entities and establishes requirements for ICT risk management, vulnerability identification, resilience testing, and oversight of certain ICT third party service providers.

ISO 27001:2022 (global)

The international standard for information security management. Its controls include management of technical vulnerabilities, while the standard requires organizations to assess and treat information security risks systematically.

GDPR Article 32 (EU/EEA, with extraterritorial reach)

Requires appropriate technical and organizational measures to ensure a level of security appropriate to the risk, including processes for regularly testing and evaluating security measures.

Australia's Essential Eight, Singapore's MAS Technology Risk Management Guidelines, India's CERT In cybersecurity directions and guidelines, and equivalent standards across APAC and LATAM all point in the same direction. The common thread across these frameworks is that organizations assess cybersecurity risk systematically, take action on identified vulnerabilities, and maintain evidence of how risk management decisions were made.

How ManageEngine Vulnerability Manager Plus Handles Risk Prioritization

ManageEngine Vulnerability Manager Plus was built for security teams that need to make prioritization decisions at scale without drowning in raw CVE data. Its AI/ML-driven risk score, ranging from 0 to 10, continuously evaluates each discovered vulnerability across a broad set of real world threat signals, and not just static severity ratings.

The score incorporates:

  1. CVSS severity (v3 and v4) as the technical severity baseline.
  2. EPSS for predicted exploitation probability over the next 30 days.
  3. Active exploitation signals: CISA KEV status and in the wild attack evidence.
  4. Exploit availability: public proof of concept code and weaponized exploits.
  5. Threat actor interest: underground forum mentions and ransomware campaign associations.
  6. Vulnerability age, remediation availability, and affected endpoint prevalence within your environment.
  7. ML driven cross-vulnerability correlations and historical exploit behaviour patterns.

Key capabilities:

  1. Continuous scanning
  2. Context-aware AI-powered risk prioritization
  3. Built-in automated patch management
  4. Zero-day mitigation with pre-built, tested scripts.
  5. Compliance audit and customization
icon-1About the author
Prasanna Kumar

Prasanna Kumar is a Product Consultant at ManageEngine, specializing in Unified Endpoint Management and security solutions. He helps organizations evaluate, implement, and optimize endpoint management strategies aligned with industry best practices.