El feed VEL de Joomla!, explicado

El escaneo diario de Houston se basa en dos feeds que el propio Joomla publica: el feed VEL para las extensiones y el feed del Security Centre para el núcleo. Esta página trata el primero: qué es realmente VEL, qué contiene cada entrada y dónde flaquean sus datos, para que una alerta suya signifique exactamente lo que dice y nada más.

Qué es realmente VEL

VEL son las siglas de Vulnerable Extensions List. Es un feed gratuito y público publicado en extensions.joomla.org, el mismo sitio donde se aloja el Joomla Extensions Directory, y no es una base de datos de CVE de propósito general. Existe específicamente para rastrear vulnerabilidades conocidas en extensiones de terceros para Joomla: componentes, plugins, módulos y plantillas, a diferencia del propio núcleo de Joomla, que cuenta con su propio feed independiente, tratado más abajo. No hace falta ninguna clave API para leerlo, y es la misma fuente que consulta Houston cada día.

Qué contiene cada entrada

Una entrada de VEL vincula una vulnerabilidad a una extensión concreta, identificada por su nombre de elemento de Joomla. Cuando el informe original lo permite, la entrada también incluye un rango de versiones afectadas, de modo que una versión ya corregida de la extensión deja de coincidir, una referencia a un identificador CVE oficial cuando el hallazgo tiene uno, y una indicación de gravedad. No todas las entradas tienen los tres datos. Algunas incluyen un CVE y un rango de versiones preciso. Otras se registran solo con el nombre de la extensión, dejando en blanco el rango de versiones o el CVE porque el informe original no lo incluía.

VEL frente al feed del Security Centre

VEL solo cubre extensiones de terceros. No dice nada sobre el propio núcleo de Joomla. Para eso, Joomla publica un feed independiente desde su propio Security Centre, el canal oficial que el equipo de seguridad de Joomla utiliza para anunciar vulnerabilidades del núcleo y las versiones que las corrigen. Houston lee ambos feeds cada día: VEL para todo lo instalado más allá del núcleo, y el feed del Security Centre para la propia versión del núcleo. Un sitio puede estar al día en uno y atrasado en el otro, así que comprobar solo uno de los dos deja un vacío real. Consulta por qué el propio aviso de actualización de Joomla no cubre esto por sí solo para saber más sobre esa distinción.

Cómo lo lee Houston sin añadir carga

VEL es un recurso público y compartido, y un escaneo que se ejecutase de forma independiente en cada instalación de Houston, potencialmente miles de sitios, cada uno con su propio horario diario, generaría una carga real sobre él si cada escaneo descargase el feed completo. Houston comprueba primero un endpoint ligero de verificación de hash, y solo descarga el feed completo, actualmente del orden de unos pocos cientos de entradas, cuando ese hash ha cambiado realmente desde su última sincronización correcta. La mayoría de los días, eso significa una petición pequeña, no una nueva descarga completa.

Dónde flaquean los datos

VEL es la mejor fuente gratuita de su tipo para Joomla, pero se compone de informes enviados de forma independiente, no de una única base de datos auditada de forma centralizada, así que su nivel de detalle varía entrada por entrada. Cuando falta un rango de versiones o un CVE, Houston sigue mostrando el hallazgo, ya que el mero hecho de que una extensión figure en VEL ya merece saberse, pero muestra exactamente lo que le ha dado el feed en lugar de inferir una gravedad o un límite de versiones que los datos de origen no respaldan. Si un hallazgo aparece sin ningún CVE asociado, ese es un vacío propio de VEL, no algo que Houston haya ocultado. Si vienes de WordPress y te preguntas cómo se compara esto con la propia base de datos de vulnerabilidades de Wordfence o WPScan, consulta la comparación honesta.

Rellenar la gravedad a posteriori: NVD y luego CVE.org

Cuando un hallazgo sí lleva un identificador CVE real, ya sea de VEL o del feed del Security Centre, Houston busca automáticamente una puntuación CVSS precisa para él. Primero consulta la National Vulnerability Database (NVD) y, solo si NVD no tiene nada para ese identificador, recurre al propio registro de CVE.org, a través de la misma CVE Services API que gestiona el CVE Program. Ninguna de las dos llamadas se produce para un hallazgo sin un identificador CVE real, y ninguna de ellas sobrescribe jamás con una suposición una gravedad ya proporcionada.

Este mecanismo de respaldo existe porque el propio retraso de puntuación de NVD se convirtió en un vacío permanente en 2026: los registros sin puntuar de antes del 1 de marzo de 2026 pasaron a un estado permanente de «Not Scheduled», y la nueva puntuación ahora prioriza las vulnerabilidades vinculadas a la lista Known Exploited Vulnerabilities de CISA o con relevancia crítica federal. Una vulnerabilidad pequeña y ya divulgada en una extensión de Joomla es exactamente el tipo de hallazgo que, cada vez más, NVD nunca llega a puntuar.

El propio registro de CVE.org es una segunda fuente independiente para la misma puntuación. Houston comprueba primero el contenedor CNA, aunque el CNA, el propio equipo de seguridad de Joomla en la mayoría de los casos, rara vez aporta él mismo una puntuación CVSS, y después revisa cada contenedor ADP, ya que el programa Vulnrichment de CISA rellena puntuaciones directamente en esa parte concreta del registro. Las dos fuentes resultan ser realmente complementarias, y no que una simplemente cubra los vacíos de la otra: en un caso verificado en vivo, una vulnerabilidad divulgada en Helix3, un framework de plantillas de Joomla muy utilizado, no tenía ninguna puntuación de NVD, pero el contenedor ADP de su registro en CVE.org llevaba una puntuación CVSS 3.1 de 7.5.