CVE disclosure trends: The biggest spikes and drops (October 2026)

For sysadmins, a change in CVE disclosures raises a practical question: What does this mean for the software we manage? This report compares newly published CVE counts across two consecutive periods of approximately 30 days to identify which products saw the biggest increases and declines. 

We also look separately at vulnerability findings across sampled devices to see where resolution activity increased and what remains open. Along the way, we’ll explain how to interpret the numbers and use PDQ to connect those findings to the software versions and devices in your environment. 

Key findings from PDQ’s vulnerability analysis 

Three patterns stand out: The largest percentage increases did not represent the largest increases by count, declining disclosures did not eliminate exposure, and higher resolution totals did not mean the remaining backlog was small. 

• The biggest percentage spike is not automatically the biggest priority. Microsoft .NET’s 1,033% increase represented 31 additional CVEs. The Windows 11 24H2 / 25H2 row increased by a smaller 62% but added 390. Compare absolute changes, then determine which vulnerabilities affect software you actually run. 

• Fewer disclosures do not mean fewer reasons to patch. Chrome’s disclosures fell 20%, but the latest window still included 29 CVEs flagged as weaponized. A downward trend should not override evidence that an installed version needs remediation. 

• Resolution volume and remaining exposure need to be read together. Windows 11 Enterprise 25H2 recorded 3.12 million resolved vulnerability findings, while 2.18 million remained open. Evaluate remediation activity alongside the remaining backlog, newly opened findings, and affected devices. 

What do these CVE disclosure trends measure? 

This analysis compares two different measurements: newly published CVEs associated with software products and vulnerability findings across sampled devices. The first describes publication activity; the second describes vulnerability instances and their status within the device sample. 

Data source and reporting periods 

Data source and sample: CVE data came primarily from Cortex. The threat intelligence used for the analysis draws on NIST, MITRE, and vendors including Microsoft, Adobe, and Apple. 

The analysis includes only vulnerable software found in at least one organization using PDQ. The disclosure results therefore reflect software represented in PDQ environments, rather than an unfiltered view of all published CVEs. 

Across the approximately 90-day reporting period, 66 organizations and 37,590 distinct devices produced at least one new vulnerability finding. The number of organizations and devices producing new findings in each window was: 

Organizations and devices can appear in more than one window, so the per-window counts should not be added together. These figures describe the population with new findings, not a confirmed total of all organizations and devices monitored during the period. 

CVE disclosure periods: The latest reporting period covers September 14 through October 14, 2026. The preceding period covers August 15 through September 13, 2026. Where referenced, the oldest period covers July 8 through August 14, 2026. 

Resolution periods: The period labeled August to September covers August 7 through September 5, 2026. The period labeled September to October covers September 6 through October 5, 2026. Open findings represent vulnerability instances listed as unresolved in the dataset. 

Counting rules: CVE records were grouped by software and separated into reporting windows using their publication dates. The analysis compares the latest reporting window with the preceding window, using the oldest window for additional context. Because the windows differ in length, percentage changes compare total CVEs per window, not daily disclosure rates. 

“Latest reporting period” refers to the dataset’s reporting window, not a live count. 

CVEs, vulnerability findings, and status labels 

A CVE ID identifies a cataloged vulnerability. A vulnerability finding is an instance of a vulnerability detected in the sampled environment. One CVE detected on 500 devices can produce 500 findings; resolving those findings does not mean 500 different vulnerabilities were fixed. 

Resolved findings count vulnerability instances marked resolved during the reporting period because the affected software was updated or uninstalled. Ignored findings are not counted as resolved. 

Open findings count vulnerability instances recorded as open in the dataset. Neither open nor resolved findings represent counts of unique CVEs or unique devices. Removed devices are excluded from the dataset entirely. 

Critical is the source data’s classification based on Common Vulnerability Scoring System (CVSS) scores. 

Weaponized identifies CVEs listed in the CISA Known Exploited Vulnerabilities Catalog. This flag should not be interpreted as evidence that a sampled device was attacked. 

Product rows can overlap because a CVE may affect multiple products or versions. These are product-level comparisons, not numbers to add together for a vendor-wide vulnerability total. 

Which products saw the biggest spikes in CVE disclosures? 

Microsoft .NET led percentage growth at 1,033%, followed by OpenSSH at 1,000%. By absolute increase, the Windows 11 24H2 / 25H2 row had the largest jump among the listed products, adding 390 CVEs to reach 1,020 in the latest window. 

Grouped product labels follow the source dataset. Paired counts correspond to the products in the order listed. A percentage increase cannot be calculated from a zero baseline. 

What rising CVE counts mean for IT teams 

A disclosure spike is a reason to investigate affected versions, not an instruction to prioritize a product solely because its percentage increase is large. Start with the absolute change, then determine whether the disclosed vulnerabilities affect your devices and how much risk those devices carry. 

.NET’s increase represented 31 additional CVEs, while OpenSSH’s represented 10. Both also returned close to their counts from the oldest reporting window: 32 for .NET and 11 for OpenSSH. Those four-digit increases followed an unusually quiet comparison period. 

Windows stood out for both volume and the number of CVEs classified as critical. Windows Server 2025 recorded 1,050 CVEs, including 48 critical CVEs. The Windows 11 24H2 / 25H2 row recorded 1,020, including 41 critical CVEs. Each row included one CVE flagged as weaponized, although those flags should not be assumed to represent different vulnerabilities. 

Lower-volume products still deserve attention where they are installed. Adobe ColdFusion’s 31 disclosures included five critical CVEs, while Apache HTTP Server’s 20 included three. 

The practical takeaway: Confirm affected software versions before turning disclosure counts into a patching queue. Then weigh exploitation evidence, system exposure, business importance, severity, and the number of affected devices. A vulnerability on an exposed, business-critical server can warrant attention before a much larger batch of disclosures for software you do not run. 

Which products saw the biggest drops in CVE disclosures? 

Microsoft Edge recorded the largest absolute decline among the listed products, falling from 491 to 130 CVEs, or 361 fewer disclosures. Several products recorded a 100% decrease, including the Adobe Acrobat family, Microsoft Word and Excel, MongoDB, and Dell Command Update. 

What falling CVE counts mean for IT teams 

A decline means fewer CVEs were published during the comparison window. It does not establish that existing vulnerabilities were fixed, that installed versions are unaffected, or that the product should move down your patching queue. 

Chrome’s count fell 20%, but its latest window still contained 495 CVEs, including 29 flagged as weaponized. The lower disclosure count does not remove the need to investigate affected Chrome installations. 

The Acrobat data makes a related point. The Acrobat product family recorded no newly published CVEs in the latest window, while the separate device-level sample still showed approximately 7,900 open findings for Adobe Acrobat (64-bit). A quiet disclosure period does not erase an existing backlog. 

The practical takeaway: Keep reviewing known vulnerabilities even when new disclosures slow down. Check installed versions, outstanding findings, and exploitation evidence rather than using a downward percentage as an all-clear. 

CISA recommends using its Known Exploited Vulnerabilities Catalog as an input to vulnerability prioritization. Consult it alongside vendor advisories and your own environment’s exposure, while recognizing that catalog inclusion does not establish that a sampled device was attacked. 

Which products saw the biggest resolution surges? 

Windows 11 Enterprise 25H2 had the largest resolved-findings volume among the listed products, reaching 3.12 million in the period labeled September to October. Adobe Acrobat (64-bit) also rose sharply, from approximately 1,800 to 18,600 resolved findings, a reported increase of 930%. 

The resolved and open counts in this table come from the previously described sample of 66 organizations and 37,590 distinct devices that produced at least one new finding during the approximately 90-day reporting period. 

These figures count vulnerability instances, not unique CVEs or unique devices. Resolved findings include cases where the affected software was updated or uninstalled. 

Counts are rounded. The Acrobat percentage is reproduced as reported rather than recalculated from rounded figures. 

What resolved findings tell you about patching performance 

Higher resolution counts show more vulnerability instances being marked resolved, but they do not establish a shrinking backlog or prove a particular patch succeeded. Evaluating patching performance also requires newly opened findings, the remaining backlog, affected device counts, and consistent scan coverage. 

Windows 11 Enterprise 25H2 still had 2.18 million open findings in the sample. Windows 11 Pro 24H2 had approximately 90,000. Dell Command Update’s resolved findings increased from about 500 to 6,100, but approximately 39,000 remained open. 

Dell’s figures are especially useful alongside its disclosure trend: The product recorded no newly published CVEs in the latest window, yet substantial device-level findings remained. That is work the disclosure table alone would not reveal. 

To understand whether remediation is keeping pace, compare newly opened findings with resolved findings over the same period and track how the open backlog changes. Review the age and severity of unresolved findings, too. A larger resolved total can coexist with high-priority issues that remain untouched. 

Keep device coverage consistent when making comparisons. Changes in the number of observed devices can affect totals, and a device without a recent scan should not be assumed to be clear of vulnerabilities. 

The practical takeaway: Report both what was resolved and what still needs attention. Verify the remaining affected devices rather than treating a large resolution total as the finish line. 

How can PDQ turn disclosure trends into a patching plan? 

PDQ’s Software page connects this analysis to installed applications, versions, and associated devices. Use it to establish where a product is present before deciding which installations need remediation. 

1. Find the software and review its installations. On the Software page, review the Installed count. Latest and Outdated counts are also available for some supported software. Click a count to see the corresponding installations and devices, then check installed versions against the relevant vulnerability information. 

2. Identify affected devices. On plans with vulnerability management, use Total vulnerabilities and Vulnerable devices alongside version information. An outdated installation is a starting point for investigation, not proof that it is affected by every CVE associated with that product. 

3. Test and deploy the appropriate remediation. On the Vulnerabilities page, review impacted devices and available remediation guidance. Select an appropriate Package Library or custom package, test it on a limited set of affected devices, and confirm that it addresses the vulnerability before expanding deployment. 

4. Verify what remains open. Deployments trigger scan activity automatically. Review refreshed vulnerability findings after deployment and address devices that still need remediation. PDQ’s dashboard also provides active, resolved, and new vulnerability views to help track whether remediation is keeping pace with newly identified exposure. 

One counting detail matters: Installation counts are not necessarily unique device counts. Side-by-side software versions can produce multiple entries on one device. Use a device-based report for unique device totals and the Vulnerable devices column for devices with detected exposure. 

For example, Chrome’s declining disclosure count does not answer whether your fleet needs an update. Your installed versions, detected vulnerabilities, and affected devices provide the information needed to make that decision. 

CVE disclosure trend FAQs

Does a decrease in CVE disclosures mean software is more secure? 

No, a decrease means fewer CVEs were published during the reporting window, not that existing vulnerabilities were fixed or affected installations disappeared. Determine whether your environment is less exposed by checking installed versions, outstanding vulnerability findings, and verified remediation results rather than relying on the disclosure trend alone. 

What do resolved vulnerability counts tell you about patching performance? 

Resolved counts show how many vulnerability instances were marked resolved during a reporting period, not how many unique CVEs or devices were patched. Evaluate them alongside newly opened findings, the remaining backlog, affected device counts, and scan coverage before treating an increase as evidence of better patching performance. 

How should IT teams prioritize vulnerabilities when CVE counts increase? 

Start by confirming which disclosed vulnerabilities affect installed software versions in your environment. Prioritize affected devices using exploitation evidence, internet exposure, business importance, severity, and the number of impacted devices, then test the appropriate fix and verify remediation rather than ranking work by percentage growth alone. 

Turn CVE disclosure trends into a clearer patching plan 

CVE disclosure trends help identify software worth investigating, but they cannot tell you on their own which device should be patched next. PDQ’s analysis shows why: Large percentage spikes can follow small starting counts, falling disclosures can still include weaponized CVEs, and millions of resolved findings can leave a substantial backlog. 

Start with the software in your environment. Confirm affected versions, weigh exploitation evidence and business impact, and target the devices that need remediation. Then review fresh findings to distinguish completed work from exposure that remains. 

PDQ connects those decisions to software inventory, affected devices, deployment, and remediation tracking. That makes the data useful beyond the report: not just understanding which numbers changed, but deciding what to investigate, what to fix, and how to confirm the fix worked. 

The goal is not simply a lower disclosure count or a larger resolved total. It is fewer exposed devices and verified remediation of the vulnerabilities that matter to your organization.