trueNetLab logo
IT
Patchday nell'era dell'IA: il ritmo aumenta

Patchday nell'era dell'IA: il ritmo aumenta

11 min read
Ai Security Network

Il Patch Tuesday di giugno di Microsoft sembrava quasi assurdo: oltre 500 CVE, un mese record e la domanda inevitabile se i grandi modelli di IA siano ormai stati messi al lavoro sul software e stiano trovando vulnerabilità ovunque.

La mia prima reazione è stata la stessa. 500 non sembra solo un Patch Tuesday grande. Sembra un punto di svolta.

Dopo la ricerca, la mia lettura è più sobria, ma anche più interessante: sì, giugno 2026 è stato davvero un mese record. No, il numero 500 non significa “500 nuove falle Microsoft che gli admin Windows dovevano patchare quel martedì”. E sì, l’IA è molto probabilmente parte del nuovo ritmo. Ma la domanda importante non è se il numero esatto sia 500.

La domanda importante è: cosa succede alle operation IT quando la scoperta delle vulnerabilità accelera in modo permanente?

Se questo ritmo continua a crescere, il secondo martedì del mese non sarà più l’unico giorno dei patch.

Cosa è successo davvero a giugno

Il 9 giugno 2026 Microsoft ha pubblicato un aggiornamento di sicurezza insolitamente grande. A seconda della fonte e del metodo di conteggio, le CVE Microsoft erano circa tra 198 e 209. Rapid7 ne ha contate 200, CrowdStrike 206, ZDI 208, Sophos ha parlato di 209 patch.

Le differenze sono interessanti sul piano metodologico, ma non sono il cuore del problema. Che il numero finale sia 198, 200, 206 o 209 CVE Microsoft cambia poco nella pratica. Anche il conteggio più stretto era eccezionalmente alto.

Ivanti ha definito 198 CVE Microsoft un nuovo record, ricordando che ottobre 2025, con 175 CVE, era il precedente massimo. Anche ZDI ha scritto che giugno è stato il Patch Tuesday più grande da quando segue questi release.

Non era quindi un nulla gonfiato artificialmente. Era un vero outlier. Proprio per questo non dovremmo trattarlo solo come una discussione sui numeri.

La tendenza più interessante è questa: arrivano più finding, più fonti, più linee di prodotto coinvolte, più aggiornamenti browser e più software di terze parti da seguire nello stesso momento. Patch Tuesday diventa meno un evento singolo e più un picco visibile in un flusso continuo.

Perché il numero 500 va comunque spiegato

Il numero 500 non è irrilevante. Mostra quanto è diventato grande l’ecosistema dei patch. Ma va spiegato, altrimenti porta a decisioni sbagliate.

Sophos lo ha formulato bene: 209 patch più 388 advisory. ZDI arriva a 571 CVE includendo Chromium e altri componenti di terze parti. Ivanti ha scritto che Chrome ed Edge hanno affrontato oltre 500 CVE nella settimana del Patch Tuesday.

È drammatico. Ma operativamente va separato.

Una grande parte di quel numero viene da Edge e Chromium. Rapid7 ha scritto che Microsoft aveva già affrontato 360 vulnerabilità browser a giugno e che non facevano parte del conteggio Patch Tuesday vero e proprio. Sophos ha spiegato inoltre che i 388 advisory erano soprattutto legati a Edge, provenivano per lo più da Chrome e spesso erano già stati patchati prima del Patch Tuesday.

Si sono aggiunti anche gli update Adobe. ZDI e Ivanti hanno citato 123 CVE Adobe in undici aggiornamenti. Sophos ha incluso Adobe e altri advisory nella propria vista Patch Tuesday.

Il punto centrale è:

  • Patch Tuesday Microsoft in senso stretto: circa 198-209 CVE Microsoft.
  • Ecosistema browser: diverse centinaia di CVE Edge/Chromium, alcune già rilasciate prima.
  • Terze parti: tra cui Adobe, con molte CVE proprie.
  • Totale combinato: un numero molto grande, ma metodologicamente misto.

Per gli admin questa distinzione è decisiva. Un Windows Server, un client Edge, Adobe Reader, lo stato delle firme Defender e un componente cloud non sono la stessa attività di patching.

Ma non bisogna fermarsi al conteggio pulito. Anche dopo la separazione resta la tendenza: c’è di più da osservare, valutare e aggiornare.

La tendenza conta più del numero esatto

Non dovremmo ripetere il 500 senza contesto. Ma non dovremmo neppure liquidarlo.

Il dato operativo è più forte: anche il conteggio Microsoft più stretto era vicino al record o da record. E fra i fix di giugno c’erano temi che non si spostano con leggerezza alla prossima finestra di manutenzione.

ZDI ha evidenziato, tra l’altro, una falla Defender sfruttata attivamente. CrowdStrike ha descritto diverse vulnerabilità pubbliche o particolarmente critiche, tra cui HTTP.sys, Windows Kernel, DHCP Client Service e Active Directory Domain Services. Rapid7 ha scritto che Microsoft ha documentato pubblicamente un problema DoS HTTP/2 in HTTP.sys e corretto anche una RCE HTTP.sys con CVSS 9.8.

Quindi, anche se la headline dei 500 è metodologicamente ampia, giugno resta un mese in cui la triage conta davvero.

Guardare solo il totale fa vedere troppo e troppo poco insieme: troppo, perché browser e terze parti gonfiano la percezione; troppo poco, perché le domande importanti non stanno nel totale:

  • La vulnerabilità è sfruttata attivamente?
  • È pubblica?
  • È colpito un servizio esposto a Internet?
  • Esiste un proof-of-concept?
  • Colpisce server, client, identità, browser o software terzi?
  • Il componente si aggiorna da solo o richiede un rollout pianificato?

È qui che un buon patch management si separa dal panico da CVE.

E cosa c’entra l’IA?

Qui diventa interessante, ma bisogna restare precisi.

A maggio 2026 Microsoft ha detto chiaramente che l’IA sta cambiando velocità e scala della scoperta di vulnerabilità. In un post MSRC, Microsoft ha scritto che sia i team interni sia la security community usano sempre più IA per esaminare il software più spesso e più a fondo. Microsoft ha anche detto che release Patch Tuesday più grandi saranno probabilmente normali per un po'.

Microsoft è stata ancora più concreta parlando di MDASH, il proprio multi-model agentic scanning harness. Il sistema usa oltre 100 agenti specializzati che analizzano codice, discutono finding, li deduplicano e in alcuni casi costruiscono prove. Microsoft indica 16 CVE trovate dai team con MDASH per il Patch Tuesday di maggio.

Questa è una prova forte che l’IA non è più solo un giocattolo di ricerca. È arrivata nella vulnerability discovery.

L’IA è un acceleratore provato nel quadro generale, anche se non spiega da sola il record di giugno.

Ma questo non prova che il record di giugno sia stato causato dall’IA.

Per giugno ci sono segnali concreti, ma puntuali. Rapid7 scrive che per CVE-2026-49160, una DoS in HTTP.sys, Microsoft accredita anche OpenAI Codex tra gli scopritori. È notevole perché è un’attribuzione IA a livello di singola CVE.

Quello che non vedo nelle fonti è una dichiarazione solida di Microsoft del tipo: “giugno è stato così grande perché X percento delle CVE è stato trovato dall’IA”. ZDI pone la stessa domanda e nota che Microsoft non sta dando quelle risposte.

La mia lettura è quindi: l’IA è un acceleratore dimostrato, visibile in alcuni finding e probabilmente parte della nuova realtà di volume. Ma non è provata come causa unica o principale del numero 500 di giugno.

È meno spettacolare di “l’IA trova 500 falle Microsoft”. Ma è più onesto.

E per le operation questa versione è già abbastanza scomoda. Se l’IA aiuta a esaminare codice più velocemente, trovare varianti prima e riscoprire vecchi pattern, aumentano i report e diminuisce il tempo per reagire dopo un fix.

Perché i browser distorcono i numeri

La parte browser è forse la più pratica di tutta la storia.

Molte organizzazioni pensano ancora al Patch Tuesday come evento mensile: Microsoft pubblica, si testa, si distribuisce, si documenta. Per Windows e server classici vale ancora in parte.

I browser funzionano diversamente. Chrome, Edge, Firefox e altri seguono una logica più continua. Se Chrome corregge centinaia di CVE il 3 giugno ed Edge segue come browser Chromium, questo entra nella settimana security di giugno. Ma non è lo stesso lavoro di una patch Exchange, Windows Kernel o AD DS.

Per MSP e admin servono quindi due numeri: quello stretto di Patch Tuesday per i prodotti Microsoft nel processo classico, e quello di ecosistema per browser, Adobe, componenti security, developer tools e software terzi.

Entrambi sono utili. Mescolarli crea decisioni sbagliate.

Meno strumenti locali è anche una strategia di sicurezza

Proprio per questo cerco di installare sul mio Mac il minor numero possibile di tool locali.

Può sembrare minimalismo. Per me è soprattutto patch management. Ogni tool aggiuntivo è altro codice da mantenere, con dipendenze, update mechanism, permessi, a volte auto-updater, servizi in background, estensioni browser o helper locali.

Ogni componente apre tre domande scomode:

  • Lo sviluppatore sa della vulnerabilità?
  • Esiste già una patch?
  • La patch arriva davvero fino a me?

Se un’app non è più mantenuta, la migliore lista CVE serve a poco. Forse saprò che qualcosa è vulnerabile, ma non se verrà corretto bene.

Per questo preferisco webapp ad app locali dove ha senso. Non è automaticamente più sicuro: anche una webapp può avere problemi. Ma la responsabilità del patch è più dal lato del provider, e io riduco programmi installati, updater e superfici d’attacco locali.

Non è una regola religiosa. Alcuni tool locali sono indispensabili, soprattutto in networking e security. Ma voglio una ragione per ogni tool. “Nice to have” mi convince sempre meno mentre aumenta la velocità delle patch.

Patching come attività continua

Giugno 2026 non mostra solo che ci sono più CVE. Mostra che la vecchia mentalità mensile diventa fragile.

Oggi penserei al patch management in quattro corsie: aggiornamenti Microsoft classici per Windows, Office, ruoli server, Exchange, SharePoint e Active Directory; browser e web client in aggiornamento continuo; componenti security come Defender, dove bisogna verificare l’auto-update; e software terzi come Adobe, PDF tools, client VPN, remote tools, app di comunicazione e utility.

Serve più struttura. È proprio questo il punto.

Se l’IA accelera la discovery, non basta cliccare più velocemente su “installa”. Serve triage migliore.

La domanda migliore non è “quante?”

Il numero conta, ma non è la domanda più importante.

Per admin e MSP valgono di più queste domande:

  • Quali sistemi sono esposti a Internet?
  • Quali vulnerabilità sono sfruttate attivamente o documentate pubblicamente?
  • Quali update toccano identità, accesso remoto o servizi server?
  • Quali prodotti si aggiornano da soli e quali no?
  • Quali fix richiedono riavvii o finestre di manutenzione?
  • Quali sistemi restano bloccati da legacy, dipendenze applicative o mancanza di finestre?
  • Dove bisogna cercare sfruttamento anche dopo il patching?

Microsoft raccomanda questa direzione nel post MSRC: non priorizzare in base al numero grezzo, ma in base a exposure, impact, exploitability e sfruttamento reale.

Forse è la lezione più importante di giugno.

Il numero grezzo diventa più rumoroso. La triage deve migliorare.

Cosa ne porto su trueNetLab

Vedo il Patch Tuesday di giugno come il lato operativo degli ultimi temi AI-security.

In Anthropic Mythos e Project Glasswing la domanda era quanto bene i modelli possano trovare vulnerabilità. Nell’articolo sui bug bounty il punto era che i team security avranno bisogno di prove più dure, perché aumentano sia i buoni finding sia l’AI slop.

Il Patch Tuesday di giugno mostra ora il lato operativo: più vulnerabilità trovate, più fonti che contano diversamente, più componenti aggiornati fuori dalla logica classica di Patch Tuesday, e più tentativi di trasformare un numero grande in una storia semplice.

La storia semplice sarebbe: l’IA trova ora 500 falle Microsoft al mese.

La storia migliore è: la vulnerability discovery diventa più veloce, più ampia e più difficile da comunicare. L’IA ne fa parte. Browser e terze parti ne fanno parte. Una metodologia di conteggio migliore ne fa parte. E per gli admin diventa più importante trasformare un numero in un piano patch affidabile.

Per me c’è anche un punto personale: la migliore vulnerabilità è quella che non devo eseguire localmente. Meno tool, meno superficie d’attacco locale, meno catene di update, meno residui silenziosi. Non è sempre comodo, perché bisogna dire no più spesso ad app interessanti. Ma in un mondo in cui aumenta il ritmo dei patch, questa disciplina vale di più.

La mia conclusione

500 CVE a giugno sono un buon segnale d’allarme, ma non una buona unità operativa.

Chi ne fa panico non aiuta. Chi lo liquida come trucco di conteggio perde il trend. La verità sta nel mezzo: giugno 2026 è stato davvero enorme per Microsoft, ma la headline dei 500 descrive un ecosistema patch ampio, non solo patch Microsoft. L’IA accelera dimostrabilmente la vulnerability discovery, ma per il picco di giugno è un fattore plausibile più che una causa unica provata.

Per me la conseguenza è chiara: il patch management deve sembrare meno un rito mensile e più una gestione continua del rischio.

Non ogni CVE è ugualmente urgente. Ma il tempo in cui i grandi patchday potevano essere gestiti come routine mensile si accorcia.

E forse questa è la vera lezione di giugno: non ogni giorno è già un patchday. Ma ci stiamo muovendo chiaramente in quella direzione.

Alla prossima,
Joe

Fonti