Alerta de seguridad en Joomla: 12+ extensiones populares corrigen vulnerabilidades graves

Las vulnerabilidades encontradas en apenas un mes

La siguiente tabla resume las extensiones afectadas, el tipo de problema descubierto, su identificador CVE y la puntuación CVSS asignada.

El sistema CVSS permite expresar la gravedad técnica de una vulnerabilidad en una escala de 0 a 10. Una puntuación elevada no significa que todos los sitios puedan ser atacados de la misma manera, ya que la configuración y las funciones utilizadas también influyen, pero sí ayuda a establecer prioridades.

Actualizaciones de seguridad oficiales sin CVE público

Además de las vulnerabilidades con identificador CVE, JoomDonation publicó durante julio varias versiones que corrigen problemas de seguridad reconocidos por el propio desarrollador.

¿Por qué esta lista merece una atención especial?

No todas las vulnerabilidades tienen la misma gravedad ni producen las mismas consecuencias.

En este caso, la lista contiene un número considerable de incidencias que pueden atacarse sin disponer de una cuenta en la web.

Esto significa que el atacante no necesita conocer una contraseña, engañar previamente a un administrador ni conseguir acceso al panel de control. Le basta con localizar una instalación vulnerable y enviar una petición especialmente manipulada.

Los fallos que permiten subir archivos ejecutables son especialmente preocupantes porque pueden otorgar al atacante un control muy amplio sobre el servidor.

La seguridad no termina al actualizar Joomla

Todavía existe la falsa sensación de que instalar la última versión del CMS es suficiente para mantener una página protegida.

Nada más lejos de la realidad.

Una instalación Joomla está formada por diferentes piezas:

• El núcleo del CMS.
• La plantilla.
• Los componentes.
• Los módulos.
• Los plugins.
• Las bibliotecas externas.
• Los constructores visuales.
• Las integraciones con otros servicios.

Cada una de ellas puede recibir nuevas funciones, mejoras de rendimiento, correcciones de errores o parches de seguridad.

Una web perfectamente actualizada hace seis meses puede ser vulnerable hoy si una de sus extensiones ha publicado una corrección que todavía no se ha instalado.

Precisamente ahí concentran sus esfuerzos muchos atacantes.

En numerosos casos no buscan vulnerabilidades desconocidas. Buscan instalaciones que siguen utilizando versiones antiguas de componentes ampliamente extendidos.

Una vez publicado un parche, pueden comparar automáticamente la versión anterior con la nueva, identificar las líneas modificadas y deducir qué error se ha corregido.

Después comienzan los escaneos masivos.

Ejecución remota de código: el escenario más grave

Las siglas RCE proceden de Remote Code Execution, o ejecución remota de código.

Este tipo de vulnerabilidad permite que un atacante ejecute instrucciones en el servidor que aloja la página web.

Dependiendo de los permisos del proceso afectado, podría:

• Instalar una puerta trasera.
• Crear usuarios administrativos.
• Modificar el contenido del sitio.
• Robar información.
• Eliminar archivos.
• Enviar spam.
• Redirigir a los visitantes.
• Distribuir malware.
• Utilizar el servidor para atacar otros sistemas.

En esta investigación, seis extensiones presentaban problemas de subida de archivos que podían desembocar en una RCE:

Cinco de ellas podían ser atacadas sin iniciar sesión.

Actualizar impide nuevos intentos de explotación, pero no elimina automáticamente una puerta trasera que ya se hubiera instalado.

RSFiles!: subida de archivos sin autenticación

RSFiles! es una extensión destinada a la gestión y distribución de archivos.

La vulnerabilidad CVE-2026-57827 permitía que una persona sin autenticar intentara subir archivos ejecutables.

Si el archivo se almacenaba en una ubicación accesible desde Internet y el servidor permitía procesarlo como PHP, el atacante podía ejecutarlo posteriormente y tomar el control del sitio.

La vulnerabilidad recibió una puntuación CVSS de 10,0, el máximo de la escala.

La ausencia de autenticación es uno de los factores que explica esta valoración. Cualquier sistema automatizado podía intentar localizar una instalación expuesta sin necesidad de disponer previamente de un usuario.

Balbooa Forms: los formularios como vía de entrada

Los formularios son uno de los elementos más expuestos de cualquier sitio web.

Formularios de contacto, solicitudes de presupuesto, registros y sistemas para adjuntar documentos reciben información directamente desde Internet. Por ello, deben aplicar controles muy estrictos sobre los datos y los archivos enviados.

Balbooa Forms presentaba una vulnerabilidad de subida arbitraria de archivos sin autenticación, identificada como CVE-2026-56291 .

El fallo podía permitir que un atacante subiera un archivo ejecutable y lo utilizara para ejecutar código en el servidor.

Su puntuación CVSS de 10,0 refleja el impacto potencial de una explotación exitosa.

Este caso demuestra que permitir archivos adjuntos en un formulario no es una función menor. La extensión debe comprobar:

• La extensión del fichero.
• Su tipo MIME.
• El contenido real del archivo.
• El nombre utilizado.
• El directorio de destino.
• Los permisos de la persona que realiza el envío.

También es recomendable almacenar los archivos fuera de rutas ejecutables y generar nombres aleatorios para evitar accesos predecibles.

Page Builder CK: un constructor visual con capacidad de subida

Page Builder CK permite construir páginas mediante una interfaz visual.

Sin embargo, los constructores modernos hacen mucho más que modificar estilos. Pueden procesar formularios, importar diseños, gestionar imágenes, consultar la base de datos y comunicarse mediante puntos finales AJAX.

La vulnerabilidad CVE-2026-56290 permitía subir archivos ejecutables sin autenticación y podía terminar en una RCE completa.

También recibió una puntuación CVSS de 10,0.

Este caso recuerda que una extensión aparentemente relacionada solo con el diseño puede tener acceso a funciones muy sensibles del servidor.

Después de actualizar conviene revisar tanto el componente principal como los plugins, módulos o paquetes adicionales instalados junto al constructor.

SP Page Builder: una extensión muy extendida con un fallo crítico

SP Page Builder es uno de los constructores visuales más conocidos del ecosistema Joomla.

La vulnerabilidad CVE-2026-48908 permitía que usuarios no autenticados subieran archivos arbitrarios, incluyendo código PHP ejecutable.

Su puntuación CVSS fue de 10,0.

La enorme popularidad del producto incrementa el interés de los atacantes. Una vulnerabilidad en una extensión utilizada por miles de sitios puede incorporarse rápidamente a herramientas automáticas de escaneo.

Después de instalar el parche también merece la pena revisar:

• Los directorios multimedia.
• Las carpetas temporales.
• Los archivos PHP modificados recientemente.
• Las plantillas alteradas.
• Los plugins desconocidos.
• Las cuentas con privilegios administrativos.
• Los registros correspondientes a las funciones de subida.

Una página comprometida puede seguir funcionando con aparente normalidad mientras mantiene código malicioso oculto.

JCE Editor: ejecución remota de código explotada activamente

Una de las incidencias de seguridad más importantes de 2026 afectó al popular editor JCE.

La vulnerabilidad CVE-2026-48907 permitía que un atacante sin autenticar creara perfiles del editor y los utilizara para subir y ejecutar código PHP en el servidor.

Una explotación exitosa podía conducir a una ejecución remota de código y comprometer completamente el sitio web.

El fallo afectaba a todas las versiones anteriores a JCE 2.9.99.5 y recibió una valoración crítica de 9,8 en CVSS 3.1 y 10,0 en CVSS 4.0.

La primera versión que corrigió la vulnerabilidad fue la 2.9.99.5, pero las versiones posteriores incorporaron medidas adicionales de endurecimiento de seguridad.

Si la actualización se realizó después de conocerse la vulnerabilidad, también conviene revisar el sitio para detectar posibles indicios de compromiso, prestando especial atención a:

• Perfiles de JCE desconocidos o modificados sin autorización.
• Archivos PHP, PHTML o similares en directorios de subida, temporales o multimedia.
• Archivos creados o modificados recientemente.
• Registros de acceso relacionados con la importación o creación de perfiles.
• Nuevos usuarios administrativos o cambios de permisos.
• Puertas traseras, tareas programadas o código ofuscado.

Actualizar impide nuevos intentos contra esta vulnerabilidad, pero no elimina el código malicioso que pudiera haberse instalado previamente.

Consulta el historial oficial de versiones de JCE y el registro de CISA KEV .

iCagenda: archivos adjuntos convertidos en código ejecutable

iCagenda es una extensión utilizada para publicar y gestionar eventos.

La vulnerabilidad CVE-2026-48939 afectaba a su función de archivos adjuntos.

Un atacante podía intentar cargar un archivo PHP sin iniciar sesión y ejecutarlo posteriormente desde el servidor.

La incidencia recibió una puntuación CVSS de 9,8.

Este caso pone de manifiesto que cualquier función de subida puede convertirse en un punto crítico:

• Imágenes de eventos.
• Currículos.
• Facturas.
• Documentación.
• Archivos de soporte.
• Formularios.
• Avatares.
• Recursos descargables.

La aplicación debe utilizar una lista cerrada de formatos permitidos, verificar el contenido y evitar que los directorios de subida ejecuten scripts.

DJ-Classifieds: subida de archivos sin autenticación

En julio de 2026 se descubrió una vulnerabilidad crítica en el componente DJ-Classifieds, identificada como CVE-2026-61424 .

El fallo permitía a un atacante subir archivos al servidor sin necesidad de iniciar sesión mediante el endpoint imageupload. En determinados entornos, una carga maliciosa podía terminar en ejecución remota de código y comprometer completamente el sitio web.

Las evaluaciones publicadas sitúan su gravedad entre 8,8 y 10,0 en la escala CVSS. La vulnerabilidad afectaba a las versiones de DJ-Classifieds hasta la 3.11.1.

Membership Pro: subida de archivos por usuarios no autenticados

Membership Pro también recibió durante julio una actualización de seguridad para corregir la vulnerabilidad CVE-2026-62415 .

El problema permitía la subida de archivos por parte de usuarios no autenticados y recibió una puntuación CVSS de 9,1, por lo que debe tratarse como una incidencia crítica.

La corrección se incluyó en la versión 4.6.2. Las instalaciones que utilicen una versión anterior deben actualizarse inmediatamente desde el canal oficial y revisar los directorios de subida y los archivos creados recientemente.

Articles Anywhere y Modules Anywhere: ejecución de PHP mediante etiquetas

Regular Labs publicó una actualización de seguridad para corregir dos vulnerabilidades de gravedad alta que afectan a Articles Anywhere y Modules Anywhere.

Según el aviso de Regular Labs, ambos fallos podían permitir que un atacante con determinados permisos inyectara y ejecutara código PHP mediante las etiquetas específicas de las extensiones debido a una validación insuficiente de las entradas.

La explotación dependía de que el usuario pudiera utilizar estas etiquetas en el contexto afectado, por lo que la exposición concreta puede variar según los permisos y la configuración de cada instalación.

Phoca Download: el riesgo de las cuentas registradas

Phoca Download presenta una diferencia importante respecto a los casos anteriores.

La vulnerabilidad CVE-2026-57828 necesitaba que el atacante dispusiera de una cuenta con acceso a las funciones de subida.

Esto reduce la exposición, pero no elimina el riesgo.

Una cuenta registrada puede:

• Haber sido robada.
• Utilizar una contraseña débil.
• Pertenecer a un antiguo colaborador.
• Haber recibido permisos excesivos.
• Haberse creado mediante otra vulnerabilidad.
• Ser controlada por una persona que ya no debería tener acceso.

El fallo podía permitir la carga de archivos ejecutables y conducir a una RCE completa, por lo que recibió una puntuación CVSS de 9,0.

Después de actualizar Phoca Download también es recomendable revisar qué grupos pueden subir archivos y comprobar que no existan permisos heredados innecesarios.

Inyección SQL: acceso indebido a la base de datos

Las vulnerabilidades de inyección SQL se producen cuando una aplicación incorpora datos recibidos desde el exterior en una consulta sin tratarlos de forma segura.

Un atacante puede manipular esa entrada para alterar la consulta enviada a la base de datos.

Dependiendo del fallo, podría:

• Consultar información privada.
• Enumerar usuarios.
• Obtener direcciones de correo.
• Acceder a configuraciones.
• Extraer datos de formularios.
• Modificar registros.
• Eliminar información.
• Preparar ataques posteriores.

Joomla dispone de herramientas para construir consultas seguras, pero cada extensión debe utilizarlas correctamente.

En esta investigación se descubrieron cuatro vulnerabilidades SQL Injection sin autenticación:

Todas recibieron una puntuación CVSS de 8,7.

Posteriormente, Joom Donation 7.6 corrigió también una vulnerabilidad de tipo Blind SQL Injection, aunque en este caso no se publicó un identificador CVE.

AcyMailing: riesgo para los datos de suscriptores

AcyMailing es una de las soluciones más conocidas para gestionar boletines y campañas de correo desde Joomla.

La vulnerabilidad CVE-2026-56292 permitía realizar una inyección SQL sin necesidad de iniciar sesión.

La explotación podía conducir a un acceso no autorizado a la base de datos y a una filtración de información.

El impacto potencial va más allá de la propia página web. Una instalación de AcyMailing puede almacenar:

• Nombres.
• Direcciones de correo.
• Preferencias de suscripción.
• Listas y segmentos.
• Historiales de campañas.
• Información sobre aperturas y clics.
• Datos utilizados para personalizar los envíos.

Una filtración podría generar problemas relacionados con la protección de datos y facilitar campañas de phishing dirigidas contra los suscriptores.

Después de actualizar, conviene revisar los registros del servidor, las exportaciones realizadas y cualquier actividad anómala durante el periodo de exposición.

DPCalendar: información privada en calendarios y reservas

DPCalendar permite crear calendarios, gestionar eventos y conectar Joomla con otros servicios.

La vulnerabilidad CVE-2026-57831 hacía posible una inyección SQL sin autenticación.

El principal riesgo era la pérdida de confidencialidad de los datos almacenados.

Dependiendo del uso de la extensión, la base de datos podría contener:

• Eventos internos.
• Datos de asistentes.
• Direcciones.
• Reservas.
• Enlaces privados.
• Identificadores de usuarios.
• Información sobre pagos.
• Tokens de servicios externos.

No todas las instalaciones contienen la misma información, pero la gravedad del problema no debe valorarse únicamente por lo que aparece públicamente en el calendario.

Los registros internos pueden contener muchos más datos que la vista frontal.

EDocman: proteger los documentos y sus metadatos

EDocman es un gestor documental para Joomla.

La vulnerabilidad CVE-2026-57832 permitía realizar una inyección SQL sin autenticación.

Los gestores documentales requieren una atención especial porque pueden almacenar:

• Contratos.
• Facturas.
• Informes.
• Manuales internos.
• Documentación para clientes.
• Archivos restringidos.
• Información asociada a las descargas.

Aunque un documento esté protegido desde la interfaz normal, una vulnerabilidad SQL puede exponer metadatos, identificadores, nombres de archivo, rutas o relaciones almacenadas en la base de datos.

Tras actualizar EDocman conviene comprobar también los permisos de las categorías y verificar que los documentos privados no sean accesibles mediante direcciones predecibles.

Quix Page Builder: el diseño también interactúa con la base de datos

Quix Page Builder es otra solución destinada a crear páginas visualmente.

Su vulnerabilidad CVE-2026-58078 permitía llevar a cabo una inyección SQL sin autenticación.

Los constructores visuales no se limitan a generar HTML y CSS. También pueden interactuar con:

• Artículos.
• Menús.
• Plantillas.
• Elementos dinámicos.
• Formularios.
• Consultas.
• Integraciones externas.
• Funciones AJAX.
• Bibliotecas complementarias.

Por eso una vulnerabilidad en un constructor puede tener un alcance mucho mayor del que sugiere su función visual.

Es recomendable comprobar tanto la extensión principal como los plugins y módulos incluidos en el paquete.

Actualizaciones de seguridad de JoomDonation en julio de 2026

Además de Membership Pro, el desarrollador JoomDonation publicó durante julio correcciones de seguridad para Joom Donation y Events Booking. No todos estos fallos disponen de un CVE público, pero las versiones fueron presentadas oficialmente como actualizaciones de seguridad y deben instalarse con prioridad.

Helix Ultimate y Helix3: permisos, XSS y manipulación de archivos

¿Por qué se encuentran tantas vulnerabilidades en poco tiempo?

La publicación de numerosos avisos consecutivos no significa necesariamente que el software sea ahora más inseguro.

En buena medida, significa que la capacidad para localizar fallos ha mejorado.

Cada vez existen más investigadores revisando código. Las herramientas automáticas pueden detectar patrones inseguros que hace unos años pasaban desapercibidos. La inteligencia artificial también está acelerando este proceso.

Hoy es posible analizar miles de líneas de código para localizar:

• Errores de validación.
• Consultas SQL inseguras.
• Comprobaciones de permisos ausentes.
• Puntos finales AJAX expuestos.
• Funciones obsoletas.
• Tratamiento incorrecto de archivos.
• Salidas sin escapar.
• Dependencias vulnerables.

Esto provoca que se publiquen más avisos, pero también permite corregir los problemas antes.

Hace años no era extraño descubrir fallos que llevaban presentes durante mucho tiempo. Actualmente, el periodo entre la detección y la publicación de un parche suele ser menor.

Eso es positivo para la comunidad.

La otra cara de la inteligencia artificial

Las mismas herramientas utilizadas por investigadores y desarrolladores también pueden ayudar a los atacantes.

Cuando se publica una nueva versión, es posible comparar automáticamente el código anterior con el actualizado.

Si se detectan las líneas modificadas, puede deducirse qué error se ha corregido. A partir de ahí, un atacante puede:

1. Crear una prueba de explotación.
2. Buscar instalaciones con la versión vulnerable.
3. Automatizar los intentos de ataque.
4. Clasificar las webs según su respuesta.
5. Comprometer múltiples sitios en poco tiempo.

Por eso retrasar una actualización grave aumenta rápidamente el riesgo.

Publicar el parche también informa indirectamente de que existía un fallo. Esta situación se conoce habitualmente como patch diffing: el análisis de las diferencias entre versiones para reconstruir la vulnerabilidad corregida.

Actualizar no siempre es suficiente

Cuando una vulnerabilidad ha estado disponible durante cierto tiempo, instalar la nueva versión es solo una parte de la respuesta.

La actualización evita nuevos intentos de explotación, pero no revierte una intrusión anterior.

Esto resulta especialmente importante en los fallos de:

• Ejecución remota de código.
• Subida arbitraria de archivos.
• Escritura o eliminación de ficheros.
• Creación de perfiles o usuarios.
• Inyección SQL con exposición de datos.

La presencia de funciones como eval, base64_decode o gzinflate no demuestra por sí sola que exista malware, ya que también pueden aparecer en software legítimo. Sin embargo, encontrarlas en archivos desconocidos o modificados recientemente justifica una investigación más profunda.

Si se confirma una intrusión, normalmente es más seguro restaurar una copia limpia, actualizar todo el software y renovar las credenciales que limitarse a borrar el archivo sospechoso.

Cinco errores que siguen cometiendo muchos administradores Joomla

Qué debes hacer ahora

Si administras una o varias instalaciones Joomla, sigue este procedimiento:

1. Haz un inventario de las extensiones instaladas.
2. Comprueba si utilizas alguno de los doce productos mencionados.
3. Comprueba también si están instalados Articles Anywhere o Modules Anywhere y revisa quién puede utilizar sus etiquetas.
4. Anota la versión de cada componente, módulo, plugin y plantilla relacionada.
5. Consulta el aviso oficial del desarrollador.
6. Realiza una copia completa de archivos y base de datos.
7. Guarda una copia fuera del servidor.
8. Instala la versión corregida desde el canal oficial.
9. Limpia la caché y comprueba el funcionamiento del sitio.
10. Revisa los usuarios con privilegios elevados.
11. Analiza los registros y los archivos modificados recientemente.
12. Elimina las extensiones que ya no se utilicen.
13. Documenta la fecha y el resultado de la revisión.

Checklist de seguridad para Joomla

Esta lista permite realizar una revisión rápida:

Completar la lista no convierte una instalación en invulnerable, pero reduce considerablemente la exposición frente a los ataques más habituales.

Cuando publicar una vulnerabilidad es una buena señal

Puede parecer contradictorio, pero una extensión que nunca publica avisos de seguridad no tiene por qué ser más segura que otra que corrige varios fallos.

En ocasiones ocurre exactamente lo contrario.

Los proyectos activos:

• Revisan su código.
• Reciben informes de investigadores.
• Publican actualizaciones.
• Mantienen la compatibilidad.
• Informan a sus usuarios.
• Responden ante una incidencia.

El verdadero peligro aparece cuando una extensión deja de mantenerse y nadie revisa su código.

En esos casos, cualquier vulnerabilidad puede permanecer abierta indefinidamente.

Por eso, al elegir una extensión no deberíamos valorar únicamente sus funciones. También conviene analizar:

• La frecuencia de las actualizaciones.
• La actividad reciente del proyecto.
• La comunicación del desarrollador.
• La compatibilidad con versiones actuales.
• La existencia de soporte.
• La rapidez con la que se solucionan las incidencias.
• El canal para comunicar problemas de seguridad.

Una extensión activa y bien mantenida suele ofrecer mayores garantías que un producto abandonado.

La seguridad no es un estado, sino un proceso

Actualizar Joomla una vez no garantiza que la web vaya a permanecer segura para siempre.

Cada versión del CMS, cada actualización de una extensión, cada cambio en PHP y cada modificación del servidor forman parte de un proceso continuo.

La seguridad evoluciona al mismo ritmo que el software y las técnicas de ataque.

Por eso, un buen mantenimiento no debería depender de revisiones esporádicas realizadas cuando ya ha aparecido un problema.

Lo recomendable es establecer una rutina para:

• Revisar actualizaciones.
• Verificar las copias.
• Comprobar los registros.
• Eliminar extensiones innecesarias.
• Revisar permisos.
• Controlar las funciones de subida.
• Verificar el estado del servidor.
• Documentar los cambios.

La constancia resulta mucho más eficaz que reaccionar únicamente cuando se publica una alerta.