EfficientEther

Windows Patching When Disclosure Moves at AI Speed: Our New Research

New company research: Windows and Office CVEs rose 159.1% in the latest complete year while mean CVSS stayed near 7.3. What it measured and what it did not.

ETEfficientEther Team2 November 20263 min read
Windows Patching When Disclosure Moves at AI Speed: Our New Research
EfficientEther Research (Zenodo, CC BY 4.0). Paper and data

Windows and Office CVE volume has risen sharply, but the average severity of those CVEs has not. That is the finding at the centre of our new research. In the latest complete year (October 2025 to September 2026) the study counts 2,438 distinct Windows and Office CVEs, up 159.1% on the 941 of the year before, while the mean CVSS v3 base score moved from 7.43 to 7.37 to 7.28. For anyone who owns patching or application packaging, the useful question is no longer how many CVEs were published. It is how to keep pace with a faster stream of updates and prove that each one is actually running.

The paper, Windows patching when disclosure moves at AI speed, is a 36-month descriptive study of Windows and Office CVEs, application release cadence and remediation timing. It was written by Ryan Mangan at EfficientEther. It is company-authored research and it has not been peer reviewed. It is published as an open-access preprint on Zenodo under a CC BY 4.0 licence. The EtherApps Forge edition, which is the same research in a designed layout, is free from the registration page.

What the study found

These are the headline numbers, as the paper states them.

  • 2,438 Windows and Office CVEs in the latest complete year, against 941 the year before and 679 the year before that (+38.6%, then +159.1%). The paper finds the surge concentrated in mid to late 2026.
  • A broadly unchanged mean CVSS v3 score of 7.43, 7.37 and 7.28. CVEs scored 9.0 or above rose from 11 to 60 between the last two complete years, so a stable average still means many more serious disclosures in absolute terms.
  • 18 Windows CVEs with documented AI-assisted discovery credit. This is a source-verified set of examples. It is not an estimate of AI's share of discoveries.
  • Release days in one year: 69 for Microsoft Edge, 64 for Chrome and 61 for Visual Studio Code. Three major vendors announced shorter release cycles during the study.
  • No whole-cohort repair-time average. None of the 4,058 CVEs in the complete 36-month window has a usable structured notification-to-fix date pair.

How to read the numbers

The study is descriptive, and its limits matter as much as its results.

  • It does not claim a cause. The paper's conclusion is that AI contributes to the change, but its share, a universal discovery-speed multiplier and any proportional change in compromise risk remain unmeasured.
  • The date is a Microsoft reporting date. Each CVE is dated by its earliest valid revision in Microsoft's monthly security update documents. That is a disclosure proxy, not an observed discovery date or a customer patch-installation date.
  • October 2026 is a partial month. It runs to the 26 October evidence cutoff and is reported separately from the three complete years.
  • The release panel is small on purpose. Six application release streams illustrate different packaging patterns. They do not represent all Windows software, and a release day is availability, not a mandatory deployment.
  • Volume does not convert to workload. Growth in disclosures cannot be turned into the same percentage increase in packages, downloads, reboots or staff hours.

The paper also declares its interests. EfficientEther develops and sells EtherApps Forge, and the study does not evaluate EtherApps Forge or any other commercial product.

Who it is for

If you run patching, endpoint management or application packaging at an organisation of 50 to 600 users, or you do it for several customers as an MSP, the paper gives you three things to take into your next planning conversation.

  1. A defensible baseline. Complete-year cohorts with explicit rules, so you can stop quoting raw CVE totals that mix products, dates and partial months.
  2. A reason to separate release intake from packaging work. The paper proposes continuous release intake, separate lanes for fast, predictable and sparse release streams, evidence that each update is running, and automation for execution while people own what is tested, what counts as a pass and which exceptions are acceptable.
  3. Evidence you can forward. A citation and an analytical supplement let a change board, a finance lead or a customer check the numbers rather than take our word for them.

Where EtherApps Forge fits

EtherApps Forge captures Windows applications on the machines where they already run and turns them into signed MSIX, MSI, Intune and App Attach packages for Microsoft Intune, Windows 365 and Azure Virtual Desktop. That is the packaging side of the work this research describes. If you are deciding how much of a faster vendor release stream your team should package centrally, MSIX packaging and deployment and application modernisation and migration cover the route. Our earlier research on 3,261 automated MSIX packaging cases and the state of application packaging in 2026 sits alongside this study.

Cite as: Mangan, R. (2026). Windows Patching, AI-Assisted Discovery and Application Assurance: A 36-Month Descriptive Study of Windows and Office CVEs, Application Release Cadence and Remediation Timing. Zenodo. https://doi.org/10.5281/zenodo.23780566

Get the Windows patching research and bring the numbers to your next patching and packaging planning meeting.