Vai al contenuto
New

DeepSeek V4.1 Flash free for 7 days: 10M tokens a day after a top-up of $10 or more. Until Nov 30.

How it works

Leggere un CVE: cosa ti dice un record CVE e cosa non ti dice

Un record CVE dà un nome alla falla e rimanda al vendor, ed è il bollettino di sicurezza del vendor a stabilire la versione con il fix.

Base12 min di letturaDi NotHoly

Leggi in una notizia che una falla con un numero CVE viene sfruttata. Dieci minuti dopo un collega ti chiede se avete applicato la patch. Il numero è l'unico fatto su cui la notizia e il collega sono d'accordo. Identifica una falla. Non ti dice quanto è grave per i tuoi sistemi, quali delle tue versioni sono colpite né cosa installare.

Questo articolo spiega cos'è un ID CVE, chi lo assegna, cosa significa ogni campo di un record CVE e cosa aggiunge a quel record il National Vulnerability Database (NVD). Nella parte pratica leggi campo per campo un record molto noto, CVE-2021-44228 (Log4Shell), da cve.org e dall'API di NVD. Poi apri il bollettino di sicurezza del vendor a cui il record rimanda. La cosa da tenere a mente: il record CVE ti indirizza al bollettino del vendor, e il bollettino del vendor è la fonte di riferimento per le versioni con il fix.

Se hai letto Cos'è una vulnerabilità, i termini ti saranno familiari. Il laboratorio manda richieste di sola lettura a due servizi pubblici e a una pagina web pubblica.

Cos'è un ID CVE

CVE sta per Common Vulnerabilities and Exposures. Il CVE Program, come spiega la sua pagina di presentazione, identifica, definisce e cataloga le vulnerabilità di sicurezza informatica rese pubbliche. Ogni vulnerabilità ha una voce, chiamata CVE Record, e l'ID è il riferimento a quella voce. Ha la forma CVE-ANNO-NUMERO. L'anno è quello in cui l'ID è stato riservato, che spesso non coincide con l'anno in cui il bug è stato scritto o corretto.

L'ID è un nome. Permette a due persone, o a due strumenti, di dire "questa" e parlare della stessa falla. Non contiene un punteggio di gravità, un elenco di prodotti colpiti, una patch né lo stato di sfruttamento. Quei dati stanno nel record, e alcuni arrivano da altre organizzazioni.

Chi assegna gli ID

Il CVE Program opera attraverso le CVE Numbering Authorities, o CNA. Il sito CVE le descrive come vendor, ricercatori, progetti open source, CERT, servizi in hosting, fornitori di programmi di bug bounty e consorzi. Ognuna è autorizzata ad assegnare ID e pubblicare record all'interno del proprio perimetro. Quando abbiamo controllato la pagina delle CNA il 2026-11-08, ne elencava 564, tra cui 3 CNA-LR (CNA di ultima istanza, per i prodotti che nessun'altra CNA copre). Il numero cambia, quindi controlla la pagina per il dato aggiornato.

La parola da ricordare è perimetro. La Apache Software Foundation è la CNA dei progetti Apache, quindi il record di CVE-2021-44228 la indica come CNA. La CNA scrive titolo, descrizione, prodotti colpiti, riferimenti e tipi di problema. Altri soggetti possono aggiungere dati in seguito, ed è qui che entra in gioco NVD.

I campi di un record CVE

I nomi dei campi qui sotto vengono dal formato JSON dei record CVE. La vista JSON su cve.org e il JSON dell'API CVE hanno la stessa struttura.

Stato e date

Lo stato ti dice se la voce è attiva. Il record di questo laboratorio mostra "state": "PUBLISHED". Esistono anche record respinti, quindi controlla prima lo stato.

Il JSON CVE ha tre date: dateReserved, datePublished e dateUpdated. Per CVE-2021-44228 sono 2021-11-26, 2021-12-10 e 2025-10-21. NVD tiene date proprie. Il suo valore published è 2021-12-10, e il valore lastModified è 2026-08-11 nella risposta che abbiamo scaricato. La pagina di cve.org mostra una data "Updated" separata, 2023-04-03, che viene dai metadati del provider della CNA. Tre fonti, tre date di "aggiornamento". Confrontale prima di concludere che hai il testo più recente.

Descrizione

La descrizione è testo libero scritto dalla CNA. Dovrebbe dire qual è la falla, cosa la attiva e quali versioni tocca. La descrizione di Log4Shell indica l'intervallo colpito, nomina la funzione coinvolta (i lookup JNDI in configurazione, messaggi di log e parametri), dice quando il comportamento è stato disattivato per impostazione predefinita e afferma che log4net e gli altri progetti di logging Apache non sono colpiti. Quell'ultima frase ti risparmia un pomeriggio passato a correggere la cosa sbagliata.

Prodotti e versioni colpiti

Questo blocco è la parte più utile del record e la più facile da fraintendere. Ogni indicazione di versione dice se un intervallo è colpito, non colpito o sconosciuto, e può esprimere cambiamenti a numeri di versione precisi.

La pagina di cve.org mostra la voce di Log4j2 come una linea temporale: colpito da 2.0-beta9, non colpito da 2.3.1, colpito da 2.4, non colpito da 2.12.2, colpito da 2.13.0 e non colpito da 2.15.0. Una versione prende lo stato dell'ultimo punto di cambiamento che la precede. Sono proprio i vuoti a contare. "Tutto ciò che sta sotto 2.15.0 è vulnerabile" qui è sbagliato, perché 2.3.1 e 2.12.2 risultano non colpite.

Il campo lessThan nomina il componente, log4j-core*. Il bollettino di Apache dice che un'applicazione che usa solo il JAR log4j-api non è colpita. Leggi il componente insieme alla versione. La completezza dell'elenco, poi, dipende da quanto l'ha curato la CNA. I prodotti che includono la libreria possono mancare, e lì aiutano il bollettino del vendor e i dati di configurazione di NVD.

Riferimenti

I riferimenti sono link a bollettini di sicurezza dei vendor, messaggi di mailing list, analisi di terzi e a volte pagine sullo sfruttamento. La pagina di cve.org elenca 53 riferimenti per CVE-2021-44228, ognuno con un tag come vendor-advisory, mailing-list, third-party-advisory o exploit. Leggi per primi i link vendor-advisory. Le pagine di terzi danno contesto, non le versioni con il fix. La copia NVD di questo record conserva i riferimenti in un ordine proprio, e le sue prime cinque voci sono tutte pagine di Packet Storm.

Debolezze (CWE)

CWE è la Common Weakness Enumeration, un catalogo di tipi di debolezza. CWE-20 è Improper Input Validation e CWE-502 è Deserialization of Untrusted Data. Un CWE dice quale tipo di errore ha portato alla falla. Non nomina un prodotto.

La CNA elenca CWE-20, CWE-400 e CWE-502. Il record NVD elenca gli stessi tre, attribuiti all'indirizzo di sicurezza di Apache, e aggiunge CWE-917, attribuito a NVD. Tieni d'occhio la colonna della fonte. Puoi non essere d'accordo con la mappatura di un analista, e dovresti sapere quale mappatura stai leggendo. CWE serve anche a raggruppare. Una ricerca per CWE trova tutte le falle di deserializzazione nei vari prodotti, cosa utile nella code review e nel threat modeling.

Metriche

Le metriche contengono punteggi e valutazioni di fonti diverse.

CVSS (Common Vulnerability Scoring System) dà un punteggio base da 0 a 10, un'etichetta di gravità e una stringa vettoriale con gli input: vettore d'attacco, complessità, privilegi, interazione dell'utente, ambito e impatto. La voce CVSS v3.1 di NVD per questo record è 10.0, CRITICAL, con il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Il record ha anche un punteggio NVD CVSS v2.0 di 9.3. Il punteggio descrive la falla in base a ipotesi dichiarate. Non descrive la tua esposizione.

SSVC è un metodo decisionale che chiede se lo sfruttamento è in corso, se l'attacco si può automatizzare e quanto è ampio l'impatto tecnico. Questo record ha una voce SSVC da una fonte di CISA con ruolo di coordinatore che indica sfruttamento attivo, automatizzabile sì e impatto tecnico totale.

KEV è il catalogo Known Exploited Vulnerabilities di CISA. Il record mostra una data di inserimento (2021-12-10), una scadenza per l'intervento (2021-12-24) e un'azione richiesta: applicare gli aggiornamenti o togliere dalla rete gli asset colpiti. KEV significa che lo sfruttamento è stato osservato. È una questione diversa dalla gravità della falla.

Le metriche cambiano. Per ogni numero leggi la fonte e la data.

Cosa aggiunge NVD a un record

NVD è gestito dal NIST ed è un progetto separato dal CVE Program. Prende i record CVE e aggiunge ciò che la CNA può non aver fornito: punteggi CVSS che calcola o conferma, mappatura CWE, configurazioni CPE (corrispondenze tra prodotti e versioni leggibili dalle macchine), tag sui riferimenti e un campo di stato. L'API di NVD su services.nvd.nist.gov distribuisce questi record arricchiti. La pagina della dashboard NVD del NIST sta accanto alla documentazione dell'API: controlla lì eventuali avvisi prima di dare per scontato che l'arricchimento sia aggiornato.

Il blocco di configurazione è la parte che quasi nessuno apre. Questo record ha 20 blocchi di configurazione con 396 voci di corrispondenza CPE. La prima voce è un pacchetto firmware Siemens, segno che l'elenco copre anche i prodotti che incorporano la libreria, oltre alle release di Apache. Una configurazione vuota o scarna può voler dire che l'analisi non è finita, e non che il prodotto è sicuro.

Lo stato qui è Analyzed. Significa che NVD ha elaborato il record. Non significa che NVD abbia testato qualcosa sulla tua rete. La data lastModified è 2026-08-11, molto dopo la pubblicazione, quindi un record letto l'anno scorso può essere cambiato.

Laboratorio: leggi CVE-2021-44228 campo per campo

Requisiti. Un browser, curl (Git Bash su Windows lo include) e Python 3.12. jq è facoltativo. Ogni richiesta qui è una lettura verso un servizio pubblico. Non chiamare l'API di NVD in un loop. Senza una chiave API, NVD limita le richieste in un breve periodo, quindi esegui ogni comando una volta sola.

Passo 1: leggi la pagina del CVE Record

Apri https://www.cve.org/CVERecord?id=CVE-2021-44228 e leggila dall'inizio alla fine. Il giorno in cui è stato eseguito questo laboratorio mostrava:

  • CNA: Apache Software Foundation
  • Pubblicato il 2021-12-10, con una data "Updated" separata del 2023-04-03
  • Titolo: Apache Log4j2 JNDI features do not protect against attacker controlled LDAP and other JNDI related endpoints
  • CWE: 3 in totale
  • Prodotto: Apache Log4j2, con le indicazioni di versione descritte sopra
  • Riferimenti: 53 in totale

Passo 2: scarica il record NVD e filtra i campi

Il comando del laboratorio, scritto per jq:

bash
curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' | jq '.vulnerabilities[0].cve | {id, published, descriptions: .descriptions[0].value, weaknesses, references: [.references[0:5][].url]}'

jq non era installato sulla macchina usata per provare questo laboratorio, quindi lo stesso filtro è stato eseguito con Python 3.12. Usa questo se non hai jq nemmeno tu:

bash
curl -s 'https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2021-44228' -o nvd.json
python -c "import json; c=json.load(open('nvd.json', encoding='utf8'))['vulnerabilities'][0]['cve']; print(json.dumps({'id': c['id'], 'published': c['published'], 'descriptions': c['descriptions'][0]['value'], 'weaknesses': c['weaknesses'], 'references': [r['url'] for r in c['references'][0:5]]}, indent=2, ensure_ascii=False))"

Output osservato con quel comando:

json
{
  "id": "CVE-2021-44228",
  "published": "2021-12-10T10:15:09.143",
  "descriptions": "Apache Log4j2 2.0-beta9 through 2.15.0 (excluding security releases 2.12.2, 2.12.3, and 2.3.1) JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. From version 2.16.0 (along with 2.12.2, 2.12.3, and 2.3.1), this functionality has been completely removed. Note that this vulnerability is specific to log4j-core and does not affect log4net, log4cxx, or other Apache Logging Services projects.",
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        { "lang": "en", "value": "CWE-20" },
        { "lang": "en", "value": "CWE-400" },
        { "lang": "en", "value": "CWE-502" }
      ]
    },
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        { "lang": "en", "value": "CWE-917" }
      ]
    }
  ],
  "references": [
    "http://packetstormsecurity.com/files/165225/Apache-Log4j2-2.14.1-Remote-Code-Execution.html",
    "http://packetstormsecurity.com/files/165260/VMware-Security-Advisory-2021-0028.html",
    "http://packetstormsecurity.com/files/165261/Apache-Log4j2-2.14.1-Information-Disclosure.html",
    "http://packetstormsecurity.com/files/165270/Apache-Log4j2-2.14.1-Remote-Code-Execution.html",
    "http://packetstormsecurity.com/files/165281/Log4j2-Log4Shell-Regexes.html"
  ]
}

Nota tre cose. Il valore published di NVD contiene un orario, 10:15, senza fuso orario, mentre il JSON della CNA dà la mezzanotte dello stesso giorno. La voce CWE aggiunta da NVD sta in un blocco a parte. E i primi cinque riferimenti sono pagine di terzi, quindi il link del vendor deve arrivare da un passo successivo.

Passo 3: leggi i punteggi e lo stato NVD

bash
python -c "import json; c=json.load(open('nvd.json', encoding='utf8'))['vulnerabilities'][0]['cve']; print('lastModified', c['lastModified'], '| vulnStatus', c['vulnStatus']); [print(k, m['source'], m['type'], m['cvssData']['version'], m['cvssData']['baseScore'], m['cvssData'].get('baseSeverity'), m['cvssData']['vectorString']) for k in ('cvssMetricV31', 'cvssMetricV2') for m in c['metrics'][k]]"

Output osservato:

text
lastModified 2026-08-11T19:33:44.513 | vulnStatus Analyzed
cvssMetricV31 [email protected] Primary 3.1 10.0 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
cvssMetricV31 134c704f-9b21-4f2e-91b3-4a467353bcc0 Secondary 3.1 10.0 CRITICAL CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
cvssMetricV2 [email protected] Primary 2.0 9.3 None AV:N/AC:M/Au:N/C:C/I:C/A:C

La voce v2 non ha un'etichetta di gravità, cosa normale per CVSS v2. La fonte secondaria v3.1 è un identificatore, non un nome. Lo stesso identificatore compare nei dati SSVC accanto a un ruolo di coordinatore CISA, quindi puoi dedurre più di quanto dica il campo. Annota ciò che riesci a confermare e indica quale parte è deduzione.

Passo 4: confronta con il JSON CVE della CNA

bash
curl -s 'https://cveawg.mitre.org/api/cve/CVE-2021-44228' -o cve5.json
python -c "import json; d=json.load(open('cve5.json', encoding='utf8')); print(json.dumps(d['cveMetadata'], indent=2))"

Output osservato:

json
{
  "state": "PUBLISHED",
  "cveId": "CVE-2021-44228",
  "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
  "assignerShortName": "apache",
  "dateUpdated": "2025-10-21T23:25:23.121Z",
  "dateReserved": "2021-11-26T00:00:00.000Z",
  "datePublished": "2021-12-10T00:00:00.000Z"
}

assignerShortName indica la CNA. Il blocco di metriche della CNA non ha un punteggio CVSS, solo una voce other che dice critical. Il punteggio CVSS che vedi viene da NVD.

Passo 5: apri il bollettino di sicurezza del vendor

Apri https://logging.apache.org/log4j/2.x/security.html. La pagina reindirizza a logging.apache.org/security.html e ha una sezione per ogni CVE. La sezione di CVE-2021-45046 sta sopra quella di CVE-2021-44228.

Nel testo che abbiamo scaricato il 2026-11-08, la sezione di CVE-2021-44228 indica come intervallo colpito [2.0-beta9, 2.3.1), [2.4, 2.12.2) e [2.13.0, 2.15.0), e come versioni con il fix 2.3.1 per Java 6, 2.12.2 per Java 7 e 2.15.0 per Java 8 e successivi. La sezione di CVE-2021-45046 dice che il fix per CVE-2021-44228 in 2.15.0 era incompleto in alcune configurazioni non predefinite. La sua riga di mitigazione raccomanda 2.3.1 per Java 6, 2.12.3 per Java 7 o 2.16.0 per Java 8 e successivi.

Metti le fonti una accanto all'altra:

Domanda Record CVE (cve.org) NVD Bollettino del vendor
Quale componente? Apache Log4j2, log4j-core 396 voci di corrispondenza CPE in totale Solo log4j-core; log4j-api da solo non è colpito
Quale versione ha il fix? Non colpito da 2.15.0 Riporta gli intervalli colpiti come corrispondenze CPE 2.15.0 per Java 8 e successivi, poi risultato incompleto; raccomandata 2.16.0
Quanto è grave? Metrica CNA "critical", nessun punteggio CVSS v3.1 10.0 CRITICAL, v2 9.3 Nessun punteggio nel testo che abbiamo letto
Sfruttata? Nessun campo sullo sfruttamento nel JSON CNA che abbiamo letto Voce KEV aggiunta il 2021-12-10 Non indicato nel testo che abbiamo letto

Chi si fosse fermato a "non colpito da 2.15.0" nel record avrebbe scelto 2.15.0 come obiettivo. Il bollettino dice che il fix di 2.15.0 era incompleto e rimanda a 2.16.0 per Java 8 e successivi. Il record mostrava le indicazioni di versione della CNA al momento in cui sono state scritte. Il bollettino mostra cosa il vendor dice oggi di installare.

Errori comuni

Prendere il punteggio CVSS per il tuo rischio. Il punteggio dà per scontati accesso e impatto. La tua esposizione dipende dal fatto che il componente sia raggiungibile e l'impostazione attiva. Usa il punteggio per ordinare il lavoro, poi controlla la raggiungibilità.

Fermarsi all'intervallo di versioni del record. La fonte per la versione da installare è il bollettino. Controllalo ogni volta.

Trattare "non elencato" come "non colpito". Un prodotto assente dall'elenco può comunque essere colpito. L'elenco dipende dal lavoro della CNA e dall'analisi di NVD, e tutti e due richiedono tempo.

Aspettarsi un CVE per ogni problema. Molti fix dei vendor escono senza un ID. L'assenza di un CVE non prova che tu sia al sicuro.

Confondere le date. Riserva, pubblicazione, ultimo aggiornamento e ultima modifica sono eventi diversi di fonti diverse. Indica la fonte accanto a ogni data che citi.

Testare un CVE su sistemi che non sono tuoi. Il laboratorio è di sola lettura. Riprodurre una falla su un target che non controlli richiede il permesso scritto del proprietario. Usa un laboratorio che hai costruito tu, con la versione del software che stai studiando.

Per andare oltre

Leggi il bollettino di sicurezza del vendor per ogni prodotto che usi e iscriviti al suo feed di sicurezza. Per i sistemi di produzione, la pagina del vendor è il documento che il tuo change control dovrebbe citare.

Raggruppa i tipi di CWE dei CVE che segui e consulta il catalogo KEV di CISA quando in una settimana arriva una lunga lista di nuovi CVE. KEV è un elenco breve di falle con sfruttamento confermato, e per questo è un filtro utile.

Il prossimo articolo di questa serie, Cos'è CVSS, spiega come si arriva al 10.0 di questo record e perché un punteggio base è solo uno degli input di una decisione di priorità.

Fonti

Fonti

  1. CVE Program overview
  2. CVE Numbering Authorities
  3. CVE Record CVE-2021-44228
  4. NVD vulnerability API documentation
  5. NVD dashboard
  6. Apache Log4j security page

Altro su Intelligence sulle vulnerabilità