Le 8 vulnerabilità informatiche più devastanti della storia: quando un bug mette in crisi il mondo

Nel corso degli ultimi decenni la sicurezza informatica ha attraversato diverse fasi evolutive, scandite spesso da incidenti che hanno cambiato radicalmente il modo in cui software, infrastrutture e protocolli vengono progettati e utilizzati. Alcune vulnerabilità non si sono limitate a rappresentare un problema tecnico circoscritto: hanno generato effetti sistemici, costringendo aziende, governi e progetti open source a ripensare pratiche di sviluppo, patch management e difesa delle infrastrutture critiche.

Tra migliaia di CVE (Common Vulnerabilities and Exposures), identificativi con cui si fa riferimento a ogni singola vulnerabilità scoperta, solo una minima parte raggiunge il punteggio massimo di 10.0 nel CVSS (Common Vulnerability Scoring System), il sistema standard utilizzato nel settore della sicurezza informatica per misurare la gravità di ciascuna problematica.

Un punteggio CVSS pari a 10.0 rappresenta il livello di rischio più elevato e indica una vulnerabilità estremamente critica: può essere sfruttata da remoto attraverso la rete, non richiede autenticazione né alcuna azione da parte dell’utente e consente a un attaccante di ottenere il controllo completo dei sistemi colpiti o di compromettere totalmente l’integrità, la riservatezza e la disponibilità dei dati.

Cosa sono le vulnerabilità informatiche e perché rappresentano una minaccia reale

Ogni software, dal sistema operativo di un server fino alle applicazioni Web utilizzate quotidianamente, è composto da centinaia, migliaia o milioni di righe di codice. In questo enorme insieme di componenti è inevitabile che possano esistere errori di progettazione o di implementazione. Quando uno di questi difetti può essere sfruttato per compromettere la sicurezza di un sistema si parla di vulnerabilità informatica.

Una vulnerabilità è una debolezza tecnica che, se individuata e sfruttata da un aggressore, può trasformarsi in un vettore di compromissione. Gli aggressori informatici analizzano costantemente software, protocolli e infrastrutture alla ricerca di queste falle. Una volta scoperta una vulnerabilità, sviluppano un exploit, cioè un insieme di tecniche o codice progettato per sfruttare quella debolezza e ottenere un vantaggio sul sistema bersaglio.

Le vulnerabilità possono manifestarsi in forme molto diverse. Alcune derivano da errori nella gestione della memoria, come i buffer overflow, altre da problemi di configurazione, da errori logici nei meccanismi di autenticazione oppure da implementazioni difettose di protocolli di sicurezza.

Parlando di applicazioni Web sono comuni anche vulnerabilità legate alla gestione degli input, come SQL injection o cross-site scripting, mentre nei sistemi operativi e nei servizi di rete sono spesso presenti bug che permettono l’esecuzione di codice non autorizzato.

Le falle di sicurezza più pericolose: Remote Code Execution (RCE)

Tra tutte le categorie di vulnerabilità, quelle considerate più critiche sono le Remote Code Execution, comunemente indicate con l’acronimo RCE. Una vulnerabilità di questo tipo consente a un attaccante di eseguire codice arbitrario su un sistema remoto. In pratica, l’aggressore riesce a far eseguire al server o al dispositivo vittima istruzioni specifiche, ottenendo un livello di controllo che può variare dalla semplice esecuzione di comandi fino alla completa compromissione del sistema.

Un attacco RCE può avvenire in diversi modi. L’attaccante può inviare una richiesta appositamente costruita verso un servizio esposto su Internet, manipolare dati che sono elaborati dal software vulnerabile oppure sfruttare meccanismi di caricamento dinamico di librerie e risorse esterne.

Se il sistema esegue il codice malevolo con privilegi elevati, l’aggressore può installare malware, rubare dati sensibili, creare backdoor permanenti o utilizzare il dispositivo compromesso come punto di partenza per attacchi contro altre macchine nella stessa rete (il cosiddetto “movimento laterale“),

È proprio questa capacità di trasformare una semplice richiesta di rete in esecuzione di codice arbitrario che rende le vulnerabilità RCE particolarmente pericolose.

In molti casi, questi attacchi RCE non richiedono alcuna interazione da parte dell’utente e possono essere sfruttati automaticamente da malware o worm in grado di propagarsi rapidamente tra i sistemi vulnerabili.

Automatizzazione degli attacchi e scoperta di nuovi sistemi vulnerabili

Gli attaccanti spesso automatizzano l’intero processo di aggressione. Dopo la pubblicazione di una nuova vulnerabilità critica, è comune osservare scanner automatici che analizzano milioni di indirizzi IP alla ricerca di sistemi non aggiornati.

Nel caso di una vulnerabilità che apre ad attacchi RCE con un punteggio CVSS molto alto, lo sfruttamento può avvenire in pochi secondi se il dispositivo affetto dalla problematica di sicurezza è esposto sulla rete Internet. Questo è il motivo per cui molte grandi campagne di attacco iniziano poche ore dopo la divulgazione pubblica di una falla di sicurezza (o comunque a stretto giro).

Gli aggressori spesso effettuano il cosiddetto reverse engineering delle patch di sicurezza, una tecnica che consiste nell’analizzare in modo approfondito le modifiche introdotte dagli sviluppatori per correggere una vulnerabilità. Quando un vendor rilascia un aggiornamento, il codice modificato può rivelare indirettamente quale parte del software risultava vulnerabile e quale tipo di errore è stato risolto.

Attraverso strumenti di binary diffing e analisi del codice compilato, i ricercatori — e allo stesso modo gli attori malevoli — confrontano la versione vulnerabile del software con quella aggiornata. Il processo permette di individuare rapidamente la funzione o il componente modificato dalla patch e, di conseguenza, di comprendere la logica della vulnerabilità. In molti casi è possibile ricostruire il bug originale e sviluppare un exploit funzionante anche senza disporre della documentazione tecnica completa.

Questo per i software a sorgente chiuso; per quelli open source il processo è ancora più semplice perché il codice modificato e il funzionamento della patch sono immediatamente verificabili senza dover svolgere alcuna attività di decompilazione.

Cos’è il “patch gap” e perché è pericoloso

Il fenomeno descritto al paragrafo precedente ha portato alla nascita di un intervallo temporale ben noto nel settore della sicurezza: il cosiddetto “patch gap”, cioè il periodo che intercorre tra il rilascio di una patch e la sua effettiva installazione sui sistemi esposti.

Durante questa finestra temporale gli attaccanti possono sfruttare il fatto che la vulnerabilità sia ormai pubblicamente documentata, mentre una parte significativa dei sistemi rimane ancora non aggiornata.

Non è raro che, a breve distanza dalla pubblicazione di una patch critica, siano sviluppati proof-of-concept (PoC) o exploit funzionanti. Questi strumenti possono diffondersi rapidamente nei forum underground, nei repository pubblici o nei toolkit utilizzati dai gruppi criminali, rendendo l’attacco accessibile anche ad attori con competenze tecniche limitate. Una volta disponibile un exploit affidabile, l’attività offensiva tende a intensificarsi rapidamente.

In molti casi le campagne di sfruttamento iniziano ancora prima della divulgazione pubblica della vulnerabilità. Se una falla critica fosse già nota a gruppi criminali o ad attori statali, è possibile che sia sfruttata come zero-day, cioè come una vulnerabilità sconosciuta agli sviluppatori e per la quale non esiste ancora alcuna patch disponibile.

Ecco spiegato perché la rapidità nella gestione degli aggiornamenti (patch management) sia un elemento di difesa fondamentale. L’applicazione tempestiva delle patch, insieme al monitoraggio delle superfici di attacco (non solo quelle esposte direttamente su Internet ma raggiungibili, ad esempio attraverso attacchi mirati o catene di vulnerabilità, attraverso la rete locale), fanno davvero la differenza.

Le falle di sicurezza che hanno cambiato la storia della cybersecurity

È proprio in questo scenario che alcune vulnerabilità hanno assunto un ruolo particolarmente significativo nella storia della cybersecurity. In determinati casi la combinazione tra ampia diffusione del software, semplicità di sfruttamento e disponibilità pubblica di exploit ha generato attacchi su scala globale, trasformando singoli bug in eventi che hanno segnato profondamente l’evoluzione delle pratiche di sicurezza informatica.

Non si tratta semplicemente di errori nel codice, ma di debolezze capaci di trasformarsi in crisi globali nel giro di poche ore, compromettendo infrastrutture critiche, aziende multinazionali e servizi utilizzati da milioni di persone.

Quando una vulnerabilità diventa un problema globale

In questi casi, infatti, l’impatto potenziale è enorme. Se il software vulnerabile è ampiamente diffuso – come una libreria utilizzata da migliaia di applicazioni, un protocollo di rete integrato nei sistemi operativi o un componente fondamentale dell’infrastruttura Internet – una singola vulnerabilità può trasformarsi in un vettore di attacco globale.

La storia della sicurezza informatica è costellata di episodi di questo tipo. Alcune vulnerabilità hanno consentito la diffusione di worm capaci di infettare milioni di computer in pochi giorni. Altre hanno esposto dati sensibili provenienti da server utilizzati da governi, aziende e piattaforme online. In diversi casi il problema risiedeva in componenti software talmente diffusi da essere presenti praticamente ovunque: server Web, cloud, dispositivi embedded e applicazioni enterprise.

Le lezioni imparate dagli incidenti più gravi

Questi eventi hanno avuto conseguenze profonde non solo dal punto di vista tecnico, ma anche culturale e organizzativo. Hanno spinto aziende e istituzioni a migliorare le pratiche di patch management, hanno portato alla nascita di programmi di bug bounty, che dovrebbero essere promossi anche a livello statale, hanno reso più rigorosi i processi di auditing del codice e hanno evidenziato l’importanza della sicurezza nella supply chain del software.

Analizzare le vulnerabilità più critiche della storia non significa soltanto ripercorrere alcuni dei più grandi incidenti informatici mai avvenuti. Significa anche comprendere come funzionano gli attacchi su larga scala, perché alcuni bug diventano improvvisamente devastanti e quali lezioni il settore della cybersecurity ha imparato da queste crisi.

Log4Shell: quando una libreria ubiqua diventa un vettore di compromissione globale

La vulnerabilità Log4Shell (CVE-2021-44228) è probabilmente uno degli esempi più emblematici di come un componente apparentemente innocuo possa diventare un punto di compromissione globale. A proposito, il valore che segue l’indicazione “CVE” suggerisce l’anno di scoperta della falla di sicurezza.

Il problema risiedeva nella libreria Java Apache Log4j, uno strumento estremamente diffuso utilizzato per registrare log applicativi. Attraverso una semplice stringa inserita in un campo di input – spesso anche all’interno di header HTTP – un attaccante poteva attivare un meccanismo di JNDI lookup che permetteva al server vulnerabile di scaricare ed eseguire codice remoto.

Il risultato era devastante: un exploit RCE eseguibile a distanza, senza autenticazione e spesso invisibile ai controlli tradizionali.

La gravità reale della vulnerabilità derivava soprattutto dalla diffusione della libreria: Log4j è incorporata in migliaia di prodotti enterprise, servizi cloud, applicazioni SaaS (Software-as-a-Service) e dispositivi embedded. Nel giro di poche ore dalla divulgazione pubblica iniziarono scansioni massive dell’intero spazio di indirizzamento IP, mentre aziende di tutto il mondo si trovarono costrette a effettuare analisi urgenti delle dipendenze software.

Molti analisti hanno definito Log4Shell la vulnerabilità più critica dell’ultimo decennio proprio per la sua combinazione di facilità di exploit, ampia superficie di attacco e diffusione trasversale nel software moderno.

EternalBlue: la vulnerabilità che ha scatenato WannaCry

Un altro episodio fondamentale nella storia della sicurezza informatica è rappresentato da EternalBlue (CVE-2017-0144), una vulnerabilità nel protocollo SMBv1 implementato nei sistemi Windows.

L’exploit, originariamente sviluppato dalla NSA, divenne pubblico nel 2017 quando il gruppo Shadow Brokers pubblicò una serie di strumenti offensivi sottratti all’agenzia statunitense. Tra questi figurava proprio EternalBlue, capace di sfruttare un difetto nel servizio SMB per eseguire codice da remoto.

La caratteristica più pericolosa della vulnerabilità consisteva nelle sue abilità di worm: un sistema compromesso poteva automaticamente infettarne altri nella stessa rete.

Il meccanismo fu sfruttato dal ransomware WannaCry, che nel maggio 2017 colpì centinaia di migliaia di computer in oltre 150 Paesi. Ospedali, aziende logistiche, industrie manifatturiere e infrastrutture pubbliche subirono interruzioni operative su larga scala.

L’episodio dimostrò in modo drammatico come vulnerabilità presenti da anni nei sistemi legacy possano trasformarsi improvvisamente in crisi globali quando vengono rese disponibili tecniche di exploit affidabili.

Heartbleed: la falla di sicurezza che ha interessato milioni di server Web e non solo

Nel 2014 la vulnerabilità Heartbleed (CVE-2014-0160) mise in discussione la sicurezza stessa delle comunicazioni cifrate online.

Il problema era legato all’implementazione dell’estensione TLS Heartbeat nella libreria crittografica OpenSSL, utilizzata da milioni di server Web (e non solo). A causa di un errore nella gestione della lunghezza dei dati restituiti, un attaccante poteva leggere porzioni arbitrarie di memoria del server.

Il bug consentiva di estrarre informazioni estremamente sensibili: chiavi private TLS, credenziali utente, cookie di sessione, dati applicativi residenti in memoria.

A differenza di molte altre vulnerabilità, Heartbleed non lasciava tracce evidenti nei log: ciò rendeva impossibile stabilire se un sistema fosse stato effettivamente preso di mira dagli aggressori.

L’impatto fu enorme: milioni di certificati TLS furono revocati e rigenerati, mentre molte imprese costrette a reimpostare password per intere basi di utenti.

Heartbleed segnò anche un punto di svolta nella comunicazione delle vulnerabilità: fu una delle prime ad essere accompagnata da branding mediatico, logo dedicato e sito informativo, pratica poi diventata comune negli anni successivi.

BlueKeep: la minaccia di un worm globale evitato per poco

Nel 2019 la vulnerabilità BlueKeep (CVE-2019-0708) generò una delle più grandi mobilitazioni nel settore della sicurezza.

Il difetto interessava il protocollo Remote Desktop (RDP) utilizzato nei sistemi Windows e consentiva esecuzione di codice remoto prima dell’autenticazione. Come EternalBlue, anche BlueKeep era wormable, il che significava che un malware avrebbe potuto propagarsi automaticamente tra i sistemi vulnerabili.

La comunità di sicurezza temeva la nascita di un worm simile a WannaCry, ma potenzialmente ancora più distruttivo, poiché milioni di sistemi esponevano RDP direttamente su Internet.

Microsoft prese la decisione rara di rilasciare patch anche per sistemi operativi ormai fuori supporto, come Windows XP e Windows Server 2003. La vulnerabilità fu poi effettivamente sfruttata in alcune campagne di cryptomining, ma non sfociò in un worm globale.

Autenticazione compromessa nella libreria pac4j-jwt

Il framework pac4j fornisce componenti di autenticazione e autorizzazione per applicazioni Java integrate con piattaforme come Spring, Play Framework o Dropwizard. Il modulo pac4j-jwt gestisce i JSON Web Token, uno dei meccanismi più diffusi per rappresentare l’identità degli utenti nei sistemi distribuiti. La libreria supporta sia token firmati (JWS) sia token cifrati (JWE).

Ancora non è chiaro l’impatto della vulnerabilità scoperta a marzo 2026 (CVE-2026-29000) ma il CVSS pari a 10.0 è tutto un programma.

La gravità del problema deriva in questo caso dal fatto che l’attaccante non deve conoscere la chiave privata del server. È sufficiente utilizzare la chiave pubblica, normalmente esposta attraverso endpoint JWKS o certificati pubblici. Con questa informazione l’aggressore può creare un token cifrato contenente claim arbitrari – ad esempio ruolo amministrativo o identità di un utente privilegiato – che il sistema accetta come autentici.

La mitigazione richiede l’aggiornamento alle versioni corrette della libreria e una revisione del flusso di validazione dei token. In molte architetture l’autenticazione JWT rappresenta il punto di ingresso dell’intero sistema. Se questa barriera cade, ogni servizio che si fida dei token emessi diventa automaticamente accessibile. E a livello di grandi aziende e Pubblica Amministrazione può trasformarsi in un nuovo colossale incidente.

Conficker e MS08-067: il worm più diffuso dell’era Windows

Prima dell’era moderna delle “vulnerabilità mediatiche”, uno degli episodi più devastanti fu legato alla vulnerabilità MS08-067 (CVE-2008-4250) nel servizio RPC di Windows. Tale difetto fu sfruttato dal worm Conficker, che riuscì a infettare tra 10 e 15 milioni di computer in tutto il mondo.

Il malware creò una gigantesca botnet utilizzata per spam, furti di dati e distribuzione di ulteriori malware. La robustezza dell’infrastruttura command & control rese la botnet estremamente difficile da smantellare.

Ancora anni dopo la scoperta della vulnerabilità era possibile trovare sistemi vulnerabili in ambienti industriali e dispositivi medicali non aggiornati.

Blaster e Sasser: i worm che segnarono l’inizio delle epidemie digitali globali

Ancora prima, i sistemi connessi con la rete Internet avevano già sperimentato attacchi su scala globale causati da worm estremamente aggressivi. Tra i casi più emblematici vi sono Blaster e Sasser, due malware che nei primi anni 2000 dimostrarono quanto potesse essere devastante una vulnerabilità di rete sfruttabile in maniera automatizzata e da remoto.

Il worm Blaster, noto anche come MSBlast o Lovsan, comparve nel 2003 sfruttando una vulnerabilità critica nel servizio RPC di Windows, identificata come CVE-2003-0352 e corretta da Microsoft con il bollettino di sicurezza MS03-026. La vulnerabilità permetteva a un attaccante di eseguire codice da remoto inviando pacchetti appositamente costruiti al servizio RPC esposto sulla porta 135.

Una volta infettato un sistema, Blaster iniziava immediatamente a scansionare altri indirizzi IP alla ricerca di computer vulnerabili. Il malware generava enormi volumi di traffico di rete e provocava continui riavvii dei sistemi Windows colpiti, rendendo molti computer praticamente inutilizzabili. L’impatto fu enorme: nel giro di pochi giorni centinaia di migliaia di macchine risultarono compromesse in tutto il mondo. In tanti si collegavano alla rete Internet usando un semplice modem, quindi senza le difese sulle quali possiamo contare oggi: la porta era spesso esposta sull’IP pubblico.

L’anno successivo, nel 2004, apparve un worm ancora più aggressivo: Sasser. Questo malware sfruttava una vulnerabilità nel servizio LSASS (Local Security Authority Subsystem Service) di Windows, identificata come CVE-2004-0112 e corretta da Microsoft con il bollettino MS04-011.

A differenza di molti malware dell’epoca, Sasser non richiedeva alcuna interazione dell’utente e non si diffondeva tramite email o file infetti. Il worm si propagava direttamente attraverso Internet sfruttando la vulnerabilità del servizio LSASS esposto sulla porta 445. Una volta compromesso un sistema, il malware installava un server FTP temporaneo per trasferire il codice malevolo ai nuovi host individuati durante le scansioni della rete.

Le nuove vulnerabilità critiche e il rischio della supply chain

Negli ultimi anni il panorama delle vulnerabilità critiche si è evoluto. Molte delle minacce più gravi non derivano più soltanto da bug di memoria o errori di implementazione nei protocolli, ma da problemi strutturali nella supply chain del software ovvero nella sua catena di fornitura.

Un esempio emblematico è la vulnerabilità CVE-2024-3094 nel progetto XZ Utils, che ha rivelato un tentativo sofisticato di inserire una backdoor direttamente nel codice di una libreria open source utilizzata in numerose distribuzioni Linux.

In altri casi emergono vulnerabilità con punteggio CVSS massimo in componenti di autenticazione o infrastrutture cloud. Tra le più recenti segnalazioni vi sono bug che consentono bypass dell’autenticazione o compromissioni di sistemi di identity management.

Sono classi di vulnerabilità che non sempre generano incidenti immediati su scala globale, ma evidenziano una trasformazione fondamentale: la sicurezza del software moderno dipende da catene di dipendenze estremamente complesse, spesso mantenute da piccoli gruppi di sviluppatori volontari.

Perché alcune vulnerabilità diventano storiche

Abbiamo detto che il punteggio massimo nel sistema CVSS deriva da una combinazione di fattori: accesso remoto tramite rete, assenza di autenticazione, nessuna interazione dell’utente e impatto completo sul sistema bersaglio. Tuttavia la gravità teorica non sempre coincide con l’impatto reale.

Una vulnerabilità in una libreria marginale può raggiungere CVSS 10 senza generare incidenti diffusi, mentre un bug con punteggio inferiore può trasformarsi in un attacco globale se colpisce infrastrutture ampiamente distribuite.

I casi più memorabili condividono alcune caratteristiche tecniche: presenza in componenti fondamentali della stack software, semplicità di sfruttamento e facilità di automazione degli exploit. Quando queste condizioni si combinano, la vulnerabilità diventa rapidamente un problema di sicurezza globale e costringe interi settori industriali a reagire in tempi brevissimi.