Sommario
Servizi & Sistemi Linux
Domini, hosting, PEC, infrastruttura email, servizi di rete e sistemi Linux. Assistenza e gestione dell'infrastruttura Open Source.
Scopri →
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
CyberAgent
Vulnerability assessment continuo e gap analysis: scansione, mappatura sui requisiti, evidenze documentali pronte.
Scopri CyberAgent →
Cosa è successo fra il 19 e il 20 luglio
Domenica 19 e lunedì 20 luglio la lista linux-cve-announce ha riversato 432 identificativi CVE in poco più di ventiquattro ore. Alcuni tracker, contando anche le aggiunte del giorno successivo, arrivano a 440. Le voci coprono buona parte dei sottosistemi: rete, Bluetooth, storage, gestione della memoria, virtualizzazione, grafica, wireless, driver di periferica, filesystem.
A notarlo per primo è stato nixCraft, lunedì mattina. Martedì 21 il sysadmin Jan Schaumann ha aperto un thread sulla mailing list oss-security con una tesi netta: “this onslaught really shows it’s not feasible to attempt to prioritize individual kernel changes”. Ha messo in fila le opzioni realistiche e le ha bocciate una per una: usare un LLM per dare priorità in base al proprio ambiente (ma le CVE continuano ad arrivare), aspettare che una vulnerabilità riceva un logo e un nome accattivante prima di muoversi, oppure aggiornare tutto ogni settimana su tutta la flotta.
Greg Kroah-Hartman ha risposto mercoledì 22. Primo punto, di merito: non era un’ondata di vulnerabilità nuove, era una coda di review pubblica smaltita in blocco dopo “a perfect storm of 6 weeks straight of conferences and vacations”. Secondo punto, di prospettiva: “The number of llm-found issues is only on the rise right now, it’s going to be a very long 18 months at the least to dig ourselves out of this mess”.
Perché il kernel produce così tante CVE
Da febbraio 2024 il progetto è CNA, cioè assegna da sé i propri identificativi. La politica dichiarata è deliberatamente prudente: al livello a cui gira il kernel quasi ogni bug che tocca un sistema in esecuzione può essere sfruttato per comprometterlo, quindi il team assegna un CVE a ogni fix che entra nelle stable e che rientri nella definizione di vulnerabilità del CVE Program.
Il risultato è aritmetico. Nel 2024 il kernel ha pubblicato 4.325 CVE, terzo CNA al mondo per volume. Nel 2025 è passato al primo posto, a un ritmo di circa cinquanta CVE a settimana. Quella è la linea di base, e la coda smaltita in quarantotto ore ne è solo la forma più visibile.
Lo stesso mese, Microsoft e Oracle
Il 14 luglio Microsoft ha chiuso un Patch Tuesday da 570 vulnerabilità, una sessantina classificate critiche e tre zero-day, due dei quali già sfruttati in attacchi. È quasi il triplo del mese precedente, che era a sua volta un record. L’azienda ha attribuito il salto in modo esplicito: “The pace of vulnerability discovery is changing with advances in AI making it possible to find more issues, faster, across more code”, ha dichiarato Pavan Davuluri, executive vice president. I conteggi di terze parti che includono anche le CVE dei componenti esterni, Chromium in testa, superano quota 620: la cifra cambia con il metodo di conteggio, l’ordine di grandezza no.
Il 21 luglio Oracle ha pubblicato il Critical Patch Update più grande della sua storia: 1.449 patch per 1.235 CVE uniche, 261 delle quali critiche, distribuite su centinaia di prodotti. Le concentrazioni maggiori sono in E-Business Suite (410 patch), Fusion Middleware (355) e Communications (168).
Per contrasto, nello stesso mese SAP ha rilasciato sedici note di sicurezza nuove e il bollettino Android ne ha coperte cinquantasette. La differenza non sta nel rigore dei team: sta nell’estensione del codice e in quanti strumenti automatici lo stanno battendo.
Il motore comune
Il 17 maggio 2026, nell’annuncio di Linux 7.1-rc4, Linus Torvalds ha definito la mailing list privata di sicurezza del kernel “almost entirely unmanageable”. Il numero racconta tutto: da due o tre segnalazioni a settimana di due anni prima a cinque o dieci al giorno, con ricercatori diversi che usano gli stessi strumenti AI, trovano gli stessi bug nello stesso momento e li segnalano in parallelo, a volte per problemi già corretti da mesi. La contromisura è procedurale: un bug trovato con strumenti AI va trattato come disclosure pubblica e mandato direttamente ai maintainer del sottosistema, non alla lista privata.
Vale la pena registrare cosa Kroah-Hartman non dice. Non parla di slop: già a marzo aveva osservato che la qualità dei report assistiti da AI era cresciuta parecchio negli ultimi mesi. Il problema non è la qualità delle segnalazioni, è il loro numero.
A giugno FIRST ha rivisto al rialzo la previsione per l’anno: circa 66.000 CVE nel 2026, dopo che le disclosure effettive erano finite oltre il 45% sopra le proiezioni iniziali. Nella nota del 15 giugno l’organizzazione indica fra i motori gli agenti di ricerca vulnerabilità di ultima generazione, citando Mythos di Anthropic e GPT-5.4-Cyber di OpenAI. Sono gli stessi strumenti che, dall’altra parte del tavolo, hanno già portato a termine un’intrusione autonoma.
A valle il NVD ha già smesso di analizzarle tutte
Il 15 aprile 2026 il NIST ha annunciato che il National Vulnerability Database non arricchirà più tutte le CVE. Punteggio di severità, prodotti affetti e CPE vanno ora a tre categorie: le CVE nel catalogo KEV della CISA, entro un giorno lavorativo; quelle su software usato dal governo federale; quelle su critical software ai sensi dell’Executive Order 14028. Tutto il resto finisce in lowest priority: resta nel database e resta indicizzato, senza analisi, con arricchimento su richiesta via email.
I numeri che motivano la scelta sono gli stessi visti finora. Nel 2025 il NVD ha arricchito quasi 42.000 CVE, il 45% in più di qualunque anno precedente. Le submission sono cresciute del 263% fra il 2020 e il 2025. Il primo trimestre 2026 è arrivato circa un terzo sopra lo stesso periodo dell’anno prima. Circa 29.000 CVE arretrate con data anteriore al 1 marzo 2026 sono state spostate in Not Scheduled.
Per chi ha costruito il proprio processo di vulnerability management su severity e prodotti affetti letti dal NVD, questa è la notizia operativamente più pesante delle tre.
La risposta del kernel: aggiornare sempre
La posizione di Kroah-Hartman è coerente da anni e nel thread è tornata secca: aggiornate. “This is what the kernel developer community recommends and supports. If you want support from us, do this. If you can’t do this, then pay a company to provide the needed support.”
Il passaggio più interessante è però un altro. Sul selezionare a mano le patch da applicare, Kroah-Hartman scrive che “this is going to be legislated away, and rightfully so”, con riferimento esplicito al Cyber Resilience Act. Tradotto: la scelta discrezionale di quali fix installare sta per diventare, in Europa, materia di conformità. Le date sono note e vicine, gli obblighi di reporting del CRA si applicano dall’11 settembre 2026 mentre SBOM e requisiti essenziali arrivano l’11 dicembre 2027.
Chiude citando Halvar Flake: “Software was never designed for perfect security, that choice is now catching up with us.”
Cosa cambia per chi gestisce sistemi
Il numero di CVE aperte ha smesso di essere una misura utile del rischio, e la singola CVE ha smesso di essere un’unità di triage sensata. Quattro conseguenze pratiche.
1. L’aggiornamento continuo diventa il default. Su un parco Linux significa kernel stable o LTS della distribuzione, finestre di reboot pianificate e livepatch dove il fermo macchina costa. Su questi volumi il triage per singola CVE costa più del deploy, ed è un calcolo che ormai si fa da sé.
2. Serve sapere cosa gira davvero. Senza inventario, la domanda “siamo esposti?” non ha risposta a nessuna velocità. È la ragione per cui SBOM e provenienza passano da buona pratica a infrastruttura: il CRA li renderà obbligatori, ma servono prima, per rispondere in ore quando una dipendenza viene sfruttata sul serio.
3. La priorità si sposta dalla severity alla exploitability. Con il NVD che arricchisce solo una parte del flusso, il segnale utile arriva dal catalogo KEV, da EPSS e dall’analisi di raggiungibilità: quella CVE tocca una funzione che il vostro codice chiama davvero, su una macchina che espone davvero quel servizio? È il materiale che scanner come Trivy preparano, e che qualcuno deve comunque interpretare.
4. Le eccezioni vanno scritte. Dove il reboot non si può fare, la deviazione va documentata con motivazione, mitigazione compensativa e scadenza. Fra NIS2 e CRA, “non abbiamo aggiornato” senza un registro è una posizione difficile da sostenere davanti a un’autorità.
Cosa ne pensiamo
Il fatto nuovo di luglio non è che il kernel Linux abbia molte vulnerabilità: ne ha sempre avute, e Copy Fail ha mostrato in aprile che le più interessanti restano in circolazione per anni prima che qualcuno le guardi con gli occhi giusti. Il fatto nuovo è che la capacità di trovarle è cresciuta di un ordine di grandezza in diciotto mesi, mentre la capacità di leggerle, classificarle e distribuirle è rimasta quella di prima. Il collo di bottiglia si è spostato dalla scoperta al consumo, e il NVD che rinuncia all’arricchimento universale è la prima istituzione che lo certifica.
Per chi gestisce infrastruttura la conseguenza è concreta e in fondo liberatoria: smettere di trattare la lista delle CVE come una coda di lavoro. La coda vera è un’altra ed è fatta di tre cose. Un parco aggiornato con continuità, che è il mestiere dei nostri servizi e sistemi Linux, dove il valore sta nelle finestre di manutenzione e nei rollback provati, non nel leggere 432 changelog. Un inventario che regge una domanda posta di corsa. Un processo di eccezione che produce carta, perché fra dodici mesi qualcuno la chiederà.
Su quest’ultimo punto CyberAgent fa il lavoro tecnico ripetitivo: scansione continua, mappatura delle vulnerabilità sui requisiti dei framework, evidenze documentali riproducibili. Come abbiamo già scritto a proposito di NIS2, non produce conformità automatica e non decide al posto vostro quali eccezioni accettare: riduce il lavoro manuale e rende ripetibile la parte che va dimostrata. La decisione su cosa aggiornare e quando resta una scelta di rischio, e va firmata da una persona.
C’è poi un ultimo punto, di sistema. Il CVE Program e il NVD sono infrastruttura pubblica su cui poggia l’intera industria della sicurezza, e stanno mostrando i limiti sotto un carico che nessuno aveva previsto quando sono stati progettati. È lo stesso schema che vediamo altrove: strumenti costruiti per un ordine di grandezza si trovano a reggerne un altro. Vale per il triage delle vulnerabilità, vale per le mailing list dei maintainer, vale per i team di sicurezza dei clienti che ci chiedono di dare un senso a un feed che nel 2026 conterà sessantaseimila voci.
Fonti
- oss-security: 432 Linux kernel CVEs, messaggio iniziale di Jan Schaumann
- oss-security: la risposta di Greg Kroah-Hartman
- The Register: Linux kernel team publishes 432 CVEs in two days
- The Register: Torvalds sulla mailing list di sicurezza del kernel
- LWN: the kernel becomes its own CNA
- LWN: how kernel CVE numbers are assigned
- Krebs on Security: Microsoft patches a record 570 security flaws
- Oracle Critical Patch Update Advisory, luglio 2026
- NIST: NVD updates operations to address record CVE growth
- Help Net Security: la previsione FIRST per il 2026
- Red Hot Cyber: gli sviluppatori Linux hanno pubblicato 432 CVE in due giorni