Il feed VEL di Joomla!, spiegato

La scansione giornaliera di Houston si basa su due feed pubblicati direttamente da Joomla!: il feed VEL per le estensioni e il feed Security Centre per il core. Questa pagina tratta il primo: cos'è realmente VEL, cosa contiene ogni voce e dove i suoi dati si assottigliano, così un avviso generato da esso significa esattamente ciò che dice, e nulla più.

Cos'è realmente VEL

VEL è l'acronimo di Vulnerable Extensions List. È un feed gratuito e pubblico pubblicato su extensions.joomla.org, lo stesso sito che gestisce la Joomla Extensions Directory, e non è un database CVE generico. Esiste specificamente per tracciare le vulnerabilità note nelle estensioni di terze parti per Joomla!: componenti, plugin, moduli e template, a differenza del core di Joomla! stesso, che ha un proprio feed separato descritto più avanti. Non è richiesta alcuna API key per leggerlo, ed è la stessa fonte che Houston interroga ogni giorno.

Cosa contiene ogni voce

Una voce VEL collega una vulnerabilità a un'estensione specifica, identificata tramite il nome del suo elemento Joomla. Quando il report di origine lo consente, una voce riporta anche un intervallo di versioni interessate, in modo che una versione dell'estensione corretta smetta di corrispondere, un riferimento a un identificativo CVE ufficiale quando il risultato ne ha uno, e un'indicazione di gravità. Non tutte le voci hanno tutti e tre questi elementi. Alcune riportano un CVE e un intervallo di versioni preciso. Altre sono registrate solo con il nome dell'estensione, con l'intervallo di versioni o il CVE lasciati vuoti perché il report originale non li includeva.

VEL a confronto con il feed Security Centre

VEL copre solo le estensioni di terze parti. Non dice nulla sul core di Joomla! stesso. Per quello, Joomla! pubblica un feed separato dal proprio Security Centre, il canale ufficiale che il team di sicurezza di Joomla! utilizza per annunciare vulnerabilità del core e release corrette. Houston legge entrambi i feed ogni giorno: VEL per tutto ciò che è installato oltre al core, e il feed Security Centre per la versione del core stessa. Un sito può essere aggiornato su uno e in ritardo sull'altro, quindi controllare solo uno dei due lascia una lacuna reale. Consulta perché l'avviso di aggiornamento nativo di Joomla! non copre da solo questo aspetto per saperne di più su questa distinzione.

Come Houston lo legge senza aggiungere carico

VEL è una risorsa pubblica e condivisa, e una scansione eseguita in modo indipendente su ogni installazione di Houston, potenzialmente migliaia di siti ciascuno con la propria pianificazione giornaliera, genererebbe un carico reale se ogni singola scansione scaricasse l'intero feed. Houston controlla prima un endpoint leggero di verifica hash, e scarica il feed completo, attualmente dell'ordine di poche centinaia di voci, solo quando quell'hash è effettivamente cambiato dall'ultima sincronizzazione riuscita. Nella maggior parte dei giorni, questo significa una piccola richiesta, non un nuovo download completo.

Dove i dati si assottigliano

VEL è la migliore fonte gratuita del suo genere per Joomla!, ma è compilata a partire da report inviati in modo indipendente, non da un unico database verificato centralmente, quindi la sua completezza varia da voce a voce. Quando manca un intervallo di versioni o un CVE, Houston mostra comunque il risultato, perché il solo fatto che un'estensione sia elencata in VEL vale la pena saperlo, ma mostra esattamente ciò che il feed gli ha fornito, invece di dedurre una gravità o un limite di versione che i dati di origine non supportano. Se un risultato compare senza un CVE associato, si tratta di una lacuna propria di VEL, non di qualcosa che Houston ha nascosto. Se vieni da WordPress e ti chiedi come questo si confronti con il database delle vulnerabilità di Wordfence o WPScan, consulta il confronto onesto.

Recuperare la gravità mancante: prima NVD, poi CVE.org

Quando un risultato riporta effettivamente un CVE reale, che provenga da VEL o dal feed Security Centre, Houston ne ricerca automaticamente un punteggio CVSS accurato. Controlla prima il National Vulnerability Database (NVD), e solo se NVD non ha nulla per quell'identificativo, ripiega sul record di CVE.org stesso, tramite la stessa API CVE Services gestita dal CVE Program. Nessuna delle due chiamate avviene per un risultato privo di un CVE reale, e nessuna delle due sovrascrive mai una gravità fornita dal chiamante con una stima.

Questo fallback esiste perché l'arretrato di valutazione di NVD è diventato una lacuna strutturale nel 2026: i record non valutati risalenti a prima del 1° marzo 2026 sono passati a uno stato permanente "Not Scheduled", e le nuove valutazioni ora danno priorità alle vulnerabilità collegate alla Known Exploited Vulnerabilities list di CISA o a una rilevanza critica a livello federale. Una vulnerabilità piccola e divulgata in un'estensione Joomla! è esattamente il tipo di risultato che, sempre più spesso, non viene mai valutato da NVD.

Il record di CVE.org è di per sé una seconda fonte indipendente per lo stesso punteggio. Houston controlla prima il container CNA, che nella maggior parte dei casi è il team di sicurezza di Joomla! stesso e che raramente fornisce direttamente un punteggio CVSS, poi ogni container ADP, poiché il programma Vulnrichment di CISA inserisce retroattivamente i punteggi esattamente in quella parte del record. Le due fonti si rivelano genuinamente complementari, non semplicemente l'una che colma le lacune dell'altra: in un caso verificato dal vivo, una vulnerabilità divulgata in Helix3, un framework di template Joomla! ampiamente utilizzato, non aveva alcun punteggio NVD, ma il container ADP del suo record CVE.org riportava un punteggio CVSS 3.1 di 7.5.