Ataques a Joomla: JCE, SP Page Builder y Helix

Qué ha cambiado desde la primera versión de esta guía

La primera revisión se centraba en unas cuantas piezas muy conocidas. Desde entonces la investigación se ha ampliado y ha empezado a aparecer un patrón bastante claro.

Entre mediados de junio y finales de julio, una única empresa de monitorización de Joomla comunicó diecinueve vulnerabilidades distintas repartidas entre diecisiete extensiones. Algunas eran componentes de comercio electrónico, otras calendarios, gestores de documentos, constructores visuales, formularios o frameworks de plantilla.

No estamos hablando de diecisiete extensiones abandonadas que alguien encontró en una copia de Joomla 2.5 detrás de una estantería.

Hay productos conocidos, mantenidos y ampliamente utilizados.

Y después de esa recopilación todavía han aparecido las nuevas vulnerabilidades de SP Page Builder del 27 de julio y otras revisiones de seguridad.

El dato importante no es el número.

Lo importante es que se repiten unas cuantas clases de fallo:

• Endpoints públicos que aceptan operaciones sin comprobar correctamente autenticación o permisos.
• Subidas de archivos con una validación insuficiente.
• Parámetros enviados por el visitante que terminan dentro de una consulta SQL.
• Acciones AJAX accesibles desde el frontend con comprobaciones incompletas.
• Rutas de archivos manipulables.
• Datos que se entregan sin comprobar que pertenecen al usuario que los solicita.
• Funciones administrativas protegidas por controles que no eran tan administrativos como parecía.

La buena noticia es que hay correcciones disponibles para los problemas que se describen aquí.

La menos buena es que tener una corrección disponible y tener todas las webs actualizadas son dos conceptos que mantienen desde hace años una relación bastante distante.

Versiones que deben revisarse

Estado comprobado a 28 de julio de 2026. Cuando exista una versión posterior estable, utiliza la más reciente compatible y revisa el registro del desarrollador antes de instalarla.

Hay vulnerabilidades que ya están siendo explotadas

A estas alturas conviene separar los fallos potencialmente explotables de aquellos para los que ya existe evidencia de explotación real.

El catálogo KEV de CISA incluye actualmente varias vulnerabilidades que afectan a extensiones mencionadas en esta guía:

• CVE-2026-48907 — JCE.
• CVE-2026-48908 — SP Page Builder.
• CVE-2026-56290 — PageBuilder CK.
• CVE-2026-48939 — iCagenda.
• CVE-2026-56291 — Balbooa Forms.

Que una vulnerabilidad aparezca en KEV no significa que tu web haya sido comprometida.

Significa algo bastante menos tranquilizador: que ya no estamos discutiendo si alguien podría aprovecharla. Alguien lo ha hecho.

Eso también cambia el criterio de revisión. Una web que ejecutó durante semanas una versión afectada por una vulnerabilidad explotada activamente merece algo más que pulsar “Actualizar” y volver a atender el teléfono.

SP Page Builder: el problema de junio ya no es el único

SP Page Builder merece su propia sección porque en apenas unas semanas ha acumulado dos episodios de seguridad distintos.

Primero: CVE-2026-48908 y la subida de PHP

SP Page Builder 6.6.2 corrigió la vulnerabilidad que permitía subir archivos arbitrarios sin autenticación y terminar ejecutando código PHP.

Los ataques observados utilizaron especialmente la tarea:

asset.uploadCustomIcon

mediante peticiones dirigidas a SP Page Builder.

Esta vulnerabilidad está en el catálogo KEV de CISA porque existe explotación confirmada.

Actualizar a 6.6.2 cerraba ese problema concreto.

La palabra importante de la frase anterior es concreto.

Después llegó SP Page Builder 6.7.1

El 27 de julio JoomShaper publicó la versión 6.7.1 con nuevas correcciones de seguridad relacionadas con Dynamic Content, Media Manager y los formularios.

Ese mismo día aparecieron cinco registros CVE vinculados a SP Page Builder anterior a 6.7.1:

• CVE-2026-65766: SQL injection sin autenticación en Dynamic Content mediante parámetros de ordenación.
• CVE-2026-65876: SQL injection sin autenticación relacionada con el parámetro catid en loadMoreArticles.
• CVE-2026-65877: SQL injection autenticada en filtros de búsqueda y fecha del Media Manager.
• CVE-2026-65878: borrado arbitrario de archivos desde Media Manager por una validación insuficiente de rutas y permisos.
• CVE-2026-65879: posibilidad de utilizar formularios para enviar correo sin autenticación debido a un secreto común incluido en el producto.

Cuatro de estos fallos forman parte de una divulgación coordinada que terminó con la publicación de 6.7.1. CVE-2026-65876 apareció además como un segundo vector SQL sobre loadMoreArticles.

Por eso algunos resúmenes publicados el día 27 hablan de cuatro vulnerabilidades y los registros CVE terminan mostrando cinco. No es que alguien haya perdido la cuenta después de comer.

Qué implica ahora una SQL injection

Esto cambia bastante la revisión posterior.

Con una subida de PHP buscas archivos, puertas traseras, tareas cron, administradores nuevos y modificaciones en el servidor.

Con una SQL injection tienes además que asumir que una persona pudo leer información de la base de datos sin escribir ningún archivo.

Entre otras cosas pueden quedar expuestos:

• Cuentas de Joomla.
• Hashes de contraseñas.
• Sesiones.
• Configuraciones guardadas por extensiones.
• Tokens y claves API almacenadas en la base de datos.
• Contenido privado.
• Datos personales.
• Información de pedidos o clientes cuando otras extensiones comparten la misma base de datos.

Un antivirus no detecta que alguien leyó una tabla SQL el martes a las tres de la mañana.

Ni siquiera necesita dejarte una nota dando las gracias.

Qué haría en una web que tuvo SP Page Builder anterior a 6.7.1

1. Actualizar a 6.7.1 o posterior.
2. Conservar los logs anteriores a la actualización.
3. Revisar peticiones dirigidas a com_sppagebuilder, Dynamic Content, loadMoreArticles, Media Manager y formularios.
4. Revisar los usuarios con permisos para editar páginas y utilizar Media Manager.
5. Invalidar sesiones administrativas y volver a autenticar a los administradores.
6. Cambiar las credenciales privilegiadas si existe cualquier indicio de acceso no autorizado.
7. Revisar tokens, secretos y claves API almacenados por Joomla o sus extensiones y rotarlos cuando el riesgo lo justifique.
8. Revisar el correo saliente y la reputación del dominio por el posible abuso de formularios.
9. Comprobar que no se hayan eliminado archivos críticos o reglas de protección.
10. Realizar además la revisión de archivos correspondiente a CVE-2026-48908, porque actualizar a 6.7.1 no borra una puerta trasera instalada durante junio.

El parche de Joomla 3 existe, pero hay que saber qué corrige

JoomShaper publicó el 15 de julio un paquete instalable para Joomla 3 destinado a corregir CVE-2026-48908 en el cargador de iconos personalizados.

Eso es una mejora importante para instalaciones que no pueden migrarse inmediatamente.

Pero el paquete documenta esa vulnerabilidad concreta.

No asumiría que ese parche del 15 de julio corrige automáticamente las vulnerabilidades que se publicaron doce días después.

Una web Joomla 3 con una rama heredada de SP Page Builder debe comprobar específicamente qué código utiliza, qué funciones están presentes y qué correcciones ofrece el proveedor para esa rama.

Un parche de emergencia es una salida temporal. No convierte Joomla 3 en una plataforma que acaba de salir del horno.

La regla antigua de SP Page Builder sigue siendo útil, pero ya no basta

La contención que incluía la primera versión de esta guía para asset.uploadCustomIcon sigue teniendo sentido frente a CVE-2026-48908 cuando una instalación no puede actualizarse inmediatamente.

En Cloudflare:

(http.request.uri.query contains "option=com_sppagebuilder"
 and
 (
   http.request.uri.query contains "task=asset.uploadCustomIcon"
   or
   http.request.uri.query contains "task=asset%2EuploadCustomIcon"
   or
   http.request.uri.query contains "task=asset%2euploadCustomIcon"
 ))

Acción:

Block

En Apache o LiteSpeed:

# CONTENCIÓN CVE-2026-48908
<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{QUERY_STRING} (^|&)option=com_sppagebuilder(&|$) [NC]
    RewriteCond %{QUERY_STRING} (^|&)task=asset(\.|%2[eE])uploadCustomIcon(&|$) [NC]
    RewriteRule ^ - [F,L]
</IfModule>

El problema es que esta regla protege esa operación.

No corrige una SQL injection en Dynamic Content. No corrige loadMoreArticles. No arregla Media Manager. No soluciona un formulario utilizado como relay de correo.

Así que mantener esta regla y pensar que SP Page Builder ya está protegido sería como cerrar con llave la puerta del garaje después de descubrir que también faltan dos ventanas.

Si no puedes instalar 6.7.1 inmediatamente

No hay una única regla universal que sustituya al parche, porque las nuevas vulnerabilidades afectan a funciones diferentes.

Como contención temporal:

• Despublica Contact Form y Form Builder cuando no sean imprescindibles.
• Retira temporalmente permisos de SP Page Builder y Media Manager a usuarios que no necesiten utilizarlos.
• Deshabilita Dynamic Content o las páginas que utilicen las funciones afectadas cuando sea posible.
• Si identificas loadMoreArticles en tu instalación, puede bloquearse temporalmente esa operación concreta mediante WAF o servidor después de comprobar que ninguna función legítima depende de ella.
• Activa reglas SQLi del WAF y revisa sus eventos, entendiendo que un WAF reduce exposición pero no sustituye la corrección.
• Si la web maneja información sensible y no existe una forma segura de aislar las funciones vulnerables, retirar temporalmente el componente o la web de exposición pública puede ser menos elegante y bastante más eficaz.

No bloquearía todo com_sppagebuilder a ciegas en una web de producción. Tampoco escribiría una regla de 400 caracteres encontrada en un foro y asumiría que cubre cinco vulnerabilidades distintas porque contiene muchas barras y paréntesis.

El problema del correo de SP Page Builder merece una revisión aparte

CVE-2026-65879 no necesita escribir archivos ni entrar en Joomla.

El problema estaba en el mecanismo utilizado por los formularios para validar el remitente. Un secreto compartido por las instalaciones podía permitir utilizar el sistema de formularios como relay de correo y falsificar el remitente.

Si una web utilizó una versión afectada con formularios publicados:

• Actualiza SP Page Builder.
• Revisa los registros SMTP y el correo saliente.
• Comprueba picos de mensajes, destinatarios desconocidos y rebotes.
• Revisa la reputación del dominio y de la IP de correo.
• Comprueba SPF, DKIM y DMARC, aunque ninguno de ellos sustituye la actualización.
• Si utilizas un proveedor SMTP externo, revisa estadísticas, credenciales, límites y actividad.
• Rota las credenciales SMTP si existen indicios de que pudieron quedar expuestas por otra vía.

Una web puede seguir funcionando perfectamente después de haber enviado veinte mil correos que tú no escribiste.

Normalmente la primera pista llega después, cuando Gmail decide que hasta la felicitación de cumpleaños de tu madre parece sospechosa.

PageBuilder CK: el primer parche no cerró completamente el problema

PageBuilder CK tuvo una vulnerabilidad crítica, CVE-2026-56290, que permitía subir archivos ejecutables sin autenticación y obtener ejecución remota de código.

Está en el catálogo KEV de CISA por explotación confirmada.

La versión 3.6.0 se publicó como corrección inicial.

Después se comprobó que la solución impedía el acceso anónimo, pero no eliminaba completamente la posibilidad de subir archivos ejecutables para determinadas cuentas autenticadas con permisos de edición.

Ese problema residual terminó registrado como CVE-2026-63048 y afecta hasta la 3.6.2.

La versión 3.6.3 refuerza la autorización del Media Manager y vuelve a aplicar las restricciones necesarias sobre los archivos subidos.

Es un buen ejemplo de por qué “ya actualicé cuando salió el aviso” no siempre cierra el expediente.

A veces aparece un parche. Luego aparece el parche del parche. Y entonces ya empiezas a sospechar que el fin de semana tenía otros planes para ti.

Helix3: el malware puede estar en la base de datos y no en los archivos

Helix3 merece una actualización importante respecto a la primera versión del artículo.

CVE-2026-49049 afecta al plugin AJAX de Helix3 y permite realizar operaciones no autorizadas sobre archivos y parámetros de la plantilla.

La corrección llegó con Helix3 3.1.1 y actualmente está disponible la 3.1.3.

Pero lo especialmente interesante es lo ocurrido después.

Se han documentado ataques automatizados contra instalaciones antiguas de Helix3 que introducen código directamente en los parámetros de estilo de la plantilla almacenados en la base de datos.

Eso permite desfigurar una web o insertar JavaScript sin necesidad de dejar un PHP sospechoso en /images/.

Por eso una búsqueda de malware sobre archivos puede devolver un resultado limpio mientras la web sigue comprometida.

Qué revisar en Helix3

• System – Helix3 Framework.
• Helix3 – Ajax.
• La plantilla construida sobre Helix3.
• La tabla #__template_styles.
• Los parámetros del estilo activo.
• Campos de Custom JavaScript.
• Custom CSS.
• Código insertado antes de </head> o en posiciones equivalentes.
• Dominios externos, scripts o valores que nadie reconozca.

Y hay que actualizar las piezas relacionadas, no una y dejar la otra esperando turno.

La combinación “framework nuevo + plugin AJAX antiguo” tiene la misma elegancia que cambiar la puerta blindada y conservar la llave debajo del felpudo.

Helix Ultimate: otro producto y otro conjunto de fallos

Helix Ultimate no es Helix3 con un nombre más optimista.

Son productos diferentes y sus actualizaciones deben tratarse por separado.

Helix Ultimate 2.2.7 corrigió problemas de autorización en acciones AJAX, rutas de archivos, eliminación de imágenes, exportación de configuración, validación de subidas, redirecciones y distintos vectores XSS.

Después se publicaron 2.2.8 y 2.2.9 para corregir regresiones y problemas funcionales posteriores.

La versión revisada a 28 de julio es 2.2.9.

Después de actualizar conviene comprobar:

• Mega Menu.
• Layouts.
• Imágenes del blog.
• Custom CSS y Custom JS.
• Código antes y después de <head> y <body>.
• Edición frontend.
• Medios.
• Configuración exportada o importada.

JoomShaper ha publicado también parches de seguridad para instalaciones Joomla 3 que siguen utilizando Helix3 y Helix Ultimate.

Sirven para reducir el riesgo mientras se mantiene una instalación heredada. No cambian el hecho de que la solución a medio plazo sigue siendo salir de una plataforma fuera de soporte.

iCagenda y Balbooa Forms: aquí sí sabemos que hubo explotación real

CVE-2026-48939 en iCagenda y CVE-2026-56291 en Balbooa Forms permiten subir archivos ejecutables sin autenticación.

Ambas vulnerabilidades están en KEV.

Las versiones corregidas son:

• iCagenda: 3.9.15 para la rama 3 y 4.0.8 para la rama 4.
• Balbooa Forms: 2.4.1 o posterior.

Si cualquiera de ellas estuvo publicada en una versión vulnerable, no limitaría la actuación a instalar el paquete nuevo.

Revisaría especialmente:

• Adjuntos enviados mediante formularios.
• Archivos asociados al alta de eventos.
• Carpetas de subida de cada componente.
• PHP, PHTML, PHAR y extensiones poco habituales.
• Archivos con doble extensión.
• Fechas de creación y modificación.
• Nuevos administradores.
• Tareas cron.
• Logs anteriores a la actualización.

Cuando una vulnerabilidad permite ejecución remota y sabemos que estaba siendo explotada, “pero no hemos visto nada raro” deja de ser una metodología de auditoría especialmente convincente.

EasyStore: aquí no solo hay que pensar en malware

El 23 de julio EasyStore 2.0.2 corrigió tres problemas de seguridad bastante serios.

• CVE-2026-65759: manipulación no autenticada de pedidos y estados de pago.
• CVE-2026-65760: acceso indebido a pedidos y facturas de otros clientes.
• CVE-2026-65761: SQL injection sin autenticación con acceso a información de la base de datos.

JoomShaper publicó después 2.0.3, que es la versión disponible al revisar esta guía.

Aquí el procedimiento posterior tiene que adaptarse al tipo de web.

Si es una tienda real:

1. Actualiza a 2.0.3 o posterior.
2. Compara los pedidos marcados como pagados con las operaciones reales del proveedor de pagos.
3. Comprueba importes, fechas, estados, identificadores de transacción y cambios manuales.
4. Revisa pedidos modificados, cancelados o completados en horarios extraños.
5. Revisa usuarios, sesiones y accesos a las vistas de pedidos y facturas.
6. Considera potencialmente expuesta la información contenida en la base de datos mientras estuvo activa la SQL injection.
7. Rota secretos, tokens y credenciales almacenados cuando puedan haberse visto afectados.
8. Valora el impacto sobre datos personales con el responsable correspondiente si existe indicio razonable de acceso no autorizado.

Un pedido que pone “Pagado” en Joomla no demuestra que alguien haya pagado.

Ese detalle normalmente resulta útil incluso cuando no hay una vulnerabilidad de seguridad de por medio.

Si no puedes actualizar EasyStore inmediatamente

Una tienda vulnerable a manipulación de pagos y lectura de datos no es un buen candidato para “le ponemos una regla y ya veremos”.

La solución temporal más segura puede ser desactivar checkout, acceso a pedidos o incluso poner la tienda en mantenimiento hasta completar la actualización.

Perder unas horas de pedidos es molesto.

Regalar productos mientras se filtran facturas tiene un departamento de marketing bastante peor.

Quix, EDocman, AcyMailing y DPCalendar: la SQL injection se está repitiendo demasiado

SP Page Builder y EasyStore no están solos.

Durante las últimas semanas se han publicado vulnerabilidades SQL sin autenticación en varias extensiones conocidas.

• Quix Page Builder: CVE-2026-58078. Corregida inicialmente en 6.2.1; la 6.2.2 cerró además otro problema detectado durante la misma auditoría.
• EDocman: CVE-2026-57832. Corregida en 3.9.0.
• AcyMailing: CVE-2026-56292. Corregida en 10.11.1.
• DPCalendar: CVE-2026-57831. Corregida en 10.11.2 y en 8.19.4 para la rama Joomla 3.

El patrón vuelve a ser parecido: una operación del frontend recibe un valor enviado por el visitante y ese valor acaba participando en una consulta a la base de datos sin una validación suficiente.

Por eso, en 2026, hacer una auditoría Joomla limitándose a buscar archivos modificados empieza a quedarse bastante corta.

Qué hacer después de una SQL injection pública

Si una versión vulnerable estuvo accesible desde Internet:

• Conserva los logs antes de que roten.
• Actualiza la extensión.
• Invalida sesiones administrativas.
• Revisa cuentas y permisos.
• Considera expuestos los hashes de contraseña y otros secretos almacenados en la base de datos.
• Rota claves API, tokens y secretos sensibles cuando proceda.
• Cambia las contraseñas privilegiadas y evita reutilizarlas.
• Comprueba si el usuario MySQL de Joomla tiene permisos sobre otras bases de datos.
• Evalúa qué información personal o comercial estaba almacenada.

Ese penúltimo punto merece atención.

En un hosting correctamente configurado, la cuenta MySQL de una web debería tener acceso únicamente a lo que necesita.

Si todas las instalaciones comparten un usuario de base de datos con permisos sobre media docena de bases, una SQL injection en una puede ampliar bastante el radio de la fiesta.

Regular Labs: no actualices solo Extension Manager

El 22 de julio Regular Labs publicó una revisión coordinada de seguridad en gran parte de su catálogo.

Dos de las correcciones afectan a la librería compartida utilizada por sus extensiones: controles más estrictos en endpoints AJAX privilegiados y una actualización de una dependencia relacionada con peticiones HTTP.

Además, varias extensiones recibieron correcciones específicas.

Entre las más relevantes aparecen:

• Cache Cleaner.
• GeoIP.
• Articles Anywhere.
• Modules Anywhere.
• Users Anywhere.
• Modals.
• Tooltips.
• Keyboard Shortcuts.
• Sourcerer.

Los problemas corregidos incluyen, según la extensión, SSRF, inyección de comandos, path traversal, XSS almacenado, exposición de contenido restringido, confianza en cabeceras de IP manipulables y controles insuficientes de permisos.

Regular Labs Extension Manager también recibió su propia corrección de permisos y protección CSRF. La rama 9.3.x incorpora esos cambios y la versión disponible al revisar esta guía es 9.3.2.

Qué hacer

No abras Joomla, actualices Extension Manager y cierres satisfecho.

Revisa la lista completa de productos Regular Labs instalados y actualiza cada uno a su rama corregida.

Hay además un problema añadido para instalaciones antiguas: las nuevas versiones han elevado requisitos y varias necesitan PHP 8.2 o posterior.

Si la web permanece en una versión antigua de PHP y no ofrece las actualizaciones, eso no significa que no las necesite.

Significa que ahora tienes dos problemas.

El inventario se ha convertido en una medida de seguridad

Durante años hemos tratado el listado de extensiones como una tarea administrativa bastante aburrida.

Después de este mes empieza a parecer una idea bastante mejor.

Entre las extensiones que han recibido correcciones recientes aparecen también RSFiles!, Gridbox, Events Booking, DJ-Classifieds y jDownloads.

No tiene mucho sentido que esta guía se convierta en una enciclopedia de CVE que caduca cada cuatro días.

La solución más útil es otra:

1. Saber exactamente qué tienes instalado.
2. Saber qué versión utiliza cada web.
3. Saber qué extensiones están desactivadas pero siguen presentes.
4. Saber cuáles han dejado de recibir soporte.
5. Consultar periódicamente las actualizaciones y avisos de cada proveedor.
6. Eliminar lo que no sea necesario.

La extensión que no recuerdas que existe es precisamente la que menos posibilidades tiene de recibir una actualización puntual.

El núcleo de Joomla también ha recibido correcciones

Joomla publicó el 7 de julio las versiones 5.4.7 y 6.1.2 con correcciones de seguridad en Media, Contactos, MFA, Plantillas, Instalador, Flujos de trabajo, Módulos, Privacidad, Campos y otros puntos del núcleo.

Estas versiones continúan siendo las últimas publicaciones de seguridad que figuran en el canal oficial al revisar esta guía el 28 de julio.

Eso tampoco convierte las vulnerabilidades de las extensiones en vulnerabilidades del propio Joomla.

Conviene distinguirlo.

Una instalación limpia de Joomla y una instalación de Joomla con quince extensiones son dos superficies de ataque muy diferentes.

El núcleo puede estar perfectamente actualizado mientras un componente instalado hace cinco años deja una puerta abierta desde el frontend.

¿Está siendo atacada mi web de forma personal?

Probablemente no.

La mayoría de estos ataques se automatiza.

Un bot recorre dominios, identifica tecnologías, prueba operaciones conocidas y continúa con la siguiente dirección.

Puede atacar una tienda con miles de pedidos, una web municipal, una clínica o la página de una asociación de siete personas que lleva tres meses sin recibir una visita.

No necesita conocer el negocio.

Necesita una respuesta vulnerable.

También explica por qué después de actualizar puedes seguir viendo intentos durante semanas o meses.

La petición seguirá llegando.

La diferencia es que ahora debería encontrarse una puerta cerrada en vez de un formulario de inscripción.

Ahora hay tres escenarios, no dos

Escenario A: no has detectado indicios y la vulnerabilidad era de ejecución o escritura

Hay que actualizar, buscar modificaciones, revisar usuarios, archivos, base de datos, tareas cron y registros.

Escenario B: existen señales de compromiso

Hay que aislar, conservar pruebas, localizar una copia limpia, cerrar la entrada y reconstruir sin conservar artefactos del atacante.

Escenario C: no hay malware, pero pudo existir acceso a datos

Este escenario cobra importancia con las nuevas SQL injection, los IDOR, los fallos de sesiones y los problemas de EasyStore.

La web puede no haber sido modificada.

El objetivo pasa a ser determinar qué información estaba disponible, invalidar credenciales y sesiones, rotar secretos y valorar si existe una posible brecha de datos.

No existe un grep capaz de demostrar que nadie leyó una base de datos.

Parte I: qué hacer si todavía no has detectado una intrusión

1. Haz una copia completa y sácala del servidor

Incluye:

• Todos los archivos.
• Base de datos.
• .htaccess.
• configuration.php.
• Configuración de tareas cron.
• Logs disponibles.
• Configuración de correo cuando sea posible.

Descarga la copia fuera de la cuenta.

Un backup dentro de la misma cuenta es mucho mejor que ninguno hasta que el problema afecta precisamente a la cuenta entera.

2. Haz un inventario real

No anotes únicamente Joomla, JCE y la plantilla.

Anota componentes, plugins, módulos, librerías, frameworks, extensiones del editor, constructores, sistemas de formularios, descargas, calendarios, newsletter, ecommerce y cualquier cosa que tenga la mala costumbre de ejecutar PHP.

Incluye las extensiones desactivadas.

Desactivado no significa borrado.

3. Crea una copia de pruebas

En una web antigua no probaría una actualización compleja directamente en producción.

El entorno de pruebas debería utilizar:

• Carpeta y base de datos independientes.
• Protección por contraseña o IP.
• Indexación bloqueada.
• Correo real desactivado.
• Pasarelas de pago desconectadas.
• Webhooks deshabilitados.
• Credenciales distintas.

4. Actualiza primero lo que puede comprometer el sistema

No todas las actualizaciones tienen la misma urgencia.

Priorizaría:

1. Vulnerabilidades con explotación confirmada.
2. RCE y subidas de archivos sin autenticación.
3. SQL injection sin autenticación.
4. Bypass de autenticación o permisos.
5. Exposición o manipulación de datos.
6. Problemas que requieren una cuenta autenticada.
7. Correcciones de menor impacto.

La versión nueva de un carrusel puede esperar un poco más que la extensión que permite a cualquiera subir PHP.

5. Si la actualización no es posible, identifica la causa

Puede ser:

• PHP antiguo.
• Joomla fuera de soporte.
• Una plantilla incompatible.
• Una extensión abandonada.
• Overrides heredados.
• Código personalizado.
• Dependencias entre framework y constructor.
• Una base de datos antigua.
• Limitaciones del hosting.

Después decide si existe un parche del proveedor, si la función vulnerable puede desactivarse o si la instalación debe migrarse.

“No puedo actualizar” es un diagnóstico a medias.

Hay que saber qué pieza está sujetando la puerta.

Bloqueo temporal de JCE desde la parte pública

Cuando nadie utiliza edición frontend ni funciones públicas de JCE, puede bloquearse temporalmente el componente fuera del administrador:

<IfModule mod_rewrite.c>
    RewriteEngine On

    RewriteCond %{REQUEST_URI} !^/administrator/ [NC]
    RewriteCond %{QUERY_STRING} (^|&)option=com_jce(&|$) [NC]
    RewriteRule ^ - [F,L]
</IfModule>

Puede romper edición frontend, cargas de medios e integraciones que necesiten JCE públicamente.

El parche o actualización oficial siguen siendo la solución.

Impide ejecutar PHP en carpetas que solo deberían guardar archivos

Esta medida gana todavía más interés después de la sucesión de vulnerabilidades de subida de archivos.

Una carpeta que contiene imágenes, documentos o adjuntos no debería ejecutar PHP salvo que exista una razón técnica concreta.

En una subcarpeta adecuada de Apache o LiteSpeed:

<FilesMatch "\.(php|php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>

En servidores antiguos:

<FilesMatch "\.(php|php[0-9]?|phtml|phar)$">
    Order Allow,Deny
    Deny from all
</FilesMatch>

Las ubicaciones candidatas pueden incluir directorios concretos dentro de:

• /images/.
• /media/.
• Carpetas de adjuntos.
• Directorios de iconos.
• Descargas públicas.
• Subidas de usuarios.

No la pegues en todas partes.

Hay extensiones que guardan PHP legítimo dentro de directorios propios y una regla aplicada sin pensar puede transformar una mejora de seguridad en una colección de errores 403.

Protege el administrador, pero recuerda que muchas de estas vulnerabilidades no pasan por él

Proteger /administrator sigue siendo recomendable para reducir fuerza bruta, contraseñas filtradas y ataques contra cuentas legítimas.

Pero JCE, SP Page Builder, PageBuilder CK, iCagenda, Balbooa Forms y varias SQL injection recientes demuestran que un atacante no siempre necesita visitar el login.

Activa MFA

Todos los Super Users deberían utilizar autenticación multifactor.

Reduce privilegios

Después de PageBuilder CK y los fallos autenticados de SP Page Builder hay otro punto que merece atención: una cuenta de Editor ya no es simplemente “una cuenta que escribe artículos”.

Revisa quién puede:

• Editar páginas.
• Gestionar medios.
• Subir archivos.
• Editar plantillas.
• Utilizar constructores visuales.
• Modificar módulos.
• Publicar contenido.

La mínima cantidad de privilegios necesaria sigue teniendo una ventaja curiosa: limita lo que puede hacer una cuenta cuando deja de estar en manos de la persona a la que se la diste.

Cloudflare solo protege lo que pasa por Cloudflare

Tener Cloudflare no significa que el servidor sea inaccesible directamente.

Comprueba:

• Que los registros web tienen proxy activado.
• Que no existen subdominios que revelen la IP de origen.
• Que el servidor no acepta conexiones HTTP y HTTPS directas desde cualquier dirección cuando no las necesita.
• Que los servicios legítimos que requieren conexión directa estén identificados.

Cuando sea viable, el servidor web puede aceptar tráfico únicamente desde los rangos de Cloudflare y servicios autorizados.

Eso debe configurarlo quien controle realmente el firewall.

Experimentar con puertos desde un panel que no conoces es una forma magnífica de proteger la web incluso de sus propietarios.

El WAF ayuda, pero ya sabemos dónde termina su trabajo

Cloudflare, ModSecurity, Imunify360 y otros WAF pueden bloquear SQL injection, peticiones anómalas, rutas conocidas y algunos intentos de explotación.

Son una capa muy útil.

No son un parche.

Una regla WAF puede:

• Reducir ataques contra un endpoint.
• Bloquear patrones SQL conocidos.
• Limitar peticiones repetidas.
• Impedir parte de las cargas maliciosas.
• Generar registros útiles para investigar.

Pero una excepción demasiado amplia puede neutralizarla y una técnica distinta puede evitar la regla.

Por eso una excepción debe limitarse siempre que sea posible a una ruta, operación, parámetro, método, IP o usuario concreto.

Desactivar todo OWASP para que un constructor visual guarde una página es una solución excelente siempre que el objetivo sea que deje de molestar el sistema que estaba intentando protegerte.

Qué buscar ahora en los registros

La lista original incluía:

com_sppagebuilder
asset.uploadCustomIcon
com_jce
com_ajax
helix3
helixultimate

Ahora ampliaría la búsqueda con los componentes instalados en cada web y con términos relacionados con las nuevas funciones afectadas:

com_sppagebuilder
uploadCustomIcon
loadMoreArticles
com_jce
com_ajax
helix3
helixultimate
pagebuilderck
icagenda
baforms
phocadownload
easystore
quix
edocman

Con SSH, una búsqueda orientativa puede ser:

grep -Ei 'com_jce|com_sppagebuilder|uploadCustomIcon|loadMoreArticles|helix3|helixultimate|pagebuilderck|icagenda|baforms|phocadownload|easystore|quix|edocman' access.log

No conviertas la ausencia de coincidencias en un certificado de limpieza.

Los nombres pueden variar, el cuerpo POST puede no aparecer en el access log y algunos ataques dejan mucha menos información de la que nos gustaría.

Para problemas de subida

Busca:

• POST poco habituales.
• Respuestas 200 en operaciones que deberían estar restringidas.
• PHP dentro de medios y subidas.
• Archivos creados inmediatamente después de una petición sospechosa.
• Acceso posterior a esos archivos.

Para SQL injection

Busca:

• Peticiones repetidas contra el mismo endpoint con parámetros cambiantes.
• Valores anormalmente largos.
• Errores SQL próximos en el tiempo.
• Picos de peticiones sobre Dynamic Content, listados, feeds o consultas públicas.
• Patrones detectados por ModSecurity o Cloudflare.

Para abuso de correo

Busca:

• Picos repentinos de mensajes enviados.
• Destinatarios desconocidos.
• Rebotes.
• Bloqueos del proveedor SMTP.
• Cambios de reputación.

Para Helix3

No te limites a los logs y archivos.

Revisa también #__template_styles y la configuración del estilo utilizado.

Pregunta al hosting algo más que “¿veis virus?”

La respuesta “el escáner está limpio” ya era insuficiente antes.

Ahora lo es todavía más.

Pide que revisen:

• Archivos.
• Base de datos cuando dispongan de herramientas para ello.
• Tareas cron.
• Procesos.
• Correo saliente.
• Usuarios del panel.
• Historial de accesos.
• Logs de Apache, LiteSpeed o Nginx.
• Logs PHP.
• Eventos de ModSecurity o Imunify.
• Otras webs alojadas bajo el mismo usuario.
• La posibilidad de conexiones directas que eviten Cloudflare.

Y pregunta qué herramientas están activas realmente:

• Imunify360.
• ImunifyAV.
• ModSecurity.
• Patchman.
• ClamAV.
• Linux Malware Detect.
• Protección propia del proveedor.

Un producto instalado en el servidor no implica necesariamente que tu cuenta tenga todas sus funciones activadas.

Parte II: qué hacer si la web ya ha sido comprometida

Señales evidentes

• Archivos PHP desconocidos.
• Super Users nuevos.
• Perfiles de JCE extraños.
• Redirecciones.
• Defacements.
• Scripts externos.
• Páginas de spam.
• Correo enviado sin explicación.
• Archivos que reaparecen.
• Crons desconocidos.
• Cambios en configuraciones de plantilla.
• Pedidos o pagos incoherentes.

Y ahora añadimos una señal especialmente poco espectacular:

ninguna.

Una SQL injection utilizada únicamente para leer datos puede no cambiar absolutamente nada.

1. Aísla sin destruir pruebas

Puedes:

• Poner la web en mantenimiento.
• Restringirla por IP.
• Protegerla mediante autenticación HTTP.
• Pedir al hosting que aísle la cuenta.
• Publicar temporalmente una página estática.

Antes guarda archivos, base de datos, logs, usuarios, cron, configuraciones y alertas.

2. Busca una copia anterior a la entrada

No anterior al día que descubriste el problema.

Anterior al día en el que pudo empezar.

La diferencia puede ser de semanas.

3. No restaures encima de la web infectada

Akeeba y otros sistemas restauran los archivos incluidos en el backup, pero un archivo malicioso añadido después puede permanecer en el servidor si no se limpia primero el destino.

La restauración más segura utiliza una carpeta y base de datos nuevas o completamente vacías.

4. Actualiza antes de devolverla a Internet

No restaures una copia vulnerable, la publiques y después empieces a actualizar.

Internet no concede cinco minutos de cortesía mientras localizas el botón.

5. Recupera los datos recientes de forma selectiva

Pedidos, formularios, usuarios o artículos creados después del backup pueden recuperarse por separado después de comprobarlos.

No importes automáticamente toda la base comprometida sobre la limpia.

6. Revisa usuarios, sesiones y métodos de autenticación

Busca:

• Administradores nuevos.
• Cuentas antiguas que siguen activas.
• Cambios de grupos.
• Métodos MFA desconocidos.
• Plugins de autenticación inesperados.
• Tokens y claves API.
• Sesiones activas.

7. Revisa los archivos

/images/
/media/
/tmp/
/cache/
/logs/
/administrator/cache/
/templates/
/plugins/
/components/
/modules/

Busca PHP, PHTML, PHAR, dobles extensiones, ficheros ocultos, código ofuscado, scripts externos y archivos con nombres parecidos a los originales.

8. Revisa la base de datos

Ahora esta fase es obligatoria, no opcional.

Comprueba:

• #__users y grupos de usuarios.
• #__extensions.
• #__template_styles.
• Módulos personalizados.
• Artículos.
• Menús.
• Redirecciones.
• Configuración de JCE.
• Datos de SP Page Builder.
• Configuración de Helix.
• Sesiones.
• Parámetros que almacenen tokens o credenciales.

Busca JavaScript, iframes, dominios externos, código codificado y valores que no reconozcas.

9. Revisa cron, .htaccess y configuration.php

Una tarea cron puede reconstruir una puerta trasera que acabas de borrar.

Una regla de .htaccess puede redirigir solamente a visitantes procedentes de Google.

Una configuración modificada puede mantener acceso sin necesidad de un archivo llamado malware.php, que además sería un nombre bastante considerado por parte del atacante.

10. Cambia las credenciales desde un equipo limpio

Según el alcance:

• Joomla.
• Hosting.
• Panel.
• FTP, SFTP y SSH.
• Base de datos.
• Cloudflare.
• Correo.
• SMTP.
• APIs.
• Pagos.
• Backups.
• Registrador del dominio.
• Repositorios.

Invalida sesiones y revisa también el equipo desde el que administras la web.

11. Revisa todas las webs de la cuenta

Una instalación vulnerable puede comprometer otras si comparten usuario, permisos, base de datos o directorios accesibles.

Incluye:

• Dominios secundarios.
• Subdominios.
• Staging.
• Copias antiguas.
• Joomlas abandonados.
• WordPress olvidados.
• ZIP.
• SQL.
• Repositorios .git.

Parte III: qué hacer cuando pudo haber fuga de datos pero no hay malware

Este procedimiento es nuevo respecto a la primera versión de la guía y resulta necesario por las SQL injection y vulnerabilidades de acceso a datos publicadas después.

1. Determina el periodo de exposición

Necesitas saber desde qué fecha estaba instalada la versión vulnerable y cuándo se aplicó la corrección.

2. Conserva los registros

No esperes demasiado.

Muchos hostings conservan logs durante periodos limitados y lo que hoy existe puede haber desaparecido cuando decidas investigar dentro de tres semanas.

3. Identifica qué datos podía leer la aplicación

No preguntes únicamente qué contiene Joomla.

Pregunta qué podía ver el usuario MySQL utilizado por Joomla.

4. Rota secretos y sesiones

Cuando exista riesgo razonable de lectura de la base de datos, revisa:

• Sesiones activas.
• Credenciales de administradores.
• Tokens.
• API keys.
• Secretos almacenados por extensiones.
• Integraciones.

Al cambiar secretos globales hay que comprobar las integraciones que dependan de ellos. Haz backup y documenta los cambios.

5. Identifica datos personales afectados

Usuarios, emails, direcciones, teléfonos, facturas, pedidos, formularios, reservas o cualquier otro dato almacenado pueden cambiar la naturaleza del incidente.

Cuando exista una posibilidad razonable de acceso no autorizado a datos personales, debe valorarse el incidente desde el punto de vista de protección de datos con quien corresponda.

Un escáner limpio no resuelve esa parte porque el problema no era escribir un archivo.

Después de limpiar, revisa también el daño SEO

Un compromiso puede dejar:

• Páginas de spam.
• Redirecciones.
• JavaScript inyectado.
• Sitemaps desconocidos.
• Métodos de verificación nuevos.
• Problemas de seguridad en Search Console.
• URLs en otros idiomas.
• Caídas de clics e impresiones.

Revisa Search Console y busca también:

site:tudominio.com

junto con términos que no tengan ninguna relación con el negocio.

Comprueba igualmente Analytics, logs, correo saliente, reputación del dominio y de la IP.

Eliminar el malware no obliga a Google a olvidar inmediatamente las páginas de casino que encontró mientras tú estabas convencido de que la portada seguía cargando estupendamente.

Qué pedir ahora al hosting

Mi web utiliza Joomla y puede haber estado expuesta a vulnerabilidades recientes en extensiones o frameworks instalados.

Necesito que reviséis:

1. Qué sistemas de seguridad están activos en la cuenta: Imunify360, ImunifyAV, ModSecurity, Patchman u otros.
2. Si se han detectado, puesto en cuarentena o eliminado archivos maliciosos.
3. Si podéis ejecutar un análisis completo de archivos.
4. Si disponéis de análisis de la base de datos o detección de contenido malicioso almacenado en ella.
5. Los logs de acceso, error, PHP y correo correspondientes al periodo afectado.
6. Peticiones relacionadas con los componentes que os indicaré y cualquier operación anómala contra index.php o com_ajax.
7. Creación o modificación de archivos en carpetas de medios, imágenes, temporales, plantillas y componentes.
8. Existencia de tareas cron desconocidas.
9. Actividad anormal de correo saliente.
10. Picos de recursos coincidentes con las fechas investigadas.
11. Si otras webs de la misma cuenta presentan cambios o malware similares.
12. Si disponéis de copias anteriores a la primera actividad sospechosa.
13. Si el servidor acepta conexiones HTTP o HTTPS directas a la IP de origen evitando Cloudflare.
14. Si podéis aislar temporalmente la cuenta o aplicar reglas WAF sobre operaciones concretas mientras se completa la actualización.

Añade dominio, extensión, versión, fecha, zona horaria, rutas sospechosas y cualquier evento concreto que tengas.

“Creemos que pasó algo” da bastante menos margen que “la web ejecutó esta versión entre el 3 de junio y el 27 de julio y necesitamos conservar los logs de ese periodo”.

Medidas que reducen la exposición aunque mañana aparezca otro CVE

Elimina extensiones que no utilices

No acumules componentes por si dentro de ocho años vuelve a hacer falta aquel formulario que utilizaste para un sorteo.

Separa permisos

No todas las personas que publican un artículo necesitan administrar medios, plantillas, constructores y extensiones.

Bloquea la ejecución de PHP donde no sea necesaria

Especialmente en carpetas destinadas exclusivamente a archivos subidos.

No compartas innecesariamente usuarios de base de datos

Cada aplicación debería acceder únicamente a sus propios datos.

Separa webs críticas

Cuando sea posible, evita que quince proyectos compartan usuario, permisos y destino con una copia de pruebas de 2018.

Utiliza MFA

Especialmente en administradores, correo, hosting, Cloudflare y registrador.

Conserva backups externos

Y prueba alguna restauración antes de descubrir durante una emergencia que llevabas once meses guardando copias inservibles con mucha disciplina.

Monitoriza cambios

Resulta útil recibir alertas por:

• Nuevos administradores.
• Cambios de archivos críticos.
• PHP en carpetas de subida.
• Modificación de configuraciones sensibles.
• Picos de correo.
• Caídas.
• Problemas de Search Console.
• Cambios de reputación.

Mantén un inventario

Si gestionas muchas webs, saber qué extensión y versión ejecuta cada una empieza a ser más importante que recordar de memoria dónde colocaste el logo en 2021.

Errores que ahora evitaría todavía más

Actualizar y considerar terminada la incidencia

La actualización cierra la vulnerabilidad. No elimina lo que haya ocurrido antes.

Confiar únicamente en un escáner de archivos

No ve una base de datos que alguien haya leído, un pedido manipulado ni necesariamente un payload almacenado dentro de una configuración.

Restaurar encima de una instalación comprometida

Puede conservar archivos añadidos después del backup.

Bloquear todo com_ajax

Puede romper funciones legítimas de media web.

Pensar que un WAF sustituye al parche

Reduce exposición. No corrige el código vulnerable.

Quedarse en la primera versión que decía “security fix”

PageBuilder CK ya nos ha dejado una demostración bastante práctica de por qué hay que seguir el historial posterior.

No conservar logs

Después resulta muy difícil responder a la única pregunta realmente interesante: qué ocurrió mientras la web estuvo expuesta.

Considerar segura una extensión porque está desactivada

Sus archivos pueden seguir presentes.

Olvidar la base de datos

Helix3 ha demostrado que el visitante indeseado también sabe guardar cosas allí.

Olvidar el correo

SP Page Builder ha añadido esa casilla a la lista.

Olvidar los pagos

EasyStore ha añadido esa otra.

Orden de actuación resumido

Si no hay señales de intrusión

1. Backup externo.
2. Inventario completo.
3. Comprobar versiones y vulnerabilidades conocidas.
4. Crear staging cuando la actualización pueda romper dependencias.
5. Actualizar las extensiones críticas.
6. Actualizar Joomla y PHP cuando corresponda.
7. Aplicar parches oficiales a ramas heredadas cuando existan.
8. Revisar usuarios y permisos.
9. Revisar archivos y base de datos.
10. Revisar correo y sesiones.
11. Conservar y examinar logs.
12. Pedir análisis al hosting.
13. Crear un nuevo backup una vez confirmado el estado.

Si existen señales de compromiso

1. Aislar.
2. Guardar pruebas.
3. Determinar el periodo probable de intrusión.
4. Buscar una copia anterior.
5. Restaurar sobre archivos y base de datos limpios.
6. Actualizar antes de publicar.
7. Revisar archivos, base de datos, usuarios, cron y configuración.
8. Recuperar datos recientes de forma selectiva.
9. Rotar credenciales, claves y sesiones.
10. Revisar otras webs de la cuenta.
11. Comprobar correo, pagos y SEO según el caso.
12. Monitorizar después de publicar.

Si el riesgo es una posible fuga de datos

1. Parchear inmediatamente.
2. Conservar logs.
3. Determinar el periodo de exposición.
4. Identificar qué información podía consultar la aplicación.
5. Revisar usuarios y sesiones.
6. Rotar secretos y credenciales sensibles.
7. Comprobar si el usuario de base de datos accedía a otros esquemas.
8. Evaluar los datos personales o comerciales potencialmente expuestos.
9. Documentar la investigación y las medidas adoptadas.

¿Y si no puedes hacerlo?

Puede que tengas una web antigua, una versión de Joomla que no admite las extensiones actuales, una plantilla que lleva años sin recibir atención o una combinación de componentes que amenaza con descomponerse en cuanto alguien pulsa “Actualizar”.

También puede que acabes de descubrir que en el servidor hay tres constructores visuales, dos frameworks de plantilla, un editor que nadie recuerda haber instalado y un plugin llamado system-old-backup-final que lleva publicado desde 2018.

No sería una novedad.

Las medidas de esta guía permiten reducir la exposición, conservar información útil y evitar algunos de los errores que más complican una recuperación.

Pero una instalación antigua no se vuelve mantenible acumulando parches temporales durante otros cinco años.

Hay webs que necesitan una actualización.

Otras necesitan una migración.

Y algunas necesitan que alguien abra primero el listado de extensiones y explique por qué existen cuatro maneras diferentes de mostrar un mapa de Google, tres editores desactivados y una plantilla llamada shaper_empresa_old_2020_definitiva.

Si tienes una web Joomla afectada o no sabes si ha quedado expuesta, puedes contactar conmigo y contarme qué versión, hosting y extensiones utiliza.

Aviso final

Esta guía ofrece medidas generales de prevención, contención y recuperación. Cada instalación tiene una combinación diferente de Joomla, extensiones, permisos, hosting y servicios externos.

Las reglas WAF, los bloqueos mediante .htaccess y otras medidas temporales pueden reducir el riesgo, peeeeeeeeero...

No sustituyen:

• La actualización.
• La revisión técnica.
• Las copias externas.
• La revisión de la base de datos.
• El análisis posterior a una intrusión.
• La evaluación de una posible fuga de datos.
• La migración de una instalación que ya no dispone de una ruta segura de mantenimiento.

Y probablemente esta lista vuelva a cambiar. La diferencia es que después de junio y julio de 2026 ya tenemos una pista bastante clara sobre dónde mirar.

Ojo, no solo en Joomla, sino en todo lo que hemos instalado encima.