Der Joomla! VEL-Feed, erklärt

Houstons täglicher Scan basiert auf zwei Feeds, die Joomla selbst veröffentlicht: dem VEL-Feed für Erweiterungen und dem Security-Centre-Feed für den Core. Diese Seite behandelt den ersten davon: was VEL eigentlich ist, was jeder Eintrag enthält und wo die Daten dünn werden – damit eine Meldung daraus genau das bedeutet, was sie sagt, und nicht mehr.

Was VEL eigentlich ist

VEL steht für Vulnerable Extensions List. Es handelt sich um einen kostenlosen, öffentlichen Feed, der auf extensions.joomla.org veröffentlicht wird – derselben Seite, auf der auch das Joomla Extensions Directory läuft – und nicht um eine allgemeine CVE-Datenbank. VEL existiert speziell, um bekannte Schwachstellen in Joomla-Erweiterungen von Drittanbietern zu erfassen: Komponenten, Plugins, Module und Templates, im Unterschied zum Joomla-Core selbst, der weiter unten einen eigenen, separaten Feed hat. Zum Lesen ist kein API-Key nötig, und es ist dieselbe Quelle, die Houston täglich abfragt.

Was ein Eintrag enthält

Ein VEL-Eintrag verknüpft eine Schwachstelle mit einer bestimmten Erweiterung, identifiziert über ihren Joomla-Elementnamen. Wo der zugrunde liegende Bericht es hergibt, enthält ein Eintrag zusätzlich einen betroffenen Versionsbereich – sodass eine gepatchte Erweiterungsversion nicht mehr erfasst wird –, einen Verweis auf eine offizielle CVE-Kennung, sofern der Fund eine hat, sowie eine Angabe zum Schweregrad. Nicht jeder Eintrag hat alle drei. Manche enthalten eine CVE und einen präzisen Versionsbereich. Andere sind nur als Erweiterungsname erfasst, wobei Versionsbereich oder CVE leer bleiben, weil der ursprüngliche Bericht keine Angabe dazu enthielt.

VEL im Vergleich zum Security-Centre-Feed

VEL deckt nur Erweiterungen von Drittanbietern ab. Über den Joomla-Core selbst sagt es nichts aus. Dafür veröffentlicht Joomla einen separaten Feed aus seinem eigenen Security Centre, dem offiziellen Kanal, über den Joomlas Sicherheitsteam Core-Schwachstellen und behobene Releases bekannt gibt. Houston liest täglich beide Feeds: VEL für alles, was über den Core hinaus installiert ist, und den Security-Centre-Feed für die Core-Version selbst. Eine Website kann beim einen aktuell sein und beim anderen hinterherhinken – wer nur einen der beiden prüft, lässt also eine echte Lücke offen. Mehr zu dieser Unterscheidung findest du unter warum Joomlas eigener Update-Hinweis das nicht von allein abdeckt.

Wie Houston den Feed liest, ohne Last zu erzeugen

VEL ist eine öffentliche, gemeinsam genutzte Ressource. Ein Scan, der unabhängig auf jeder Houston-Installation läuft – potenziell Tausende von Websites, jede mit ihrem eigenen täglichen Zeitplan –, würde eine echte Last erzeugen, wenn jeder einzelne Scan den kompletten Feed abrufen würde. Houston prüft zuerst einen leichtgewichtigen Verify-Hash-Endpunkt und lädt den vollständigen Feed, derzeit in der Grössenordnung von einigen Hundert Einträgen, nur dann herunter, wenn sich dieser Hash seit der letzten erfolgreichen Synchronisierung tatsächlich geändert hat. An den meisten Tagen bedeutet das eine kleine Anfrage, keinen vollständigen erneuten Download.

Wo die Daten dünn werden

VEL ist die beste kostenlose Quelle ihrer Art für Joomla, wird aber aus unabhängig eingereichten Berichten zusammengestellt und nicht aus einer zentral geprüften Datenbank – die Vollständigkeit variiert daher von Eintrag zu Eintrag. Fehlt ein Versionsbereich oder eine CVE, zeigt Houston den Fund trotzdem an, denn schon die blosse Tatsache, dass eine Erweiterung in VEL gelistet ist, ist wissenswert. Houston zeigt dabei aber genau das, was der Feed geliefert hat, statt einen Schweregrad oder eine Versionsgrenze zu erraten, die die Quelldaten nicht hergeben. Taucht ein Fund ohne zugehörige CVE auf, ist das eine Lücke von VEL selbst – nichts, was Houston verbirgt. Wer von WordPress kommt und wissen möchte, wie sich das mit Wordfence oder WPScans eigener Schwachstellendatenbank vergleicht, findet den ehrlichen Vergleich.

Schweregrad nachträglich ergänzen: NVD, dann CVE.org

Trägt ein Fund tatsächlich eine echte CVE-ID – aus VEL oder aus dem Security-Centre-Feed –, sucht Houston automatisch einen präzisen CVSS-Score dafür. Zuerst wird die National Vulnerability Database (NVD) geprüft, und nur wenn NVD zu dieser ID nichts liefert, greift Houston auf den CVE.org-Datensatz selbst zurück, über dieselbe CVE Services API, die das CVE Program betreibt. Keiner der beiden Aufrufe erfolgt bei einem Fund ohne echte CVE-ID, und keiner überschreibt je einen bereits vorliegenden Schweregrad mit einer Schätzung.

Der Fallback existiert, weil NVDs eigener Rückstau bei der Bewertung 2026 zu einer dauerhaften Lücke wurde: unbewertete Datensätze von vor dem 1. März 2026 wechselten in einen permanenten Zustand «Not Scheduled», und neue Bewertungen priorisieren inzwischen Schwachstellen, die mit CISAs Known Exploited Vulnerabilities-Liste verknüpft sind oder eine bundeskritische Relevanz aufweisen. Eine kleine, offengelegte Schwachstelle in einer Joomla-Erweiterung ist genau die Art von Fund, der zunehmend nie von NVD bewertet wird.

CVE.orgs eigener Datensatz ist eine unabhängige zweite Quelle für denselben Score. Houston prüft zuerst den CNA-Container, auch wenn die CNA – in den meisten Fällen Joomlas eigenes Sicherheitsteam – selbst nur selten einen CVSS-Score liefert, danach jeden ADP-Container, da CISAs Vulnrichment-Programm Scores direkt in genau diesen Teil des Datensatzes nachträgt. Die beiden Quellen erweisen sich als wirklich komplementär und nicht nur als gegenseitige Lückenfüller: In einem live verifizierten Fall hatte eine offengelegte Schwachstelle in Helix3, einem weitverbreiteten Joomla-Template-Framework, überhaupt keinen NVD-Score, aber der ADP-Container ihres CVE.org-Datensatzes trug einen CVSS-3.1-Score von 7.5.