Ataques a Joomla: JCE, SP Page Builder y Helix

Versiones que deben revisarse

Estas fichas reflejan el estado publicado por los desarrolladores y los registros de vulnerabilidades a fecha de 18 de julio de 2026. Las versiones pueden cambiar después de la publicación de esta guía, así que comprueba siempre el registro oficial antes de instalar un paquete. Internet tiene la mala costumbre de seguir avanzando después de que uno publique.

Qué vulnerabilidades están implicadas

Los nombres se han mezclado bastante en avisos, foros, mensajes de hosting y conversaciones entre administradores. Al final parece que JCE, Helix y SP Page Builder fueran tres primos que han robado juntos una furgoneta. Es importante separarlos porque el riesgo, las versiones afectadas y las soluciones no son iguales.

JCE: creación de perfiles y ejecución de código sin autenticación

El 3 de junio de 2026 se publicó JCE Pro 2.9.99.5 para corregir CVE-2026-48907, una vulnerabilidad crítica presente en todas las versiones anteriores hasta la 2.9.99.4.

El fallo permitía que una persona no autenticada crease perfiles del editor y aprovechase esa capacidad para subir y ejecutar código PHP. No hacía falta conocer una contraseña de Joomla, entrar en el administrador ni enviar una carta certificada. Bastaba con encontrar la instalación vulnerable.

Después llegaron las versiones 2.9.99.6, 2.9.99.7 y 2.9.99.8 con más medidas de endurecimiento y correcciones. JCE 2.9.99.9, publicada el 8 de julio, solucionó además falsos positivos provocados por reglas OWASP de Cloudflare y por el WAF de Imunify.

JCE recomienda la versión 2.9.99.9 para todos los sitios. La rama 2.9.99.x es compatible con Joomla 3, 4, 5 y 6, lo que facilita la corrección en muchas instalaciones antiguas.

Para webs que sigan atrapadas en ramas anteriores, el desarrollador ha publicado un parche gratuito destinado a versiones 2.7.x a 2.9.x. Ese parche debe descargarse únicamente desde la web oficial de JCE, no desde un ZIP llamado jce-parche-definitivo-bueno-ahora-si.zip que alguien ha dejado en un foro.

La corrección del componente cierra la vulnerabilidad conocida, pero no elimina perfiles maliciosos, archivos subidos o puertas traseras creadas antes de la actualización. Una instalación que estuvo expuesta necesita revisión.

SP Page Builder: subida arbitraria de archivos

SP Page Builder 6.6.2 se publicó el 15 de junio con una descripción sorprendentemente escueta en el registro de cambios: “Fixed security for upload endpoints”. Detrás de esa frase había una vulnerabilidad bastante más seria de lo que sugiere una línea perdida entre mejoras de iconos y ajustes de animaciones.

CVE-2026-48908 permite a usuarios no autenticados subir archivos arbitrarios y, en determinadas condiciones, ejecutar código PHP. El registro de vulnerabilidades considera afectadas las versiones comprendidas entre la 1.0.0 y la 6.6.1.

Los intentos observados utilizan especialmente esta tarea:

asset.uploadCustomIcon

y peticiones como:

/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

Hay dos problemas adicionales.

El primero es que las ramas modernas de SP Page Builder no son compatibles con cualquier versión antigua de Joomla. Una instalación con Joomla 3 puede no tener una ruta directa hacia la versión 6.6.2.

El segundo es que la información pública sobre las ramas heredadas ha sido poco clara. El CVE incluye un intervalo muy amplio, mientras distintas respuestas de soporte han ofrecido matices sobre determinadas versiones. Si tu web utiliza SP Page Builder 3, 4 o 5, no asumiría que está protegida por antigüedad, por oscuridad ni por el poder ancestral de llevar siete años sin actualizarse.

Cuando no existe una actualización compatible inmediata, el bloqueo temporal del endpoint y la revisión del servidor son medidas de contención, no una solución definitiva.

Helix3: actualización del framework

Helix3 3.1.1, publicada el 29 de junio, corrigió una vulnerabilidad de seguridad en el framework. La versión 3.1.2 llegó el 1 de julio con una corrección funcional y la 3.1.3 se publicó el 15 de julio para reparar otro problema del Mega Menu.

Las instalaciones basadas en Helix3 deben comprobar especialmente estos elementos:

• System – Helix3 Framework.
• Helix3 – Ajax.
• La plantilla construida sobre Helix3.
• Overrides y personalizaciones que dependan de versiones antiguas del framework.

Helix3 y Helix Ultimate son productos distintos. Instalar un paquete de Helix Ultimate sobre una plantilla construida con Helix3 no es una actualización. Es una forma bastante rápida de descubrir qué planes tenías realmente para el fin de semana.

Helix Ultimate: permisos, rutas, subidas y XSS

Helix Ultimate 2.2.7 se publicó el 7 de julio con un conjunto amplio de correcciones de seguridad. Entre ellas aparecen:

• Redirecciones abiertas.
• Falta de comprobaciones CSRF y permisos en acciones AJAX.
• Validación incorrecta de rutas en operaciones de medios, layouts y blog.
• Controles insuficientes al eliminar imágenes o exportar ajustes.
• Validación deficiente de archivos subidos.
• Vulnerabilidades XSS en galerías, medios, Mega Menu, Layout Builder y tipografías.
• Validación insuficiente en la edición de artículos desde el frontend.

La 2.2.8 corrigió un problema que podía eliminar campos de código personalizado al guardar la configuración. La 2.2.9 reparó otros fallos relacionados con imágenes del blog, Mega Menu y copyright.

Por eso no instalaría únicamente la 2.2.7 si ya está disponible una versión posterior. Cerrar un agujero de seguridad para descubrir después que ha desaparecido el código insertado antes de </head> es una victoria bastante discutible.

La rama actual de Helix Ultimate requiere Joomla 4.4, 5.4 o 6.0. Las webs de Joomla 3 que utilizan versiones antiguas de Helix Ultimate necesitan un parche específico, una versión heredada corregida por el proveedor o una migración. Forzar el paquete moderno y confiar en que Joomla “se adapte” pertenece al ámbito de la fe, no de la administración de sistemas.

El propio núcleo de Joomla también ha recibido una actualización de seguridad

Joomla publicó el 7 de julio las versiones 5.4.7 y 6.1.2. Incluyen correcciones de control de acceso y XSS en componentes como Media, Contactos, Plantillas, Instalador, Flujos de trabajo, Módulos, Privacidad y Campos.

La actualización introdujo una regresión que puede provocar que Joomla ignore los parámetros específicos de un artículo y utilice en su lugar los ajustes globales o los del elemento de menú. El proyecto ha publicado un hotfix oficial mientras prepara la corrección definitiva para Joomla 5.4.8 y 6.1.3.

Esto no es una razón para quedarse en una versión vulnerable. Es una razón para actualizar primero en una copia de pruebas y no utilizar la web de producción como si fuera una pista de ensayo.

¿Está siendo atacada mi web de forma personal?

Probablemente no.

La mayoría de estos ataques se automatiza. Un bot recorre dominios, busca señales de Joomla, prueba endpoints conocidos y continúa con la siguiente dirección.

Puede atacar una tienda con miles de pedidos, una web municipal, la página de una clínica o el sitio de una peña dedicada a criar canarios con una audiencia mensual de siete personas. Para el bot son direcciones dentro de una lista.

Eso explica por qué una web sin tráfico, sin una gran marca y sin enemigos declarados puede acabar comprometida. El atacante no necesita conocer el negocio. No le importa quién eres, qué vendes ni que tu cuñado asegure que nadie va a querer hackear “una web tan pequeña”. Solo necesita que responda una extensión vulnerable.

También explica por qué seguir viendo intentos después de actualizar no demuestra que la corrección haya fallado. Los bots continuarán probando el endpoint durante meses. La diferencia está en si la petición termina con un bloqueo o con un archivo PHP nuevo instalado en la cocina.

Antes de cambiar nada: ¿quieres prevenir o ya estás recuperando?

Hay dos escenarios que exigen procedimientos diferentes.

Escenario A: no has visto señales de intrusión

El objetivo es cerrar los puntos conocidos, comprobar que el sitio no haya sido alterado y reducir la exposición mientras se prepara una actualización completa.

Escenario B: existen indicios de compromiso

El objetivo es impedir nuevas modificaciones, conservar pruebas, localizar una copia limpia, cerrar la vulnerabilidad y restaurar la web sin reintroducir los archivos del atacante.

Actualizar una extensión en una web comprometida no elimina lo que se haya subido previamente. Es como cambiar la cerradura después de que alguien haya instalado una cama, una nevera y fibra óptica en el trastero. La puerta nueva ayuda, pero el inquilino sigue dentro y probablemente ya ha cambiado la contraseña del wifi.

Qué puede hacer cada persona según su nivel de acceso

Si solo tienes acceso a Joomla

Puedes comprobar versiones, actualizar extensiones compatibles, revisar usuarios, activar MFA, deshabilitar componentes, examinar algunos registros y crear una copia con Akeeba Backup cuando esté instalado.

No podrás revisar todos los logs del servidor, restringir la IP de origen, configurar ModSecurity ni analizar otras cuentas alojadas en la misma máquina.

Si tienes cPanel, Plesk o un panel similar

Normalmente podrás gestionar archivos, editar .htaccess, descargar copias, acceder a phpMyAdmin, cambiar PHP, revisar tareas cron y consultar las funciones de seguridad que el proveedor haya habilitado.

Si controlas Cloudflare

Podrás bloquear endpoints, aplicar desafíos, revisar eventos, proteger el administrador y detener parte del tráfico antes de que alcance el alojamiento.

Si administras el servidor

Podrás revisar registros completos, procesos, conexiones, tareas cron, ModSecurity, Imunify360, permisos, otras cuentas y la IP real de origen. También podrás aislar el usuario, tomar snapshots y comparar archivos con paquetes limpios.

La mayoría de propietarios se encuentra entre los dos primeros niveles. Por eso una parte importante de la respuesta consiste en pedir al hosting acciones concretas y no conformarse con un “hemos revisado y no vemos nada raro”, esa frase técnica que puede significar desde “hemos realizado un análisis forense” hasta “la portada carga en nuestro navegador”.

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

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

La copia debe incluir:

• Todos los archivos.
• La base de datos.
• .htaccess.
• configuration.php.
• Archivos asociados situados fuera de la carpeta pública.
• Configuración de cron, correo y servicios externos cuando sea posible.

Descárgala a tu ordenador y, cuando sea posible, conserva otra copia en almacenamiento externo.

Una copia guardada únicamente dentro de la misma cuenta puede ser borrada, alterada o cifrada. También desaparecerá si el proveedor restaura o suspende toda la cuenta. Un backup que comparte piso con la web atacada no es precisamente un plan de evacuación.

Si utilizas Akeeba Backup

Comprueba que la copia ha terminado correctamente y descarga todas sus partes. Un backup dividido puede incluir un archivo principal y varios segmentos; sin todos ellos no podrás restaurarlo.

Kickstart extrae el archivo. ANGIE, incluido dentro de la copia, restaura los ficheros y la base de datos.

La existencia de una línea verde en el panel de Akeeba no sustituye la descarga ni la comprobación del archivo. Las líneas verdes son tranquilizadoras, pero todavía no han conseguido restaurar una web por sí solas.

2. Haz un inventario real de la instalación

Anota:

• Versión de Joomla.
• Versión de PHP.
• Versión de JCE.
• Versión de SP Page Builder.
• Helix3 o Helix Ultimate.
• Versión del framework y de la plantilla.
• Extensiones asociadas al constructor.
• Plugins AJAX.
• Componentes desactivados que continúan instalados.
• Extensiones sin soporte o cuyo desarrollador ha desaparecido.

Una extensión desactivada puede seguir dejando archivos accesibles en el servidor. Cuando ya no sea necesaria, desinstálala y comprueba que no queden carpetas abandonadas.

Este inventario también sirve para detectar la dependencia real de la web. A veces se descubre que una plantilla comercial utiliza un framework, el framework utiliza un plugin AJAX, el constructor necesita una versión concreta de PHP y una pequeña extensión instalada en 2017 sostiene el menú principal por motivos que nadie comprende. Es la clase de cadena que convierte una actualización sencilla en una mudanza con piano.

3. Crea una copia de pruebas antes de actualizar

En una instalación moderna y sencilla puede bastar con hacer backup, actualizar y comprobar. En una web antigua no jugaría esa partida directamente en producción.

La copia de pruebas debería tener:

• Una carpeta y base de datos independientes.
• Protección mediante contraseña o restricción por IP.
• Indexación bloqueada.
• Correos reales desactivados.
• Pagos, reservas y webhooks desconectados.
• Credenciales distintas a producción.

Después de actualizar, prueba la portada, menús, formularios, edición, constructor, buscador, zona privada, correos, pagos, reservas, móvil, redirecciones, tareas programadas y cualquier integración externa.

Abrir la portada, verla bonita y declarar concluida la prueba es un método cómodo. También es el motivo por el que algunos fallos aparecen tres días después, cuando un cliente intenta enviar un formulario o pagar una reserva.

4. Instala las correcciones oficiales compatibles

La prioridad es llegar a una versión corregida, no simplemente a una versión algo menos antigua.

En el momento de publicar esta guía:

• JCE debería estar en la 2.9.99.9.
• SP Page Builder debería estar en la 6.6.2 cuando esa rama sea compatible.
• Helix3 debería estar en la 3.1.3.
• Helix Ultimate debería estar en la 2.2.9.
• Joomla debería estar en una rama mantenida y con las actualizaciones de seguridad instaladas.

Descarga siempre los paquetes desde el desarrollador. No instales archivos compartidos en foros, repositorios desconocidos o enlaces enviados por alguien que aparece de repente para salvarte la web. Los incendios atraen a bomberos y a gente que vende gasolina.

5. Si la web no puede actualizarse, identifica el bloqueo exacto

“No se puede actualizar” describe el resultado, pero no explica el problema.

Puede fallar por:

• Una versión antigua de PHP.
• Una plantilla no compatible.
• Una extensión abandonada.
• Overrides construidos para Joomla 3.
• Código personalizado.
• Una base de datos antigua.
• Dependencias entre framework y constructor.
• Limitaciones del hosting.

Cuando el proyecto está atrapado porque depende de una plataforma o de un proveedor que ya no ofrece una salida razonable, aparece el mismo problema que explicaba en la web barata que terminó saliendo cara cuando llegó el momento de marcharse. El coste no estaba en crearla. Estaba escondido en la dependencia acumulada.

Si la migración va a llevar días o semanas, aplica las medidas temporales siguientes mientras preparas la solución definitiva. Temporal significa temporal, no “lo dejamos así hasta que vuelva a fallar dentro de cuatro años”.

Bloqueo temporal del endpoint de SP Page Builder

Este bloqueo está pensado como contención para el endpoint conocido. No sustituye la actualización ni demuestra que una web expuesta anteriormente esté limpia. Es una tabla puesta contra la puerta mientras llega el cerrajero.

Mediante Cloudflare

Crea una regla personalizada del WAF con una expresión similar a esta:

(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"
 ))

Selecciona la acción:

Block

No utilizaría un desafío. Un visitante legítimo no necesita acceder directamente a esa tarea y resolver tres semáforos para demostrar que es humano.

Después:

• Comprueba que la regla aparece en los eventos de seguridad.
• Prueba la web y el administrador.
• Comprueba la carga de iconos personalizados en SP Page Builder.
• Anota la fecha y el motivo de la regla.
• Revísala cuando la extensión esté actualizada.

Mediante .htaccess

En Apache o LiteSpeed puedes utilizar:

# BLOQUEO TEMPORAL DEL ENDPOINT DE SP PAGE BUILDER
<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>

Coloca la regla antes de las reglas generales SEF de Joomla y comprueba que una petición coincidente devuelve un error 403.

Si utilizas Nginx

Nginx ignora los archivos .htaccess. El bloqueo debe añadirse en la configuración del servidor o del virtual host. Si utilizas hosting gestionado, envía al soporte el dominio, el parámetro, el endpoint y la necesidad de mantener operativo el resto de SP Page Builder.

No sigas editando el .htaccess durante dos horas esperando que Nginx termine entrando en razón. No va a ocurrir.

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>

Esta regla puede romper edición frontend, cargas de medios e integraciones que llamen a JCE desde la parte pública. El parche o la actualización oficial son preferibles.

Impide ejecutar PHP dentro de carpetas de subida

Una carpeta destinada exclusivamente a imágenes, iconos o documentos no debería ejecutar scripts PHP. Una fotografía de la fachada no necesita lanzar procesos en el servidor, por mucho carácter que tenga el edificio.

En subcarpetas concretas de Apache o LiteSpeed puede utilizarse:

<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 determinadas carpetas dentro de:

• /images/.
• /media/.
• Directorios de iconos.
• Carpetas de documentos descargables.
• Directorios de subida creados por extensiones.

No copies esta regla por toda la instalación sin revisar. Algunas extensiones almacenan archivos PHP legítimos dentro de sus propias carpetas. Un bloqueo indiscriminado puede romper la web y esconder el motivo detrás de una colección de errores 403 y 500, la versión informática de apagar todas las luces para que no entren ladrones.

Protege el administrador y reduce cuentas con privilegios

Proteger /administrator no corrige una vulnerabilidad explotable desde el frontend, pero reduce la fuerza bruta, el uso de contraseñas filtradas y los intentos contra cuentas administrativas.

En Cloudflare

Puedes aplicar un desafío administrado a:

starts_with(http.request.uri.path, "/administrator")

Si los administradores trabajan desde IP fijas, el acceso puede restringirse mediante una lista autorizada. Hay que dejar previstas las conexiones legítimas desde otras ubicaciones, salvo que quieras descubrir la eficacia de la regla el primer día que intentes entrar desde el móvil.

Con contraseña adicional del hosting

cPanel y Plesk suelen permitir proteger una carpeta mediante autenticación HTTP. Esto añade una pantalla anterior al login de Joomla.

Comprueba formularios, peticiones AJAX, tareas externas, actualizaciones y servicios que utilicen rutas dentro de /administrator. Una protección demasiado amplia puede bloquear funciones legítimas.

Activa MFA

Todos los Super Users deberían utilizar autenticación multifactor. Elimina administradores antiguos, cuentas compartidas, usuarios de agencias que ya no trabajan en el proyecto y accesos creados para una intervención puntual en 2019 que, por algún misterio, siguen teniendo todos los permisos.

Cada persona debe utilizar una cuenta propia. Cuando todos entran como admin, los registros sirven principalmente para confirmar que alguien hizo algo en algún momento.

Cloudflare solo protege el tráfico que pasa por Cloudflare

Tener una cuenta de Cloudflare no garantiza que la web esté protegida por sus reglas. También se puede tener una alarma sin conectarla, un extintor vacío y un antivirus cuya licencia caducó en febrero.

Comprueba:

• Que los registros web tienen el proxy activado.
• Que el dominio resuelve a direcciones de Cloudflare.
• Que no existen subdominios como origin, direct o server apuntando a la IP real.
• Que el correo no revela innecesariamente la misma IP del servidor web.
• Que la IP antigua no sigue accesible mediante registros DNS históricos.

Si alguien conoce la dirección real del servidor, puede enviar las peticiones directamente y evitar el WAF.

La solución más sólida es permitir conexiones HTTP y HTTPS desde los rangos oficiales de Cloudflare y bloquear el resto, dejando autorizados los proveedores o servicios que necesiten acceso directo. Esa configuración corresponde al hosting o al administrador del servidor.

Puedes preguntar al alojamiento:

Utilizo Cloudflare como proxy para el dominio. ¿Podéis confirmar si el servidor acepta conexiones HTTP y HTTPS directas a la IP de origen? Si las acepta, ¿podéis limitar esos puertos a los rangos oficiales de Cloudflare y a los servicios autorizados, manteniendo operativos el correo y el panel?

No experimentes con el firewall del servidor si no controlas su configuración completa. Bloquear el puerto equivocado es una medida de seguridad extraordinariamente eficaz contra clientes, buscadores, administradores y cualquier otra forma de tráfico.

Revisa el WAF sin crear un agujero más grande para solucionar un falso positivo

Cloudflare, ModSecurity e Imunify pueden bloquear peticiones legítimas de Joomla, JCE o SP Page Builder.

Cuando eso ocurre, la respuesta habitual consiste en desactivar la regla que molesta. El problema aparece cuando se crea una excepción global y se deja funcionando durante años, como una ventana abierta con un cartel que dice “no cerrar, entra corriente”.

Una excepción debería limitarse a:

• Una ruta concreta.
• Una regla específica.
• Una cuenta autenticada.
• Una IP autorizada.
• Un método HTTP.
• Un parámetro conocido.

No desactives todo el conjunto OWASP porque JCE devuelva un falso positivo. La versión 2.9.99.9 se publicó precisamente para corregir incompatibilidades con determinadas reglas de Cloudflare e Imunify.

Pregunta al hosting por Imunify360, ModSecurity y los análisis disponibles

La mayoría de usuarios no administra Imunify360. Puede estar instalado en el servidor y no aparecer en el panel del cliente, o mostrarse en una versión limitada.

Imunify360 puede incluir:

• Firewall.
• WAF.
• Escáner de archivos.
• Análisis en tiempo real.
• Proactive Defense para código PHP.
• Escáner de bases de datos compatible con Joomla.
• Detección de tareas cron maliciosas.
• Limpieza o cuarentena.

También pueden existir otras herramientas: ModSecurity, Patchman, ClamAV, Linux Malware Detect, ConfigServer Security & Firewall o sistemas propios del proveedor.

Pide que te confirmen:

• Qué productos están activos.
• Si funcionan en modo bloqueo o solo registran.
• Si el análisis incluye la base de datos.
• Si Proactive Defense está activado.
• Si han encontrado archivos o tareas cron sospechosas.
• Si la limpieza automática ha modificado algo.
• Si conservan los logs del periodo afectado.
• Si otras webs de la misma cuenta presentan indicios similares.

No pulses “limpiar todo” antes de guardar una copia. La limpieza automática puede eliminar una puerta trasera, pero también dejar incompleta una extensión legítima. El botón grande y tranquilizador no siempre contiene una estrategia forense detrás.

Qué buscar en los registros y en los archivos

En los logs de acceso busca cadenas como:

com_sppagebuilder
asset.uploadCustomIcon
com_jce
com_ajax
helix3
helixultimate

Con acceso SSH puede utilizarse una búsqueda orientativa:

grep -Ei 'com_jce|com_sppagebuilder|uploadCustomIcon|helix3|helixultimate' access.log

También interesa revisar:

• Peticiones POST a rutas poco habituales.
• Respuestas 200 a peticiones que deberían haber sido rechazadas.
• Accesos directos a archivos PHP dentro de carpetas de medios.
• Peticiones a archivos creados pocos segundos antes.
• Picos de consumo de CPU o memoria.
• Envíos anormales de correo.
• User agents vacíos o extraños.
• Muchas IP atacando el mismo endpoint.

Para localizar scripts en carpetas donde no deberían existir:

find images media -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" \) -print

La presencia de una petición maliciosa bloqueada no demuestra una intrusión. Una respuesta correcta del servidor, seguida de la creación o ejecución de un archivo, sí merece una investigación inmediata.

Bloquear direcciones IP una por una tiene una eficacia limitada cuando el ataque utiliza redes distribuidas. Es mejor bloquear la operación vulnerable que pasarse la tarde jugando a matar moscas con una libreta de direcciones.

Configura alertas antes de necesitarlas

Resulta útil recibir avisos por:

• Caída de la web.
• Cambio inesperado de la portada.
• Creación de archivos PHP en carpetas de subida.
• Modificación de archivos críticos.
• Nuevos usuarios administrativos.
• Aumento brusco de consumo.
• Envíos masivos de correo.
• Problemas de seguridad en Search Console.
• Inclusión del dominio en listas de malware o spam.

Una alerta no evita el ataque, pero puede reducir de varias semanas a unas horas el tiempo durante el que permanece oculto. Descubrir una intrusión pronto suele salir bastante más barato que enterarse porque un cliente ha buscado tu empresa y Google le ha recomendado un casino de criptomonedas.

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

Señales que deberían activar el procedimiento de recuperación

• Archivos PHP desconocidos.
• Super Users que nadie reconoce.
• Perfiles de JCE modificados.
• Páginas desfiguradas.
• Redirecciones a casinos, medicamentos o contenido adulto.
• Scripts externos insertados.
• Páginas de spam indexadas.
• Correos enviados desde la cuenta.
• Avisos del hosting, navegador o Search Console.
• Consumo anormal de recursos.
• Tareas cron desconocidas.
• Archivos que reaparecen después de borrarlos.

La ausencia de estos síntomas no garantiza que el sitio esté limpio. Muchas intrusiones intentan mantener el acceso sin modificar la portada. Una puerta trasera silenciosa resulta bastante más útil que una calavera giratoria con música de fondo.

1. Aísla la web sin destruir las pruebas

Dependiendo del acceso disponible, puedes:

• Ponerla en mantenimiento.
• Protegerla con contraseña HTTP.
• Restringir el acceso por IP.
• Desactivar temporalmente la ejecución PHP.
• Publicar una página estática de mantenimiento.
• Pedir al hosting que aísle la cuenta.

Antes de sustituir archivos, guarda:

• La instalación completa.
• La base de datos.
• Logs de acceso, error, PHP y correo.
• Alertas de seguridad.
• Lista de usuarios.
• Tareas cron.
• Fechas de modificación.
• Capturas de los síntomas.
• Configuración de Cloudflare.

Conserva una copia sin modificar y trabaja sobre un duplicado.

Si la web almacena datos personales, pagos, información sanitaria u otra información sensible, la incidencia puede exigir una evaluación legal y de protección de datos. En ese caso debe participar un profesional especializado. “Hemos borrado el archivo raro y parece que va bien” no constituye un análisis de impacto.

2. Busca una copia anterior a la entrada, no anterior al descubrimiento

Una web puede llevar semanas comprometida antes de que aparezca el primer síntoma visible.

Busca backups en:

• Akeeba Backup.
• JetBackup.
• R1Soft.
• cPanel o Plesk.
• Snapshots del servidor.
• Amazon S3.
• Google Drive.
• Dropbox.
• Discos locales.
• Repositorios privados.
• Ordenadores de antiguos desarrolladores.

Intenta determinar:

• La primera petición maliciosa.
• El primer archivo desconocido.
• La creación del primer administrador sospechoso.
• El primer envío de spam.
• La primera alerta del alojamiento.
• La primera modificación visible.

Elige una copia anterior y deja margen. Si la primera prueba es del 18 de junio, una copia del día 17 puede contener ya una puerta trasera que todavía no había sido utilizada. El malware también sabe esperar.

3. No restaures encima de la instalación infectada

Este es uno de los errores más peligrosos.

Akeeba Backup sobrescribe los archivos incluidos en la copia, pero no elimina automáticamente los archivos adicionales que ya existen en el servidor.

Si el atacante creó shell.php después de la fecha del backup, restaurar encima puede dejar ese archivo exactamente donde estaba, observando cómo trabajas.

El procedimiento más seguro es:

1. Guardar el estado comprometido.
2. Crear una carpeta nueva o vaciar completamente la ubicación de destino.
3. Crear una base de datos nueva o vaciar la anterior.
4. Restaurar la copia limpia.
5. Actualizar Joomla y las extensiones antes de publicar.
6. Analizar archivos y base de datos.
7. Cambiar todas las credenciales.
8. Probar la web en un entorno aislado.
9. Publicar únicamente después de cerrar la vía de entrada.

No mezcles archivos limpios, antiguos e infectados esperando que la restauración se imponga por mayoría. Los servidores no resuelven conflictos mediante votación.

4. Recupera los datos recientes de forma selectiva

Una copia antigua puede dejar fuera pedidos, reservas, formularios, usuarios, artículos y cambios realizados después.

No importes la base de datos comprometida completa sobre la restaurada. Eso sería retirar el agua del barco y volver a meterla porque dentro había dos pedidos nuevos.

Puede ser necesario:

• Exportar registros concretos por fecha.
• Comparar tablas.
• Recuperar pedidos desde el componente.
• Reconstruir formularios a partir de correos.
• Importar únicamente contenido verificado.
• Consultar la base comprometida desde un entorno aislado.

En tiendas, reservas y zonas privadas, esta fase puede resultar más complicada que restaurar los archivos.

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

Busca:

• Super Users desconocidos.
• Cuentas creadas recientemente.
• Correos extraños.
• Usuarios antiguos todavía activos.
• Cambios de grupo o privilegios.
• Nombres parecidos a los administradores legítimos.
• Métodos MFA añadidos.
• Plugins de autenticación desconocidos.
• Tokens y claves API.

No basta con eliminar la cuenta. Hay que determinar cuándo apareció y qué acciones pudo realizar. Borrar al usuario support_admin_2 no borra los archivos que haya creado durante su estancia.

6. Revisa los archivos manualmente

Examina especialmente:

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

Busca:

• PHP dentro de carpetas de imágenes.
• Extensiones dobles.
• Archivos .phtml, .phar, .php5 o similares.
• Archivos ocultos.
• Nombres casi idénticos a ficheros legítimos.
• Código ofuscado.
• Redirecciones.
• JavaScript externo.
• Archivos creados en el mismo minuto.

Funciones como base64_decode, eval, gzinflate, system o shell_exec pueden aparecer en malware, pero también en software legítimo. Compara el archivo con el paquete original antes de borrarlo. El método de “buscar palabras feas y eliminar todo” puede terminar limpiando la web de malware, extensiones y funcionamiento.

7. Revisa la base de datos

Comprueba:

• Usuarios y permisos.
• Extensiones instaladas.
• Plugins activados.
• Módulos HTML personalizados.
• Artículos y campos personalizados.
• Plantillas y configuraciones.
• Perfiles de JCE.
• Datos de SP Page Builder.
• Código personalizado de Helix.
• Menús y redirecciones.
• Sesiones y tokens.

Busca scripts, iframes, enlaces de spam, dominios externos, contenido codificado y parámetros que no estaban antes.

8. Revisa .htaccess, configuration.php y cron

En .htaccess busca:

• Redirecciones solo para Google.
• Reglas según dispositivo o user agent.
• Dominios externos.
• Excepciones desconocidas.
• Ejecución de PHP mediante extensiones alternativas.
• Permisos añadidos en carpetas de subida.

En configuration.php revisa la base de datos, rutas, correo, depuración, sesiones y cualquier cambio reciente.

En las tareas cron busca llamadas a curl, wget, scripts dentro de /tmp, archivos desconocidos y trabajos creados recientemente.

Una tarea cron puede volver a generar la puerta trasera cada vez que la eliminas. Si el archivo resucita varias veces, no es perseverancia del sistema: alguien ha preparado el mecanismo.

9. Cambia todas las credenciales desde un equipo limpio

Cambia:

• Joomla.
• Hosting.
• cPanel o Plesk.
• FTP, SFTP y SSH.
• Base de datos.
• Cloudflare.
• Correo administrativo.
• Almacenamiento de backups.
• SMTP.
• APIs.
• Pagos.
• Registrador del dominio.
• Repositorios.

Revisa el ordenador utilizado para administrar la web, las extensiones del navegador, el cliente FTP, el correo y las sesiones activas de Google o Microsoft.

Cambiar la contraseña desde un equipo comprometido solo entrega al atacante una contraseña nueva, limpia y recién estrenada. Un detalle de cortesía que probablemente no necesitas tener.

10. Revisa todas las webs de la misma cuenta

Una instalación limpia puede volver a infectarse desde otra web vulnerable que comparte usuario y permisos.

Analiza:

• Dominios adicionales.
• Subdominios.
• Carpetas de pruebas.
• Joomlas abandonados.
• WordPress olvidados.
• Copias antiguas.
• ZIP y SQL públicos.
• Repositorios .git.

Cuando sea posible, separa los proyectos en cuentas diferentes. Alojar seis webs, tres pruebas y una copia de 2018 bajo el mismo usuario es muy cómodo hasta que una de ellas decide compartir el problema con todas las demás.

Después de limpiar la web, revisa el daño SEO

Eliminar el malware no arregla automáticamente lo que Google haya rastreado mientras la web estuvo comprometida.

Revisa en Search Console:

• Problemas de seguridad.
• Acciones manuales.
• Nuevos propietarios o métodos de verificación.
• Solicitudes de retirada.
• Sitemaps desconocidos.
• Páginas indexadas en otros idiomas.
• Caídas repentinas de clics e impresiones.

Busca en Google:

site:tudominio.com

y combina el dominio con términos habituales de spam: casino, apuestas, medicamentos, contenido adulto o marcas que no tienen ninguna relación con el negocio.

Revisa también Analytics, logs, correo saliente, reputación de la IP y listas negras.

Si necesitas interpretar una caída o detectar cuándo empezó el problema, la guía sobre clics, impresiones, CTR y cambios de Search Console ayuda a separar una pérdida real de visibilidad de un cambio de medición.

Cuando el sitio esté limpio, solicita la revisión correspondiente en Search Console y actualiza las URL afectadas. No envíes cientos de solicitudes de indexación a ciegas. Google dispone de suficientes botones para perder el tiempo sin necesidad de pulsarlos todos.

Qué pedir al hosting

Cuando no controles el servidor, envía una petición concreta. Puedes adaptar este texto:

Mi web utiliza Joomla junto con JCE, SP Page Builder, Helix3 o Helix Ultimate y puede haber estado expuesta a vulnerabilidades publicadas en junio y julio de 2026.

Necesito que reviséis:

1. Si utilizáis Imunify360, ImunifyAV, ModSecurity, Patchman u otro sistema de protección.
2. Si se han detectado o limpiado archivos maliciosos dentro de la cuenta.
3. Si podéis ejecutar un análisis completo de archivos y de la base de datos Joomla.
4. Si hay eventos relacionados con com_jce, com_sppagebuilder, asset.uploadCustomIcon, com_ajax, helix3 o helixultimate.
5. Si podéis conservar y facilitar los logs de acceso, error, PHP y correo del periodo afectado.
6. Si existen tareas cron desconocidas.
7. Si otras webs de la misma cuenta presentan archivos sospechosos.
8. Si disponéis de una copia anterior a la primera actividad detectada.
9. Si el servidor acepta conexiones directas a la IP de origen evitando Cloudflare.
10. Si podéis aplicar una regla temporal para bloquear los endpoints afectados.
11. Si se ha producido envío anormal de correo.
12. Si la cuenta puede aislarse mientras se realiza la recuperación.

Añade el dominio, la zona horaria, las horas exactas, rutas, capturas, archivos detectados y mensajes de error.

“La web hizo algo raro el martes” da bastante menos margen de investigación que “a las 03:42 CET se creó este archivo después de una petición POST a este endpoint”. Aunque ambos mensajes suelen recibir inicialmente la misma respuesta automática agradeciendo que hayas contactado con soporte.

Medidas adicionales que pueden reducir la exposición

Desactiva o elimina extensiones que no se utilicen

Desactivar un componente puede no impedir el acceso directo a todos sus archivos. Desinstalarlo puede borrar datos. Haz una copia y comprueba el resultado.

No bloquees globalmente com_ajax

Helix y muchas extensiones utilizan com_ajax para formularios, menús, módulos y procesos dinámicos. Bloquearlo entero puede dejar media web sin funcionar.

Las reglas deben identificar el plugin, la tarea, el método y los parámetros concretos. Cerrar toda la autopista porque un coche circula mal suele producir algunos efectos secundarios.

Utiliza rate limiting con objetivos claros

Puede aplicarse al login, formularios, endpoints concretos o peticiones POST repetidas. Un límite general demasiado bajo puede bloquear usuarios detrás de una misma red, aplicaciones, sistemas de pago y bots legítimos.

El bloqueo geográfico solo reduce ruido

Puede tener sentido en una web estrictamente local, pero los atacantes utilizan VPN y servidores del mismo país. No lo utilices como defensa principal. Los delincuentes informáticos también han descubierto los vuelos internacionales virtuales.

Desactiva la edición frontend cuando no sea necesaria

Revisa ACL, permisos de publicación, perfiles de JCE y funciones de subida pública.

Comprueba los permisos

Como orientación habitual:

Directorios: 755
Archivos: 644
configuration.php: más restrictivo cuando el hosting lo permita

No utilices permisos 777 como solución permanente. Dar permiso total a todo el mundo corrige muchos errores de escritura y crea una colección estupenda de problemas nuevos.

Protege archivos sensibles

No deberían ser accesibles públicamente:

• Copias JPA, JPS o ZIP.
• Exportaciones SQL.
• Logs.
• Archivos .env.
• Copias de configuration.php.
• Ficheros con sufijos .bak, .old o .save.
• Repositorios .git.

Errores que complican la recuperación

Restaurar encima de la web infectada

Puede conservar archivos maliciosos que no existían en el backup. Es la forma digital de cambiar las sábanas sin comprobar quién sigue durmiendo en la habitación.

Actualizar y dar el asunto por resuelto

La actualización cierra la vulnerabilidad, pero no elimina las puertas traseras anteriores.

Confiar únicamente en un escáner

Un resultado limpio reduce la sospecha. No demuestra que no exista malware desconocido.

Borrar logs y archivos antes de guardar una copia

Impide reconstruir el incidente y elimina la posibilidad de volver atrás.

Mantener las mismas credenciales

Permite regresar mediante una cuenta legítima, con la tranquilidad de quien todavía conserva las llaves.

Bloquear todo com_ajax

Puede romper formularios, módulos, menús y otras funciones.

Copiar un .htaccess gigantesco sin entenderlo

Añade errores, falsos positivos y reglas que nadie sabrá mantener. Que tenga 900 líneas no significa que proteja 900 veces más.

Publicar la copia restaurada antes de actualizarla

Devuelve a Internet exactamente la misma vulnerabilidad, recién restaurada y con aspecto saludable.

Ignorar otras webs de la cuenta

Una instalación abandonada puede reinfectar la principal.

Guardar el único backup dentro del hosting

Cuando cae la cuenta, cae también la copia. Van juntas a todas partes.

Asumir que no hubo ataque porque la portada sigue bien

Una puerta trasera silenciosa es mucho más útil para el atacante que una calavera girando sobre fondo negro.

Orden de actuación resumido

Si no hay señales de intrusión

1. Haz una copia completa y descárgala.
2. Anota versiones y dependencias.
3. Crea una copia de pruebas.
4. Actualiza Joomla y las extensiones.
5. Aplica el parche oficial de JCE cuando sea necesario.
6. Bloquea temporalmente el endpoint de SP Page Builder si no puedes actualizar.
7. Revisa Helix3 y Helix Ultimate por separado.
8. Activa MFA.
9. Revisa administradores, archivos y base de datos.
10. Pide al hosting un análisis completo.
11. Revisa logs y correo.
12. Prepara una migración si la instalación ha quedado sin una ruta segura.

Si la web ya está comprometida

1. Aísla la web.
2. Conserva archivos, base de datos y registros.
3. Determina la primera actividad sospechosa.
4. Busca una copia anterior.
5. Restaura en una carpeta y base de datos limpias.
6. Actualiza antes de publicar.
7. Analiza archivos y base de datos.
8. Revisa usuarios, cron, plantillas, plugins y configuración.
9. Recupera los datos posteriores de forma selectiva.
10. Cambia todas las credenciales desde un equipo limpio.
11. Revisa el resto de instalaciones de la cuenta.
12. Comprueba Search Console, correo y reputación.
13. Crea un nuevo backup limpio.
14. Mantén monitorización después de publicar.

¿Y si no puedes hacerlo?

Puede que tengas una web antigua, una versión de Joomla que no admite las extensiones actuales o una plantilla que amenaza con descomponerse en cuanto alguien pulsa “actualizar”.

También puede que no sepas si la web está infectada, dónde guarda las copias el hosting o qué diferencia hay entre Helix3 y Helix Ultimate. Bastante tienes ya con dirigir tu negocio como para añadir a la semana una investigación forense de PHP.

Las medidas de esta guía permiten cerrar algunos accesos, pedir al proveedor la información adecuada y evitar errores que complican la recuperación.

Cuando la instalación es antigua o existen señales de intrusión, prefiero revisar el conjunto antes de empezar a borrar archivos como quien limpia un trastero cinco minutos antes de una mudanza.

Puedo comprobar versiones, revisar las copias disponibles, preparar reglas temporales, hablar con el hosting con datos concretos, buscar señales de compromiso y estudiar una actualización o una migración que no convierta el menú principal en una pieza de arte conceptual.

No todas las instalaciones se resuelven pulsando un botón.

Algunas necesitan una actualización. Otras una migración. Y unas cuantas necesitan que alguien abra la carpeta de archivos, respire profundamente y descubra por qué existen diecisiete copias de index.php con nombres distintos y una carpeta llamada web-vieja-no-borrar-definitiva-2.

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. La configuración exacta depende de Joomla, las extensiones, el servidor y los servicios utilizados.

Las reglas temporales pueden reducir el riesgo, pero no sustituyen:

• La actualización.
• La revisión técnica.
• Las copias externas.
• El análisis posterior a una intrusión.
• La renovación de una instalación fuera de soporte.

Los ataques automatizados seguirán probando estas vulnerabilidades mientras encuentren webs expuestas.

No esperan a que tengas tiempo, a que el proveedor responda, a que vuelva el informático de vacaciones ni a que recuerdes dónde guardaste las claves del hosting.