Nei primi otto mesi del 2026 le falle sfruttate sono già 141, più di tutto il 2025. Crescono soprattutto gli attacchi su bug già corretti, e l'IA accorcia il tempo tra la patch e l'attacco.
Quanti giorni passano tra l'uscita di una patch e il primo attacco che la sfrutta? Fino a poco tempo fa si parlava di settimane. Oggi, a volte, bastano quattro giorni.
I numeri di Google
Il Google Threat Intelligence Group (GTIG) ha messo in fila i dati del 2026. Tra gennaio e agosto le vulnerabilità divulgate e poi sfruttate in attacchi reali sono state 141. In tutto il 2025 erano state 127. In media si passa da 10,5 a 18 falle sfruttate al mese. Nello stesso periodo le segnalazioni di nuovi bug sono più che raddoppiate: circa 5.000 a gennaio, oltre 10.700 ad agosto. Parte della crescita dipende da come vengono assegnati i codici CVE nei progetti open source. Il kernel Linux, per esempio, compare in circa 5.000 segnalazioni, ma Google non ha registrato nessuno zero-day sfruttato.
Non è un'esplosione di zero-day
Google non parla di crescita esponenziale. Gli zero-day sfruttati, cioè le falle attaccate prima che esista una correzione, salgono da 8 a 11 al mese (con un picco di 22 ad agosto). La crescita vera riguarda gli attacchi n-day: bug già noti, spesso già corretti dal produttore, ma non ancora aggiornati sui sistemi delle aziende. Detto in modo semplice: la patch c'è, ma nessuno l'ha ancora installata.
Cosa c'entra l'intelligenza artificiale
Due cose. La prima: le falle trovate con l'aiuto dell'IA sono più pericolose. La metà permette l'esecuzione di codice da remoto (RCE): chi attacca fa girare comandi sulla macchina senza toccarla. Tra le altre falle questa quota si ferma al 26%. La seconda: i modelli linguistici sanno confrontare la versione vecchia e quella nuova di un software e capire cosa è stato corretto. Così il passaggio dalla patch all'exploit funzionante diventa più rapido. Il caso citato è CVE-2026-1731, una falla nei prodotti di accesso remoto di BeyondTrust scoperta in autonomia da un sistema di IA. GTIG ha visto i primi attacchi quattro giorni dopo la divulgazione. Entro una settimana altri cinque gruppi si erano aggiunti.
Il punto per le aziende
In proporzione, le falle sfruttate restano poche: circa una su 431. Il problema è capire quale, e farlo in fretta. Chi aggiorna una volta al mese, con calma, lavora con tempi che gli attaccanti hanno già superato. Questo vale soprattutto per quello che è esposto su Internet: VPN, firewall, strumenti di accesso remoto.
Fonte: Red Hot Cyber
La tua azienda è pronta ad affrontare una minaccia come questa?
Richiedi una valutazione gratuita →
Il numero che mi è rimasto in testa non è 141. È quattro: i giorni tra la divulgazione della falla BeyondTrust e i primi attacchi. Aggiornare una volta al mese, in una finestra di manutenzione fissa, è una scelta molto diffusa e ha le sue ragioni: aggiornare in fretta a volte rompe qualcosa, e un gestionale fermo il lunedì mattina è un danno vero, non teorico. Però, a guardare questi dati, usare lo stesso ciclo mensile per tutto mi sembra sempre meno difendibile. Secondo me la strada più realistica è dividere. Da una parte una corsia lenta per i sistemi interni. Dall'altra una corsia veloce, di giorni e non di settimane, per tutto ciò che è esposto su Internet: VPN, firewall, accesso remoto, portali web. Spesso il primo ostacolo non è nemmeno tecnico. Manca una lista aggiornata di cosa è esposto, e senza quella lista non sai neanche cosa mettere nella corsia veloce.
Resta un dubbio che non so sciogliere del tutto, soprattutto se penso alle piccole realtà che non hanno un sistemista a tempo pieno. Se l'IA continua ad accorciare il tempo tra la patch e l'attacco, fino a che punto è ragionevole chiedere a un'azienda di dieci persone di stare al passo? E quanta parte di questo peso dovrebbero invece prendersi i produttori, con aggiornamenti automatici e più sicuri? Se vuoi capire quali dei tuoi sistemi esposti meritano la corsia veloce, posso aiutarti a farne l'elenco e a fissare tempi di aggiornamento che la tua azienda riesca davvero a rispettare.