Il volume delle CVE di Windows nel 2026: cosa dovrebbero misurare i team che si occupano di patching

Nei tre anni completi della nostra nuova ricerca, le CVE distinte di Windows e Office sono passate da 679 a 941 a 2.438 (+38,6 %, poi +159,1 %), mentre il punteggio di base CVSS v3 medio è passato da 7,43 a 7,37 e poi a 7,28. È un carico in ingresso molto più grande con una gravità media che non è salita, ed è per questo che un conteggio grezzo delle CVE è un cattivo modo di gestire un programma di patching. Questo articolo passa in rassegna cosa dicono i numeri, come è stata costruita la coorte, cosa misurare al loro posto e cosa lo studio non ha potuto misurare. La ricerca è redatta dall'azienda e non è stata sottoposta a revisione paritaria. L'abbiamo presentata il 2 novembre, e il documento completo è disponibile dalla pagina di registrazione.

Cosa dicono i numeri annuali

Il documento confronta tre anni completi non sovrapposti, ciascuno da ottobre a settembre, in modo che nessun mese incompleto falsi il confronto.

CVE distinte di Windows e Office nelle tre coorti annuali complete del documento. Windows e Office si sovrappongono, quindi l'unione è deduplicata e i due conteggi non vanno sommati.

L'impennata non è distribuita in modo uniforme. Il documento la rileva concentrata tra metà e fine 2026: luglio ha avuto 483 CVE, agosto 316 e settembre 819, contro una mediana di 69 al mese sui 36 mesi completi. Ottobre 2026 contribuisce già con 1.277 CVE di Windows e Office fino alla data limite del 26 ottobre, di cui 1.114 record del sistema operativo Windows. Sono totali mensili di divulgazione rivisti, che comprendono record fuori ciclo, quindi non vanno equiparati a una notizia di stampa che conta soltanto il rilascio originale del Patch Tuesday. Il documento non proietta un singolo mese in una previsione annuale e non rivendica alcun test di significatività né alcun punto di rottura causale.

Negli ultimi 12 mesi di riferimento (da novembre 2025 a ottobre 2026, con ottobre parziale) la coorte contiene 3.565 CVE, circa 297,1 per mese di riferimento. La divisione per 12 descrive il flusso per mese di riferimento e non annualizza ottobre. La verifica sui mesi completi fino a settembre 2026 dà 2.438 CVE su 12 mesi, 3.379 su 24 e 4.058 su 36.

La gravità media non è salita

La media non supporta un aumento generale della gravità di base media, ma non significa nemmeno che il rischio sia diminuito. Il numero assoluto di divulgazioni gravi può crescere mentre la loro media resta stabile: nell'ultimo anno, 1.841 dei 2.436 record con punteggio (75,6 %) ottengono almeno 7, e 60 ottengono 9,0 o più. Il documento tratta il CVSS come una scala di gravità e la sua media come una sintesi descrittiva, non come una perdita finanziaria attesa né come una probabilità di compromissione. Le etichette Critical assegnate dai fornitori sono una classificazione diversa e sono riportate separatamente.

Lo studio associa inoltre ogni CVE al catalogo Known Exploited Vulnerabilities della CISA. L'appartenenza al catalogo nelle tre coorti annuali è pari a 29, 25 e 21 alla data limite. Il documento lo definisce una sezione trasversale descrittiva, non una prova che lo sfruttamento stia diventando meno comune: il tempo di osservazione differisce, la copertura del catalogo è incompleta e un denominatore in espansione può abbassare meccanicamente la quota osservata.

Come è stata costruita la coorte

Il metodo è volutamente prudente, e ogni passaggio è visibile nel documento.

1. Fonte. 37 documenti CVRF mensili del Microsoft Security Response Center, da ottobre 2023 a ottobre 2026, conservati con marche temporali e hash SHA-256.
2. Pulizia. Sono state escluse sette righe di avvisi non CVE e 48 identificatori CVE esplicitamente rifiutati. Le righe ripetute di versioni di prodotto sono state ridotte a un solo record per CVE.
3. Ambito delimitato. Client Windows numerati e prodotti Windows Server, più le applicazioni Office desktop, con un elenco esplicito di prodotti consentiti. I totali su tutti i record del Microsoft Security Response Center non sono la misura principale perché comprendono anche Azure Linux, servizi cloud e componenti upstream.
4. Una data per CVE. La data della prima revisione valida. Il documento precisa che è un indicatore di divulgazione ricavato dalle segnalazioni di Microsoft, non una data di scoperta osservata, una data di pubblicazione globale o una data di installazione della patch.
5. Un punteggio per CVE. Il punteggio di base CVSS v3.x applicabile più alto osservato tra le revisioni conservate. I punteggi mancanti sono esclusi dalla media e dal suo denominatore, e i punteggi CVSS v4 e temporali non vengono mescolati.
6. Associazione con lo sfruttamento. Appartenenza al CISA KEV in base all'identificatore CVE, usando la versione 2026.10.23 del catalogo.
7. Mesi parziali. Gli anni completi vanno da ottobre a settembre. Ottobre 2026 è riportato a parte e non è mai trattato come un mese concluso.

Controlli automatizzati hanno confermato i 37 documenti attesi, l'assenza di CVE e chiavi di ambito duplicate, intervalli di punteggio validi e conteggi mensili che si riconciliano con i totali delle coorti. Un confronto su sei record con NVD e con l'API CVE Services è un controllo di coerenza, non una replica indipendente, e NVD non è usato come unico denominatore dei prodotti con punteggio perché il suo arretrato del 2024 e un cambio della politica di arricchimento di aprile 2026 creano una discontinuità di copertura. Secondo il documento, il supplemento analitico contiene le tabelle a livello di CVE e delle coorti mensili, l'audit dell'ambito dei prodotti, i record esclusi e rifiutati, gli eventi di rilascio delle applicazioni e le serie mensili, il dataset di 17 righe sui tempi di remediation con il relativo file di copertura, i registri delle evidenze e un manifest SHA-256, con gli script di analisi inclusi.

Sei flussi di rilascio di applicazioni

I team di pacchettizzazione non applicano le patch secondo un unico calendario, quindi il documento aggiunge un pannello scelto di proposito di sei flussi di rilascio: Chrome, Edge, Firefox, Visual Studio Code, Notepad++ e 7-Zip. Un giorno di rilascio è una data distinta in cui è stata pubblicata una versione di un'applicazione. Nell'ultimo anno completo il pannello va da 69 giorni di rilascio per Edge, 64 per Chrome e 61 per Visual Studio Code, passando per 44 per Firefox e 17 per Notepad++, fino a 4 per 7-Zip. I mesi di punta sono più affollati di quanto queste medie lascino intendere: Visual Studio Code ha raggiunto nove giorni di rilascio in un solo mese.

Nei 36 mesi completi i sei flussi hanno prodotto 661 giorni di rilascio specifici delle applicazioni. Il pannello non è un campione rappresentativo del software Windows, le popolazioni di CVE e di rilasci differiscono, e il documento precisa che i conteggi non vanno moltiplicati tra loro né letti come una relazione causale. I giorni di rilascio descrivono disponibilità e opportunità di monitoraggio, non distribuzioni obbligatorie né ore di pacchettizzazione.

Cosa misurare al posto del conteggio delle CVE

Il documento le propone come misure di gestione, non come valori ricavati dai totali delle CVE.

• Tempo alla protezione verificata: dalla disponibilità della correzione del fornitore applicabile alla protezione confermata, compresi riavvii del browser, riavvii delle macchine e nuove scansioni. Riportate la mediana e il percentile 90, oltre a installazioni non riuscite, tasso di rollback e scadenza delle eccezioni.
• Ritardo tra rilascio e decisione, e tra rilascio e protezione per ogni applicazione e canale.
• Impegno di qualifica: transizioni di versione selezionate al mese, build centralizzate degli artefatti, e durata mediana e al percentile 90 della qualifica.
• Rilavorazioni: quota di emergenze, tasso di errori e rilavorazioni, e arretrato dei malfunzionamenti degli updater.
• Esposizione: l'età degli aggiornamenti di sicurezza applicabili in sospeso, insieme alle istanze KEV esposte e alla loro età, agli asset non supportati e all'arretrato per importanza del servizio.

Alla base di tutte queste misure c'è un inventario con versioni, in modo che una CVE venga associata agli asset installati ed esposti prima che la coda di remediation cresca. Tenete separati i conteggi delle CVE dalle istanze sui dispositivi e dall'impegno di distribuzione.

Cosa lo studio non ha potuto misurare

• Una media dei tempi di correzione sull'intera coorte. Ognuna delle 4.058 CVE della finestra completa ha una marca temporale di revisione valida, ma nessuna data di scoperta o di rilascio specificata. Tutte le 98.265 righe di remediation applicabili riportano la data sentinella dell'anno 0001 con DateSpecified=false. Esistono voci di correzione del fornitore per tutte le 4.058 CVE, voci di workaround esplicite per cinque e voci di mitigazione per 66, quindi non c'è alcuna coppia di date strutturata utilizzabile. Le date mancanti non sono ritardi pari a zero.
• Un unico orologio. I casi datati, come tre intervalli di 61, 71 e 81 giorni tra segnalazione privata e rilascio per PHP e NGINX, usano eventi di inizio e fine diversi e sono riportati separatamente, non raggruppati in una media.
• La gravità di ogni CVE dei browser. Solo 240 dei 2.931 record legati a Edge (8,2 %) riportano un punteggio CVSS v3 numerico applicabile in questa estrazione, quindi la media di quel gruppo non può rappresentare tutte le CVE dei browser.
• Cosa hanno visto gli amministratori il giorno stesso. I file mensili storici sono modificabili e i punteggi possono cambiare dopo la divulgazione iniziale. Lo snapshot consente di replicare lo studio, non di recuperare gli stati precedenti delle fonti.

Il ruolo di EtherApps Forge

Lo studio non valuta EtherApps Forge né alcun prodotto commerciale, ed EfficientEther dichiara nel documento il proprio interesse in EtherApps Forge. Il legame è il lavoro che questi numeri generano. Quando i rilasci dei fornitori arrivano più in fretta, la domanda sulla pacchettizzazione diventa quali applicazioni pacchettizzare in modo centralizzato e con quale rapidità potete qualificare ogni nuova versione. EtherApps Forge acquisisce le applicazioni Windows dove già vengono eseguite e crea pacchetti MSIX, MSI, Intune e App Attach firmati, che è il lato pacchettizzazione di quella routine. Modernizzazione e migrazione delle applicazioni e modernizzazione delle applicazioni legacy riguardano le applicazioni più vecchie, le più difficili da mantenere aggiornate, e il nostro studio precedente su 3.261 casi di pacchettizzazione MSIX automatizzata mostra come separiamo la creazione del pacchetto dalle evidenze di avvio e di test.

Ottenete la ricerca sul patching di Windows per le tabelle complete, il metodo e le misure che il vostro team può adottare.