The Joomla! VEL Feed, Explained

Houston's daily scan is built on two feeds Joomla itself publishes: the VEL feed for extensions, and the Security Centre feed for the core. This page covers the first one: what VEL actually is, what each entry contains, and where its data runs thin, so an alert from it means exactly what it says and nothing more.

What VEL actually is

VEL stands for Vulnerable Extensions List. It is a free, public feed published on extensions.joomla.org, the same site that runs the Joomla Extensions Directory, and it is not a general-purpose CVE database. It exists specifically to track known vulnerabilities in third-party Joomla extensions: components, plugins, modules and templates, as opposed to the Joomla core itself, which has its own separate feed covered below. No API key is required to read it, and it is the same source Houston queries every day.

What each entry contains

A VEL entry ties a vulnerability to a specific extension, identified by its Joomla element name. Where the underlying report supports it, an entry also carries an affected version range, so a fixed extension version stops matching, a reference to an official CVE identifier when the finding has one, and a severity indication. Not every entry has all three. Some carry a CVE and a precise version range. Others are recorded as an extension name alone, with the version range or CVE left blank because the original report did not include one.

VEL versus the Security Centre feed

VEL only covers third-party extensions. It says nothing about the Joomla core itself. For that, Joomla publishes a separate feed from its own Security Centre, the official channel Joomla's security team uses to announce core vulnerabilities and fixed releases. Houston reads both feeds every day: VEL for everything installed beyond the core, and the Security Centre feed for the core version itself. A site can be current on one and behind on the other, so checking only one of the two leaves a real gap. See why Joomla's own update notice does not cover this on its own for more on that distinction.

How Houston reads it without adding load

VEL is a public, shared resource, and a scan running independently on every Houston install, potentially thousands of sites each on its own daily schedule, would put real load on it if every single scan pulled the entire feed. Houston checks a lightweight verify-hash endpoint first, and only downloads the full feed, currently on the order of a few hundred entries, when that hash has actually changed since its last successful sync. Most days, that means one small request, not a full re-download.

Where the data runs thin

VEL is the best free source of its kind for Joomla, but it is compiled from independently submitted reports, not a single centrally audited database, so its completeness varies entry by entry. When a version range or CVE is missing, Houston still surfaces the finding, since an extension being listed in VEL at all is worth knowing, but it shows exactly what the feed gave it rather than inferring a severity or version boundary the source data does not support. If a finding shows up with no CVE attached, that is VEL's own gap, not something Houston hid. If you are coming from WordPress and wondering how this compares to Wordfence or WPScan's own vulnerability database, see the honest comparison.

Backfilling severity: NVD, then CVE.org

When a finding does carry a real CVE id, from VEL or from the Security Centre feed, Houston looks up an accurate CVSS score for it automatically. It checks the National Vulnerability Database (NVD) first, and only if NVD has nothing for that id, falls back to the CVE.org record itself, through the same CVE Services API the CVE Program runs. Neither call happens for a finding without a real CVE id, and neither ever overwrites a caller-supplied severity with a guess.

The fallback exists because NVD's own scoring backlog became a standing gap in 2026: unscored records from before 1 March 2026 moved into a permanent "Not Scheduled" state, and new scoring now prioritizes vulnerabilities tied to CISA's Known Exploited Vulnerabilities list or federal-critical relevance. A small, disclosed vulnerability in a Joomla extension is exactly the kind of finding that increasingly never gets scored by NVD at all.

CVE.org's own record is an independent second source for the same score. Houston checks the CNA container first, though the CNA, Joomla's own security team in most cases, rarely supplies a CVSS score itself, then every ADP container, since CISA's Vulnrichment program backfills scores directly into exactly that part of the record. The two sources turn out to be genuinely complementary, not just one covering for the other's gaps: in one live-verified case, a disclosed vulnerability in Helix3, a widely used Joomla template framework, had no NVD score at all, but its CVE.org record's ADP container carried a CVSS 3.1 score of 7.5.