CVE sta per Common Vulnerabilities and Exposures ed è il catalogo di riferimento globale delle vulnerabilità di sicurezza note pubblicamente. Il programma è gestito dalla MITRE Corporation dal 1999 ed è finanziato dall'agenzia statunitense per la cybersicurezza CISA. Ogni vulnerabilità riceve un identificativo univoco nel formato CVE-ANNO-NUMERO, per esempio CVE-2021-44228 per Log4Shell, in modo che fornitori, scanner, ricercatori e articoli di stampa intendano tutti la stessa falla. Gli identificativi vengono assegnati da diverse centinaia di CVE Numbering Authorities (CNA) in tutto il mondo. La gravità di un CVE viene valutata con il Common Vulnerability Scoring System (CVSS), una scala da 0.0 a 10.0 mantenuta da FIRST: dal 9.0 la classificazione è Critical, da 7.0 a 8.9 High, da 4.0 a 6.9 Medium e al di sotto Low. Le dimensioni del sistema sono cresciute enormemente: solo nel 2024 sono stati pubblicati oltre 40.000 nuovi CVE e nell'ecosistema WordPress sono state divulgate poco meno di 8.000 vulnerabilità, circa il 96 percento delle quali nei plugin.
Cosa significa CVE?
Prima che esistesse il CVE, ogni fornitore di sicurezza descriveva le vulnerabilità con parole proprie e nessuno riusciva a capire se il buffer overflow di un bollettino fosse lo stesso bug del remote exploit di un altro. Il programma Common Vulnerabilities and Exposures, avviato da MITRE nel 1999, ha risolto la questione con qualcosa di ingannevolmente semplice: un nome univoco per ogni falla. Un record CVE contiene quell'identificativo, una breve descrizione, i riferimenti a bollettini e patch e i prodotti interessati.
Il formato dell'identificativo è CVE-ANNO-NUMERO, dove l'anno è quello di assegnazione, non necessariamente quello della scoperta, e il numero ha quattro o più cifre. Il database ufficiale si trova su cve.org. Sopra di esso si colloca il National Vulnerability Database (NVD), gestito dall'istituto statunitense di standardizzazione NIST, che arricchisce i record CVE con punteggi di gravità, intervalli di versioni interessate e classificazioni delle debolezze. Quando il tuo scanner di sicurezza mostra i dati di gravità di un CVE, di solito arrivano dall'NVD.
Come ottiene un identificativo CVE una vulnerabilità?
Gli identificativi CVE vengono distribuiti dalle CVE Numbering Authorities, in breve CNA. Si tratta di produttori di software, aziende di sicurezza e organizzazioni di ricerca autorizzate ad assegnare identificativi per i propri prodotti o per il proprio ambito di competenza. La rete è cresciuta fino a diverse centinaia di CNA in decine di Paesi, ed è il motivo per cui un ricercatore che trova una falla, poniamo, in un prodotto Cisco la segnala direttamente a Cisco, e Cisco assegna il CVE per conto proprio.
Il flusso tipico è questo: un ricercatore scopre una vulnerabilità e la segnala alla CNA competente, la CNA riserva un identificativo CVE mentre la correzione viene sviluppata e, una volta rilasciata la patch, il record viene pubblicato insieme al bollettino. Quella fase di riserva spiega perché a volte vedi citato pubblicamente un identificativo CVE senza che vi siano ancora dettagli.
Per chi usa WordPress c'è un dettaglio che vale la pena conoscere: Wordfence, WPScan e Patchstack sono tutte e tre CNA. La grande maggioranza dei CVE relativi a plugin e temi WordPress viene assegnata da una di queste tre, motivo per cui i loro database di vulnerabilità sono anche le fonti più complete per l'ecosistema WordPress.
Cos'è il punteggio CVSS?
Un nome da solo non ti dice quanto è grave una falla. Di questo si occupa il Common Vulnerability Scoring System, uno standard aperto mantenuto da FIRST, l'associazione mondiale dei team di risposta agli incidenti. Il CVSS condensa le caratteristiche tecniche di una vulnerabilità in un punteggio compreso tra 0.0 e 10.0. La versione 2 è comparsa nel 2007, la versione 3.0 nel 2015, la revisione 3.1 nel 2019 e la versione 4.0 nel novembre 2023. Nella pratica la maggior parte dei database e dei bollettini parla ancora CVSS 3.1, con un'adozione della 4.0 che cresce lentamente.
Le classi di gravità CVSS da None a Critical
| Classificazione | Punteggio CVSS | Significato tipico |
|---|---|---|
| None | 0.0 | Nessun impatto |
| Low | da 0.1 a 3.9 | Difficile da sfruttare oppure con impatto molto limitato |
| Medium | da 4.0 a 6.9 | Impatto reale, ma con presupposti come l'interazione dell'utente o privilegi già ottenuti |
| High | da 7.0 a 8.9 | Impatto serio, spesso esposizione di dati o escalation di privilegi |
| Critical | da 9.0 a 10.0 | Tipicamente sfruttamento remoto senza autenticazione con compromissione totale |
Il famigerato 9.8 che vedi su tantissimi bollettini è il punteggio tipico di una remote code execution senza autenticazione: raggiungibile via rete, nessun privilegio, nessuna interazione dell'utente richiesta. Un 10.0 pieno esce inoltre dal componente vulnerabile verso altri sistemi, che è esattamente ciò che è riuscito a fare Log4Shell.
Come si calcola un punteggio CVSS?
Il punteggio base deriva da una manciata di metriche che descrivono come si può raggiungere una falla e cosa rompe. Sul versante della sfruttabilità: Attack Vector (rete, adiacente, locale, fisico), Attack Complexity, Privileges Required e User Interaction. Sul versante dell'impatto: l'effetto su Confidentiality, Integrity e Availability, più, nella versione 3.1, la metrica Scope che cattura se il danno si estende ad altri componenti. Le singole scelte vengono registrate in una stringa vettoriale compatta che troverai su ogni voce dell'NVD:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
AV:N raggiungibile via rete
AC:L complessità di attacco bassa
PR:N nessun privilegio richiesto
UI:N nessuna interazione dell'utente necessaria
S:U scope invariato
C:H/I:H/A:H impatto alto su riservatezza, integrità, disponibilità
Risultato: punteggio base 9.8, CriticalLa cosa bella del vettore è che ti dice più del numero. Un 7.5 con PR:N e un 7.5 con PR:H sono bestie molto diverse per il tuo modello di minaccia, e leggere il vettore richiede dieci secondi una volta che conosci le abbreviazioni.
Cosa c'è di nuovo in CVSS 4.0?
La versione 4.0 affronta le critiche principali mosse alla 3.1. La confusa metrica Scope è sparita, sostituita da valutazioni di impatto separate per il sistema vulnerabile e per i sistemi successivi. User Interaction è ora più sfumata, con le varianti passiva e attiva, e una nuova metrica Attack Requirements cattura le condizioni che devono esistere sul bersaglio. Le vecchie metriche temporali sono state rielaborate in metriche di minaccia e lo standard ora nomina esplicitamente le varianti di punteggio: CVSS-B per il punteggio base puro, CVSS-BT con i dati sulle minacce e CVSS-BE con il contesto ambientale. Concettualmente è tutto un miglioramento. In pratica l'ecosistema si muove lentamente, quindi aspettati di leggere vettori 3.1 ancora per anni.
Perché un punteggio CVSS alto non è automaticamente il tuo rischio maggiore
Ecco la verità scomoda sul CVSS: misura la gravità, non la probabilità. La stragrande maggioranza dei CVE pubblicati non viene mai sfruttata sul campo, mentre alcune falle con punteggio medio vengono martellate nel giro di poche ore perché esiste un exploit pubblico e il bersaglio è ovunque. Due insiemi di dati aiutano a colmare quello scarto. Il punteggio EPSS, anch'esso di FIRST, stima la probabilità che una vulnerabilità venga sfruttata nei 30 giorni successivi sulla base di telemetria reale. E il catalogo CISA KEV elenca le vulnerabilità con sfruttamento confermato, che è il segnale più forte a disposizione.
Una regola pratica di prioritizzazione per chi gestisce un sito: correggi per primo ciò che è nel KEV o ha un punteggio EPSS alto e si trova in un componente esposto su Internet. Un 9.8 in un plugin che hai disattivato l'anno scorso conta meno di un 7.5 nel plugin dei moduli di contatto che ogni visitatore può raggiungere. La gravità è contesto e solo tu conosci il tuo contesto.
I CVE nell'ecosistema WordPress
Il core di WordPress è ormai un bersaglio duro e rappresenta ben meno dell'uno percento delle vulnerabilità divulgate. L'azione è nell'ecosistema delle estensioni: secondo Patchstack, nel 2024 sono state divulgate poco meno di 8.000 nuove vulnerabilità nell'ecosistema WordPress, circa il 96 percento delle quali nei plugin e la maggior parte delle restanti nei temi. Le categorie più frequenti sono cross-site scripting, cross-site request forgery e controllo degli accessi difettoso. Nulla di tutto ciò significa che WordPress sia insicuro, significa che la sicurezza del tuo sito la decidono i plugin che installi e la velocità con cui li aggiorni. Un plugin con 100.000 installazioni e una falla nota non corretta diventa bersaglio di scansioni di massa nel giro di giorni, a volte di ore.
Esempi celebri di CVE
- CVE-2014-0160, Heartbleed: divulgazione di memoria in OpenSSL che permetteva agli attaccanti di leggere le chiavi private dai server. Il bug che ha dato alle vulnerabilità logo e nome.
- CVE-2017-0144, EternalBlue: la falla SMB dietro l'ondata di ransomware WannaCry del 2017.
- CVE-2021-44228, Log4Shell: un CVSS 10.0 nella libreria di logging Java Log4j. Una stringa costruita ad arte in un qualsiasi campo registrato portava all'esecuzione di codice remoto, e mezza Internet registrava input degli utenti.
- CVE-2023-4966, Citrix Bleed: fuga di token di sessione in Citrix NetScaler, sfruttata da gruppi ransomware contro migliaia di apparati.
Come usa InspectWP i dati CVE?
InspectWP rileva i plugin e i temi di un sito WordPress analizzato e li confronta con i dati sulle vulnerabilità note, così un report può dirti che uno specifico componente installato ha un CVE pubblicato, quanto è grave e che è disponibile un aggiornamento. Questo chiude la fastidiosa distanza tra un CVE che esiste da qualche parte in un database e il fatto che tu venga davvero a sapere che riguarda uno dei tuoi siti. In combinazione con i report automatici pianificati ottieni la versione pratica della gestione delle vulnerabilità per WordPress: sapere cosa fai girare, sapere cosa è rotto, aggiornare per prime le cose che contano.