Windows CVE Volume in 2026: What Patching Teams Should Measure

Across the three complete years in our new research, distinct Windows and Office CVEs went from 679 to 941 to 2,438 (+38.6%, then +159.1%), while the mean CVSS v3 base score moved from 7.43 to 7.37 to 7.28. That is a much larger inbound workload with an average severity that has not risen, which is why a raw CVE count is a poor way to run a patching programme. This post goes through what the numbers say, how the cohort was built, what to measure instead and what the study could not measure. The research is company-authored and has not been peer reviewed. We announced it on 2 November, and the full paper is available from the registration page.

What the annual numbers say

The paper compares three non-overlapping complete years, each running October to September, so that no unfinished month distorts the comparison.

Distinct Windows and Office CVEs in the paper's three complete annual cohorts. Windows and Office overlap, so the union is deduplicated and the two counts must not be added.

The surge is not spread evenly. The paper finds it concentrated in mid to late 2026: July had 483 CVEs, August 316 and September 819, against a median of 69 a month across the 36 complete months. October 2026 already contributes 1,277 Windows and Office CVEs through the 26 October cutoff, including 1,114 Windows operating-system records. These are revised monthly disclosure totals that include off-cycle records, so they should not be equated with a news report that counts only the original Patch Tuesday release. The paper does not project a single month into an annual forecast, and it claims no significance test or causal breakpoint.

Over the latest 12 reporting months (November 2025 to October 2026, with October partial) the cohort holds 3,565 CVEs, about 297.1 per reporting month. Dividing by 12 describes throughput per reporting month and does not annualise October. The complete-month check ending September 2026 gives 2,438 CVEs over 12 months, 3,379 over 24 and 4,058 over 36.

Average severity did not climb

The mean does not support a general rise in average base severity, but it does not mean the risk fell either. The absolute number of serious disclosures can grow while their average holds steady: in the latest year, 1,841 of 2,436 scored records (75.6%) score at least 7, and 60 score 9.0 or above. The paper treats CVSS as a severity scale and its mean as a descriptive summary, not an expected financial loss or a probability of compromise. Vendor Critical labels are a different classification and are reported separately.

The study also joins each CVE to the CISA Known Exploited Vulnerabilities catalogue. Membership in the three annual cohorts is 29, 25 and 21 as of the cutoff. The paper calls that a descriptive cross-section, not evidence that exploitation is becoming less common: follow-up time differs, catalogue coverage is incomplete and an expanding denominator can mechanically lower the observed share.

How the cohort was built

The method is deliberately conservative, and each step is visible in the paper.

1. Source. 37 monthly Microsoft Security Response Center CVRF documents, October 2023 to October 2026, retained with timestamps and SHA-256 hashes.
2. Cleaning. Seven non-CVE advisory rows and 48 explicitly rejected CVE identifiers were excluded. Repeated product-version rows were collapsed to one record per CVE.
3. Bounded scope. Numbered Windows clients and Windows Server products, plus desktop Office applications, with an explicit product allowlist. Totals across every Microsoft Security Response Center record are not the headline measure because they also include Azure Linux, cloud services and upstream components.
4. One date per CVE. The earliest valid revision date. The paper is clear that this is a Microsoft-reporting disclosure proxy, not an observed discovery date, a global publication date or a patch-installation date.
5. One score per CVE. The highest observed applicable CVSS v3.x base score across retained revisions. Missing scores are excluded from the mean and its denominator, and CVSS v4 and temporal scores are not mixed in.
6. Exploitation join. CISA KEV membership by CVE ID, using catalogue version 2026.10.23.
7. Partial months. Complete years use October to September. October 2026 is reported on its own and never treated as a finished month.

Automated checks confirmed the 37 expected documents, no duplicate CVE and scope keys, valid score ranges and monthly counts that reconcile to cohort totals. A six-record comparison with NVD and the CVE Services API is a consistency check, not independent replication, and NVD is not used as the sole scored-product denominator because its 2024 backlog and an April 2026 change in enrichment policy create a coverage break. According to the paper, the analytical supplement holds the CVE-level and monthly cohort tables, the product-scope audit, excluded and rejected records, the application release events and monthly series, the 17-row remediation timing dataset and coverage file, the evidence ledgers and a SHA-256 manifest, with the analysis scripts included.

Six application release streams

Packaging teams do not patch to one calendar, so the paper adds a purposive panel of six release streams: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ and 7-Zip. A release day is a distinct date on which a version was published for an app. In the latest complete year the panel runs from 69 release days for Edge, 64 for Chrome and 61 for Visual Studio Code, through 44 for Firefox and 17 for Notepad++, down to 4 for 7-Zip. Peak months are busier than those averages suggest: Visual Studio Code reached nine release days in a single month.

Across the 36 complete months the six streams produced 661 app-specific release days. The panel is not a representative sample of Windows software, the CVE and release populations differ, and the paper says the counts must not be multiplied together or read as a causal relationship. Release days describe availability and monitoring opportunities, not mandatory deployments or packaging hours.

What to measure instead of CVE counts

The paper proposes these as management measures, not values inferred from CVE totals.

• Time to verified protection: from applicable vendor fix availability to confirmed protection, including browser restarts, reboots and rescans. Report the median and 90th percentile, plus failed installs, rollback rate and exception expiry.
• Release-to-decision and release-to-protection delay for each app and channel.
• Qualification effort: monthly selected version transitions, central artefact builds, and median and 90th-percentile qualification duration.
• Rework: emergency share, failure and rework rate, and the updater failure backlog.
• Exposure: the age of outstanding applicable security updates, plus exposed KEV instances and their age, unsupported assets and backlog by service importance.

Underneath all of these sits a versioned inventory, so a CVE is matched to the installed and exposed assets before the remediation queue grows. Keep CVE counts separate from device instances and deployment effort.

What the study could not measure

• A whole-cohort repair-time average. Every one of the 4,058 complete-window CVEs has a valid revision timestamp, but no specified discovery or release date. All 98,265 applicable remediation rows carry the year-0001 sentinel date with DateSpecified=false. Vendor-fix entries exist for all 4,058 CVEs, explicit workaround entries for five and mitigation entries for 66, so there are zero usable structured date pairs. Missing dates are not zero delays.
• A single clock. Dated cases, such as three PHP and NGINX private-report-to-release intervals of 61, 71 and 81 days, use different start and end events and are reported separately, not pooled into an average.
• Severity for every browser CVE. Only 240 of 2,931 Edge-related records (8.2%) carry an applicable numeric CVSS v3 score in this extraction, so that group's mean cannot stand for all browser CVEs.
• What administrators saw on the day. Historical monthly files are mutable and scores can change after initial disclosure. The snapshot supports replication of the study, not recovery of earlier source states.

Where EtherApps Forge fits

The study does not evaluate EtherApps Forge or any commercial product, and EfficientEther declares its interest in EtherApps Forge in the paper. The connection is the work the numbers create. When vendor releases arrive faster, the packaging question becomes which applications you package centrally and how quickly you can qualify each new version. EtherApps Forge captures Windows applications where they already run and builds signed MSIX, MSI, Intune and App Attach packages, which is the packaging side of that routine. Application modernisation and migration and legacy application modernisation cover the older applications that are hardest to keep current, and our earlier study of 3,261 automated MSIX packaging cases shows how we separate package creation from launch and test evidence.

Get the Windows patching research for the full tables, the method and the measures your team can adopt.