Seguridad en Joomla: JCE, SP Page Builder, Helix y cómo recuperar una web

En el Frecuencia 942 de hoy vuelvo a la seguridad de Joomla. Entre renovar webs, revisar ataques y comprobar actualizaciones, esta guía se había quedado con una foto de julio. Y el verano, que ya venía entretenido, siguió repartiendo trabajo. Si actualizaste una vez, viste todo verde y cerraste el panel, hay unas cuantas cosas que revisar. El color verde tiene muy buena prensa en informática; a veces le damos más responsabilidades de las que puede asumir.

JCE, SP Page Builder y Helix siguen aquí, acompañados de otros componentes que permiten subir archivos, consultar información, gestionar pedidos o guardar código dentro de la configuración. También han llegado correcciones al propio Joomla, a sus controles de acceso y a la autenticación multifactor. Por eso he rehecho la guía: para comprobar qué estuvo expuesto, cerrar lo que siga abierto y recuperar la web sin perder los datos ni conservar al visitante que se coló.

Hay una diferencia que merece quedar clara desde el principio. Tener instalada una versión vulnerable acredita una exposición que hay que evaluar. Para afirmar que alguien entró hacen falta indicios o evidencias. Y para afirmar que hemos terminado la recuperación hace falta algo más que una portada que vuelve a cargar. Un atacante puede modificar una plantilla, leer datos o enviar correo mientras la web sigue enseñando la misma fotografía del equipo, todos muy sonrientes.

Las versiones y los avisos de este texto están comprobados a 15 de octubre de 2026. Las fuentes enlazadas están al final; las llamadas numeradas llevan a ellas. Los procedimientos de revisión, los ejemplos y el orden de trabajo son mi propuesta para aplicarlos a una instalación concreta.

Versiones y avisos que han cambiado

La tabla de julio ya no sirve para decidir qué instalar hoy. Algunas cifras siguen identificando el primer parche de una vulnerabilidad, pero han aparecido correcciones posteriores. Utilizaré esas versiones antiguas para explicar lo ocurrido; para mantener una web buscaría la versión estable compatible que ofrece su desarrollador en la fecha de la intervención.

El inventario debe identificar el producto, su edición y su rama. SP Page Builder Free y Pro no comparten todas las funciones; un parche para Joomla 3 tiene un alcance propio; Helix3 y Helix Ultimate son productos distintos. Comparar solo el número más grande de una lista puede dejarnos con un paquete que ni corresponde a la instalación. Tampoco instalaría un QuickStart sobre una web existente: suele ser una instalación de demostración, no su actualización.

Joomla: los avisos de septiembre y las versiones de octubre

Las publicaciones estables consultadas son Joomla 6.2.0 y 5.4.10, ambas del 13 de octubre.^[1][2] Los avisos de seguridad de septiembre señalan como versiones corregidas 6.1.4 y 5.4.9 para problemas que afectaban a ramas anteriores. Incluyen controles de permisos, creación indebida de cuentas, XSS, solicitudes del servidor y borrado de directorios a través de la caché, entre otros.^[3]

Destaca CVE-2026-92227: un problema con las cookies de «Recordarme» podía permitir eludir MFA en versiones afectadas. También hubo una corrección anterior de MFA en agosto.^[4] Mantendría la autenticación multifactor y actualizaría el núcleo que la implementa. Tener activado un control exige revisar sus actualizaciones, igual que cualquier otra parte del sistema.

En una web que deba permanecer temporalmente en Joomla 5, distinguiría aplicar su actualización mantenida de preparar el salto a Joomla 6. Una migración puede exigir revisar PHP, plantilla y extensiones. Ese trabajo debe planificarse; tampoco debería convertirse en la excusa para dejar sin aplicar el parche disponible en la rama que se utiliza. La agenda del rediseño y la de una vulnerabilidad explotable pueden llevar bastante mal lo de compartir fecha.

SP Page Builder: junio, julio, agosto, septiembre y octubre

SP Page Builder necesita una cronología porque aquí quedarse con el primer aviso da una imagen incompleta. La corrección de una operación no permite dar por corregidas las demás. Además, revisando las fuentes he encontrado un error en la versión anterior de esta guía: CVE-2026-65876 seguía afectando a 6.7.1 y su corrección corresponde a 6.8.0. Queda corregido en este repaso.^[9]

En septiembre aparecen CVE-2026-78375, CVE-2026-79700, CVE-2026-79701, CVE-2026-81564, CVE-2026-81565 y CVE-2026-81566. El problema de SQL requiere una cuenta con permisos suficientes para guardar contenido; los de CAPTCHA afectan a funciones públicas en sus condiciones concretas. Sería incorrecto presentar los seis como una misma entrada anónima. Para la revisión práctica interesa comprobar tanto los permisos de menús como las rutas de subida y renombrado de medios, además de la respuesta del CAPTCHA en servidor.

Que el formulario muestre el recuadro de verificación tampoco demuestra que el servidor compruebe su resultado. Si se utiliza Contact Form, Opt-in Form o Form Builder dentro de un módulo, revisaría precisamente ese contexto después de actualizar. Es uno de esos detalles que desaparecen cuando la comprobación consiste en abrir la portada, asentir con satisfacción y marcharse a comer.

Para Joomla 3 el proveedor ofrece una línea de parches diferente. La revisión 1.0.3, del 2 de octubre, documenta correcciones de CAPTCHA en módulos y de XSS en un filtro de contenido dinámico.^[12] Hay que comprobar su compatibilidad y las correcciones que incorpora para esa instalación. No trasladaría automáticamente a esa rama las conclusiones de la versión 6 ni daría por suficiente el primer ZIP publicado en julio.

JCE: actualizar y revisar los perfiles

El aviso de JCE sigue siendo una referencia para investigar una posible intrusión. CVE-2026-48907 permitía crear perfiles sin autenticación y terminar subiendo código PHP. La corrección inicial fue 2.9.99.5. El desarrollador pide revisar perfiles desconocidos y conservar los archivos sospechosos antes de retirarlos.^[5] Buscaría cambios en permisos, tipos de archivo y destinos de subida, además de comprobar qué cuentas utilizaban el editor.

El anuncio del 7 de octubre ofrece JCE Pro 3.0.2 para Joomla 5 y 6, y JCE Pro 2.9.99.12 para Joomla 3, 4, 5 y 6.^[6] Son referencias de las ediciones publicadas que he consultado, no una obligación de comprar Pro ni una invitación a instalar la rama 3 en cualquier Joomla. En cada web revisaría su edición y el paquete oficial que le corresponde.

Un perfil raro merece investigación aunque el editor funcione. También puede haber un archivo subido antes de la actualización que siga disponible después. El parche debe cerrar la vía conocida; la revisión posterior tiene que ocuparse de lo que pudo haberse guardado mientras estuvo abierta.

Helix: plantilla, plugins y configuración guardada

Para Helix Ultimate he comprobado la versión 2.2.10, cuyo historial incluye correcciones del saneado de Mega Menu y de código incrustado de audio y vídeo. La página oficial de Helix3 ofrece 3.1.4.^[13][14] La plantilla instalada sobre el framework y sus plugins deben revisarse juntos. Puede haber archivos modificados a mano, versiones mezcladas u overrides que continúen ejecutando código antiguo.

En Helix3, el problema descrito por CVE-2026-49049 afecta al manejador AJAX y al acceso no autorizado a operaciones de archivos y configuración.^[38] Por eso revisaría también #__template_styles y los parámetros del estilo: JavaScript personalizado, inserciones en cabecera, código adicional y dominios que nadie reconoce. El prefijo #__ representa el prefijo real de las tablas de esa instalación.

Un análisis de archivos puede pasar por alto un script guardado en la base de datos. Y una reinstalación del framework puede conservar exactamente ese parámetro. La revisión debe relacionar el código instalado con lo que Joomla está leyendo al generar la página; sustituir el ZIP y conservar una configuración manipulada deja una parte del trabajo pendiente.

Otras extensiones que siguen dentro del inventario

Conservo las alertas del artículo anterior como referencias para investigar instalaciones que estuvieron expuestas. Las cifras siguientes identifican correcciones de esos avisos, no certifican que una versión antigua siga siendo la recomendada en octubre. Antes de intervenir hay que comprobar los avisos posteriores y la rama mantenida de cada proveedor.

RSFiles!, Gridbox, Events Booking y jDownloads también formaban parte del inventario de alertas de la guía anterior. Si están instalados, deben entrar en la comprobación de versiones y avisos de su proveedor. No les asigno aquí una versión «segura» por semejanza con otro producto. Tampoco elijo qué revisar únicamente por si el nombre aparece en esta tabla: el punto de partida es el inventario completo de la web.

En el catálogo oficial KEV he contrastado los cinco avisos que señalaba el artículo: JCE, SP Page Builder, PageBuilder CK, iCagenda y Balbooa Forms.^[7] Su presencia documenta explotación conocida. No demuestra que una web concreta haya sido comprometida, ni permite extender esa afirmación a todos los CVE de la misma marca. Sí justifica dar prioridad a una instalación afectada y conservar sus registros cuanto antes.

Qué hacer según lo que encuentres

Antes de encadenar actualizaciones, anotaría qué sabemos de esa web. Un intento bloqueado, una versión afectada y una modificación no autorizada son observaciones distintas. Mezclarlas produce informes aparatosos y decisiones poco precisas. También tiene su peligro el extremo contrario: llamar «ruido de bots» a cualquier cosa porque el negocio todavía recibe llamadas.

Una SQL injection puede permitir consultar información sin crear un archivo. Un fallo de permisos puede mostrar una factura ajena sin modificar la tienda. Una vulnerabilidad de correo puede utilizar un formulario que sigue pareciendo normal. El tipo de fallo determina qué hay que investigar. Buscar únicamente PHP extraño dejaría fuera varias de las preguntas que este verano nos ha puesto encima de la mesa.

La exposición depende también de las funciones presentes y los permisos. Un problema autenticado requiere revisar qué cuentas podían alcanzar la operación; uno público puede ser relevante aunque el administrador tenga MFA y una contraseña magnífica. Para ordenar el trabajo ponderaría la explotación conocida, la exposición real, los datos del negocio y las medidas que ya existen. Una web de reservas con información de clientes no se evalúa mirando únicamente si utiliza la misma plantilla que otra.

La ausencia de síntomas exige prudencia en las dos direcciones. No la convertiría en una fuga confirmada ni la utilizaría para asegurar que no pasó nada. Cuando falten registros, lo dejaría escrito. «No se han encontrado indicios en los datos disponibles» es una conclusión defendible si explicas qué has revisado. «Cien por cien limpio» es bastante más corto y bastante más difícil de sostener.

Y puede que nadie haya decidido atacarte personalmente. Los intentos automatizados pueden recorrer dominios sin saber si detrás hay una tienda, un estudio de pilates o una asociación que actualiza el blog por Navidad. Aun así, la atribución exige pruebas. Para proteger la web suele resultar más urgente comprobar la operación vulnerable que ponerle nacionalidad al bot.

Copias y actualizaciones comprobables

La primera tarea es disponer de una copia que permita investigar y recuperar. Incluiría los archivos, la base de datos, las configuraciones relevantes, las tareas programadas y los registros disponibles. Guardaría fecha, zona horaria y alcance. Si la web ya presenta señales de intrusión, esa captura conserva el estado sospechoso: no debe etiquetarse como copia limpia ni utilizarse sin revisión para reconstruir.

Akeeba recomienda mantener copias fuera de la web y advierte de una limitación decisiva: restaurar un archivo de respaldo no elimina automáticamente los ficheros que existen en el destino y no están dentro de la copia.^[27] Por tanto, una puerta trasera añadida después puede sobrevivir a una restauración hecha encima. Volver a ver la portada de la semana pasada puede dar bastante alivio mientras el archivo del atacante sigue exactamente donde estaba.

Una copia descargada todavía necesita una prueba

Comprobaría que se han generado todas las partes del archivo, que el volcado SQL contiene las tablas esperadas y que las exclusiones no han dejado fuera contenido necesario. Haría una restauración en un destino independiente y probaría páginas, acceso administrativo y datos importantes. En una tienda, contrastaría pedidos; en una web de reservas, las reservas. Abrir el ZIP y encontrar carpetas acredita que contiene carpetas. El negocio suele necesitar algo más.

Un manifiesto con huellas SHA-256 ayuda a comprobar que una copia no ha cambiado durante su traslado. También permite comparar archivos entre dos capturas. Su límite es el origen de la referencia: calcular hoy la huella de un archivo manipulado conserva una referencia manipulada. Para comprobar código distribuido por un proveedor necesitamos un paquete oficial correspondiente a la misma versión, no solo dos copias que coincidan entre sí.

El respaldo completo quedaría fuera del directorio público y con acceso restringido. Un SQL, un archivo de configuración o un paquete de recuperación pueden contener datos personales y credenciales. No los dejaría en una carpeta del sitio confiando en que nadie adivine el nombre. Tampoco subiría esos archivos a un repositorio público o a un escáner externo para pedirle una opinión rápida.

Conservaría al menos una copia fuera de la misma cuenta de hosting. Si el incidente afecta a esa cuenta, a sus permisos o a su almacenamiento, las copias que comparten acceso pueden quedar expuestas también. El criterio para elegir retención y frecuencia debe permitir recuperar un estado anterior al incidente y asumir una pérdida de datos que el negocio conozca. Hacer una copia cada mes puede resultar muy ordenado hasta que hay que reconstruir veintinueve días de trabajo.

El inventario incluye lo que nadie utiliza

Anotaría Joomla, PHP, base de datos, plantilla, frameworks, componentes, plugins, módulos y bibliotecas. Para cada extensión guardaría versión, edición, procedencia del paquete, función que cumple, dependencias y situación de soporte. Incluiría los plugins desactivados y las instalaciones antiguas que siguen dentro de la cuenta. Desactivar una extensión no retira sus archivos ni acredita por sí solo que todas sus rutas hayan quedado inaccesibles.

Si una extensión ya no se usa, prepararía su retirada después de comprobar referencias y guardar una copia. Puede haber contenido generado con sus etiquetas, módulos ocultos en ciertas páginas, tareas programadas o campos que dependen de ella. No borraría carpetas a mano para hacer limpieza de primavera en octubre. La desinstalación debe seguir el procedimiento del producto y comprobar qué datos conserva o elimina.

Este inventario también descubre por qué una actualización no aparece: una clave de descarga caducada, un sitio de actualizaciones desactivado, requisitos de PHP, una rama abandonada o una instalación cuyo registro no coincide con sus archivos. El panel puede estar diciendo «no tengo una actualización que ofrecerte». Es una afirmación bastante más limitada que «todo lo instalado está mantenido y corregido».

Un clon de pruebas puede seguir hablando con producción

Crearía la copia de ensayo con archivos, base de datos y credenciales independientes. La protegería mediante autenticación o acceso restringido y la excluiría de indexación. noindex ayuda a controlar su aparición en buscadores; no impide que alguien acceda a una URL que conoce. Un clon con datos personales necesita protección de acceso, además de esa indicación a los robots.

Revisaría correo, pasarelas, webhooks, automatizaciones, tareas de Joomla, cron y servicios externos. Un clon puede enviar el resumen diario a los clientes, lanzar una sincronización o confirmar una operación real aunque nadie pulse el formulario. El calendario y las tareas programadas también trabajan cuando tú estás mirando otra pestaña, detalle muy suyo.

Para el correo usaría un receptor de pruebas y destinatarios ficticios. Para pagos y otras integraciones, sus modos de ensayo o simulaciones cuando estén disponibles. Si necesito validar una conexión real, definiría antes qué datos se envían, qué cuenta se utiliza y qué efecto puede producir. Cambiar el dominio del clon no cambia automáticamente todos los destinos guardados en la base de datos.

También comprobaría que el entorno de ensayo no comparte rutas absolutas de escritura con la web original. La documentación de Akeeba trata expresamente los sitios restaurados que siguen modificando el origen por una configuración entrelazada.^[27] Un ensayo de recuperación tiene que demostrar que podemos trabajar sobre la copia sin tocar la instalación que atiende al negocio.

Actualizar con una salida preparada

Priorizaría los fallos explotados y las funciones expuestas que puedan comprometer ejecución, datos o autenticación. Revisaría las dependencias antes de elegir el orden de los paquetes. Una actualización de núcleo puede necesitar una preparación distinta de un parche pequeño de una extensión. Cuando exista una exposición grave, la contención debe reducirla durante el ensayo; dejarla abierta mientras preparamos una migración durante semanas sería una mala forma de organizar la espera.

Descargaría los paquetes desde el proveedor y distinguiría actualización, paquete completo y QuickStart. Conservaría los overrides y cambios propios identificados. Si el sitio necesita un parche específico, documentaría su origen y sus límites. Un archivo modificado a mano puede funcionar hoy y ser sobrescrito en la siguiente actualización, de modo que el mantenimiento posterior también debe saber que existe.

Antes de publicar prepararía cómo volver atrás y qué condiciones lo permitirían. Una restauración completa de una base de datos antigua puede borrar formularios, pedidos, artículos o cuentas creados después de la copia. Si la web continúa recibiendo actividad, hay que coordinar el corte o reconciliar esos datos. «Tenemos backup» no resuelve por sí solo qué ocurre con el pedido que entró cinco minutos después.

Después de instalar comprobaría las versiones efectivas, el esquema de base de datos y las funciones utilizadas. Contrastaría que se conservan los datos y permisos previstos. El ensayo debe cubrir guardar y volver a abrir contenido, subir los archivos admitidos, navegar con una cuenta limitada y probar las integraciones de forma controlada. Un instalador que termina correctamente acredita que terminó; la validación funcional continúa después.

Accesos, permisos y datos guardados

Una parte de las correcciones recientes requiere una cuenta autenticada con determinados permisos. Eso obliga a revisar qué puede hacer cada persona, no solo a contar Super Users. El grupo de Joomla da una referencia, pero los permisos efectivos pueden combinar reglas globales, del componente, de la categoría y del propio contenido. Miraría la operación concreta que debe poder realizar el usuario.

Comprobar el permiso con la cuenta que lo usa

Para alguien que escribe artículos, separaría redactar, editar otros textos, publicar, utilizar el constructor, gestionar archivos y cambiar la configuración. Para una persona que comenta, el alta no debería conceder administración ni moderación. Y para quien mantiene el sitio, utilizaría una cuenta individual con los permisos necesarios y MFA. Compartir una única contraseña de administrador dificulta limitar accesos y averiguar quién hizo un cambio.

OWASP recomienda verificar la autorización en cada petición y aplicar el mínimo privilegio.^[30] En una prueba controlada comprobaría una acción permitida y otra que debe rechazarse con esa identidad. Ocultar el botón ayuda a ordenar la interfaz; el servidor sigue teniendo que denegar la operación. Esto afecta especialmente a gestores de medios, edición de menús, exportaciones y cambios de estado.

Una cuenta de prueba ficticia permite comprobar esos límites sin utilizar a un cliente como conejillo de indias. Al terminar retiraría la muestra y verificaría que sus datos no han quedado mezclados con los reales. También revisaría cuentas antiguas, accesos de proveedores que ya no trabajan en la web y credenciales utilizadas por tareas automáticas. Las cuentas olvidadas tienen una capacidad extraordinaria para sobrevivir a los cambios de empresa.

MFA, sesiones y recuperación de la cuenta

Además de activar MFA, comprobaría el acceso completo, los métodos registrados y la recuperación. Guardaría los códigos de respaldo de forma privada y revisaría quién controla el correo que permite restablecer una contraseña. Si un atacante conserva ese buzón, puede recuperar un acceso que acabamos de cambiar con bastante esfuerzo.

Ante un compromiso revisaría sesiones activas, métodos MFA desconocidos, tokens de API, plugins de autenticación y modificaciones de grupos. Cambiar una contraseña no permite dar por revocados todos los accesos de todos los servicios. El cierre debe comprobar cada mecanismo implicado y, cuando corresponda, invalidar sesiones o revocar tokens desde la función prevista por el producto.^[37]

Los avisos de MFA del núcleo son otro motivo para mantener Joomla actualizado. También revisaría la protección del hosting, el registrador, el correo y la cuenta que administra el DNS. Si se pierde el control de uno de esos servicios, recuperar únicamente la contraseña de Joomla puede dejar al negocio sin control sobre otra parte de la misma web.

Acceso con Google y otras integraciones OAuth

Al incorporar un acceso social comprobaría la vuelta del proveedor, la asociación con la cuenta correcta y los permisos del usuario resultante. En el flujo elegido deben estar implementadas las protecciones adecuadas contra solicitudes falsificadas y repetición, vinculadas a la sesión; OWASP explica el papel de state, PKCE y los controles correspondientes.^[29] Que el botón lleve al logotipo de Google no valida la integración completa.

Probaría un acceso nuevo y un reingreso. Comprobaría que no crea cuentas duplicadas, que los casos inválidos se rechazan y que el usuario conserva un grupo limitado. Revisaría también la política de vinculación de cuentas: compartir una dirección escrita en un formulario no debe bastar para apropiarse de una cuenta existente. La identidad que verifica el proveedor y la decisión de asociación de Joomla requieren una implementación explícita.

Los secretos del cliente y los tokens quedarían fuera del directorio público, del código versionado y de los informes de depuración. En los logs de una prueba no hace falta conservar el código de autorización completo para saber que una respuesta fue rechazada. Registrar el secreto con la intención de depurar la seguridad es una manera especialmente laboriosa de cambiarle de sitio al problema.^[31]

La base de datos también genera la página

Revisaría las cuentas y sus grupos, el registro de extensiones, los estilos de plantilla, los módulos personalizados, los artículos, los menús y las redirecciones. Añadiría perfiles del editor, contenido de Page Builder y parámetros que guardan código o destinos externos. Una referencia a un dominio extraño necesita contexto: puede ser una integración legítima. La comparación con una versión confiable ayuda a decidir qué cambió y quién lo autorizó.

No eliminaría todo el JavaScript que aparezca en una consulta. Hay configuraciones que lo utilizan deliberadamente, y también puede haber código malicioso que no incluya una palabra fácil de buscar. El objetivo es revisar los puntos que pueden generar o ejecutar contenido y relacionarlos con el historial del sitio. Borrar por coincidencia de texto puede estropear una función y conservar la persistencia que no habíamos sabido reconocer.

Comprobaría además qué bases de datos puede consultar el usuario MySQL de Joomla. Si distintas webs comparten una cuenta con permisos sobre varios esquemas, una vulnerabilidad puede ampliar su alcance. Las restricciones de una aplicación no sustituyen los permisos de la base de datos. Para separar proyectos, el proveedor debe revisar tanto usuarios y permisos del sistema de archivos como accesos a datos y copias.

Subidas, WAF y protección del servidor

Las vulnerabilidades de subida han demostrado por qué hace falta controlar tanto la operación que recibe el archivo como el lugar en el que termina. Un formulario que admite únicamente documentos debe validar lo que recibe en el servidor, limitar tamaños y aplicar permisos. Un nombre que termina en .jpg o el tipo enviado por el navegador no bastan para identificar su contenido. OWASP recomienda varias comprobaciones y, cuando sea posible, almacenamiento fuera del directorio público.^[28]

Evitar ejecución en las carpetas de archivos

Pediría que las rutas destinadas a imágenes, adjuntos y descargas no puedan ejecutar los tipos de código que interprete ese servidor. Hay que identificar los manejadores efectivos: PHP y sus variantes de extensión, otras funciones de ejecución y las reglas que puedan heredarse. Bloquear una lista corta de nombres no equivale a retirar todos los mecanismos de ejecución.

La guía anterior incluía fragmentos de .htaccess. Para aplicarlos hay que comprobar servidor, versión, permisos y ubicación. Apache, Nginx y LiteSpeed no utilizan toda su configuración de la misma manera, y un bloqueo en una carpeta equivocada puede impedir el funcionamiento legítimo de una extensión. Por eso aquí priorizo la condición que hay que conseguir y cómo verificarla, en lugar de presentar un fragmento como solución universal.

La prueba debe hacerse en una ubicación controlada con archivos inocuos y una retirada prevista. Comprobaría que el contenido estático sigue sirviéndose y que la petición que debería denegarse no ejecuta código ni entrega secretos. Lo documentaría por ruta y tipo de archivo. No hace falta subir una shell obtenida de Internet para saber si una política de ejecución está funcionando.

También revisaría archivos ocultos, dobles extensiones y cambios de configuración dentro de esas carpetas. Pero un nombre o una fecha inusual son pistas, no una sentencia. Puede haber archivos legítimos del propio componente. Conservaría una copia privada del sospechoso y sus metadatos para compararlo con el paquete original, evitando abrirlo mediante una petición que pueda ejecutarlo.

Permisos y PHP: comprobar el entorno efectivo

Reducir permisos de escritura exige conocer con qué usuario se ejecuta PHP y qué rutas necesita modificar Joomla. No aplicaría un cambio recursivo de permisos a toda la cuenta para después ver qué se rompe. Un directorio de caché con propietario incorrecto puede provocar errores; abrirlo a escritura de cualquiera puede esconder el síntoma y empeorar la exposición.

Con el hosting revisaría la versión de PHP mantenida para la aplicación, la exposición de errores y las restricciones disponibles. Si se utiliza open_basedir, comprobaría qué limita y dónde se aplica; el propio manual de PHP advierte que es una ayuda adicional, no una protección completa.^[34] Las restricciones deben probarse sin convertirlas en un sustituto de la separación entre cuentas.

La configuración de PHP que muestra una consola SSH puede diferir de la que atiende una petición web mediante PHP-FPM o LSAPI. Que una directiva aparezca vacía en CLI no demuestra cómo está configurado el alojamiento de ese dominio. Pediría el dato efectivo del sitio y su método de comprobación. Tampoco dejaría un phpinfo() público para enseñar a cualquier visitante cómo está montada la casa.

Haría lo mismo con las cabeceras de seguridad. Revisaría quién las genera y probaría una política compatible con la web. Una CSP aplicada sin ensayo puede bloquear el editor, el acceso social o un formulario. HTTPS, nosniff y las demás medidas deben configurarse con sus dependencias y comprobarse en la respuesta real; acumular nombres de cabeceras en un informe no arregla una operación vulnerable del servidor.

Una regla WAF tiene que describir su alcance

Cloudflare, ModSecurity o la protección del hosting pueden reducir ataques y aportar eventos para investigar. Revisaría qué está activo, en qué rutas y con qué excepciones. Un producto instalado no acredita que todas sus funciones estén disponibles para la cuenta; tampoco que una petición concreta haya pasado por ellas.

La regla histórica contra asset.uploadCustomIcon solo trataba una operación asociada al problema de SP Page Builder de junio. No cubre las posteriores consultas SQL, los permisos del gestor de medios ni los formularios. Además, una condición basada únicamente en un parámetro visible de la URL tiene límites según cómo se envíe y normalice la petición. Documentaría esos límites en lugar de prometer que el patrón equivale al parche.

Si una función legítima queda bloqueada, buscaría el evento y la regla que intervino. La excepción debería limitarse al caso comprobado: ruta, método, operación y condición que proceda. Desactivar un conjunto entero de protección para que el constructor guarde una página deja sin respuesta demasiadas preguntas. Lo mismo ocurre al bloquear todo com_ajax o todo un componente sin revisar qué utiliza el sitio.

Una contención temporal debe indicar qué riesgo reduce, cómo se ha probado, qué funciones afecta y cuándo se retira. Si no existe una forma fiable de aislar una función vulnerable con datos sensibles, se puede restringir su acceso mientras se corrige. El modo de mantenimiento de Joomla no debe darse por aislamiento completo: hay que comprobar qué rutas siguen atendiendo solicitudes fuera de la portada.

Cloudflare y el acceso directo al origen

La documentación de Cloudflare plantea restringir el tráfico al origen y, según el entorno, autenticar su procedencia.^[32] Para que esa protección tenga efecto, quien administra el servidor debe revisar también sus entradas directas. Un dominio con proxy puede convivir con una dirección de origen que acepta peticiones sin pasar por el WAF.

La política debe contemplar los servicios autorizados y su mantenimiento: rangos del proxy, monitores, validación de certificados y otras conexiones necesarias. No bloquearía puertos a ciegas desde el panel. También comprobaría qué direcciones se consideran proxies de confianza antes de utilizar cabeceras de IP para conceder acceso o excluir una petición del filtrado.

Separar una web crítica de copias abandonadas reduce el alcance de un incidente cuando se hace de forma efectiva. Moverla a otra carpeta bajo el mismo usuario puede mantener los mismos permisos de lectura y escritura. Pediría al proveedor que explique el aislamiento entre cuentas, procesos y bases de datos. La distancia entre dos carpetas en el árbol no es una medida de seguridad especialmente convincente.

Lo que pediría al hosting para investigar

Enviaría el dominio, la extensión y versión afectadas, el periodo de exposición conocido y la zona horaria. Adjuntaría identificadores de eventos y rutas relevantes, con secretos y datos personales retirados de la copia de trabajo. Pediría preservar los registros antes de su rotación y concretar cuáles existen: acceso web, errores, PHP, panel, SSH/SFTP/FTP, correo y WAF.

Sobre una copia de un access.log de texto, esta búsqueda de la guía anterior sirve para localizar algunas referencias. Filtra los componentes que realmente tenga la web; no interpreta el resultado ni sustituye la revisión de los eventos:

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

Una coincidencia indica que esa cadena aparece en el registro. La ausencia de coincidencias tampoco demuestra que no hubo acceso: pueden faltar archivos rotados, peticiones con otros nombres o datos enviados en el cuerpo POST. Conserva el original y evita publicar resultados que contengan información personal o secretos.

También solicitaría el historial de detecciones, cuarentenas y limpiezas, no solo el resultado del último análisis. Imunify distingue funciones como análisis de malware, historial e incidentes; su disponibilidad depende de la configuración y los permisos.^[33] Un resultado limpio hoy responde a una consulta concreta. No reconstruye por sí solo lo que se detectó o borró durante la semana anterior.

Si una pantalla o API devuelve un error de permisos, anotaría «historial no consultado». No lo traduciría por «historial sin incidentes». Preguntaría al proveedor qué puede aportar desde su acceso y qué zonas no cubre su análisis. Una investigación mejora bastante cuando el informe reconoce el dato que falta, por poco vistoso que quede el hueco.

Con una línea temporal se pueden relacionar una petición, una modificación, un acceso al panel y un pico de correo. Un 200 aislado no demuestra ejecución; un 403 puede documentar que ese intento se bloqueó. El cuerpo POST puede no estar en el registro y una respuesta puede variar según ruta, autenticación o agente. Conservaría el resultado exacto y sus condiciones antes de sacar conclusiones.

Recuperación y posible acceso a datos

Si aparecen archivos, usuarios o configuraciones no autorizados, cambiaría la forma de trabajar. La prioridad es contener el daño, conservar evidencia y recuperar desde un estado confiable. Borrar lo que se ve y esperar a que no vuelva a aparecer deja sin comprobar cómo entró y qué capacidad conserva el atacante.

Contener sin perder el estado del incidente

Coordinaría la restricción de acceso desde el servidor, proxy o alojamiento según el alcance. Si el negocio necesita informar a sus clientes, prepararía una página temporal independiente. Evitaría que una restauración todavía vulnerable quede accesible mientras se actualiza. Internet lleva bastante mal lo de conceder un margen de cortesía porque estás buscando la contraseña del panel.

Guardaría archivos y base de datos del estado sospechoso, registros, tareas programadas, configuración y alertas. Documentaría qué se cambia a partir de ese momento y quién lo hace. Las copias con material sospechoso deben quedar privadas y fuera de ejecución. No enviaría a terceros un archivo de configuración completo para que «le echen un vistazo», ni un volcado con información de clientes para comprobar una coincidencia de texto.

Intentaría establecer la primera actividad conocida y sus límites. La fecha del aviso al cliente puede ser posterior a la intrusión. Una modificación de archivo orienta, pero se puede alterar y también puede deberse a una actualización legítima. Cruzaría fechas con logs, versiones instaladas, copias y cambios autorizados. Cuando no se pueda precisar el inicio, mantendría un intervalo razonado y explicaría la incertidumbre.

Reconstruir con paquetes confiables y datos revisados

Prepararía archivos y base de datos en un destino limpio, separado del sitio comprometido. Utilizaría paquetes oficiales y una copia anterior al incidente cuando exista y se pueda contrastar. Si no hay una copia confiable, reconstruiría el código y recuperaría el contenido revisado. Reinstalar únicamente el núcleo deja fuera los archivos añadidos y las modificaciones de extensiones, plantillas y configuración.

Compararía también overrides, módulos y personalizaciones con sus fuentes conocidas. No todo archivo ajeno al paquete oficial es malicioso: puede contener trabajo propio. Y no todo archivo con nombre oficial conserva el código original. La revisión necesita ambas referencias y una decisión documentada sobre lo que se recupera.

Los datos recientes requieren un tratamiento específico. Pedidos, reservas, formularios, artículos y cuentas pueden haberse creado después de la copia elegida. Identificaría qué debe conservarse y lo trasladaría de forma selectiva, comprobando relaciones y consistencia. Una importación completa de la base comprometida puede volver a introducir usuarios, parámetros o tareas que pretendíamos retirar.

Antes de volver al servicio público verificaría los paquetes corregidos y las funciones necesarias. Si el corte debe hacerse por fases, cada fase necesita un estado recuperable y un registro. Probaría también la vuelta atrás en el entorno separado. El momento de descubrir que el respaldo omite media biblioteca de imágenes debería llegar durante el ensayo, preferiblemente con café y sin un cliente esperando al teléfono.

Buscar persistencia en archivos y configuración

Además de imágenes, medios y temporales, revisaría componentes, plugins, módulos, plantillas, cachés y ubicaciones escribibles de esa instalación. Comprobaría los archivos de configuración del servidor, incluidas reglas de .htaccess, configuraciones por directorio y tareas cron. Añadiría el planificador de Joomla y las tareas de extensiones que puedan recrear archivos o lanzar conexiones.

En la base de datos volvería a revisar los puntos que generan contenido o conceden acceso. Una redirección puede depender del origen de la visita; un script puede estar en un parámetro de plantilla; una cuenta puede utilizar un plugin de autenticación inesperado. La revisión debe comprobar cómo se comporta la página para un visitante y para las identidades implicadas, no solo cómo se ve mientras está conectado el administrador.

Incluiría otras webs accesibles desde la cuenta. Una copia antigua en un subdirectorio, una instalación de pruebas olvidada o un WordPress abandonado pueden mantener una entrada. Si no se puede confiar en el alojamiento o se detecta una afectación más amplia, el proveedor debe participar en la recuperación. Limpiar la carpeta del dominio principal no permite concluir que toda la cuenta esté resuelta.

Rotar credenciales con un orden que mantenga el control

Desde un equipo confiable revisaría los accesos del hosting, correo, dominio y aplicación. La selección depende de lo que pudo quedar expuesto: contraseñas privilegiadas, cuentas de base de datos, claves SSH, tokens, SMTP, APIs, pagos y sistemas de copia. Una credencial accesible al atacante debe dejar de servir; también hay que revisar las sesiones o autorizaciones que puedan sobrevivir a su sustitución.^[37]

Prepararía la actualización de las integraciones que dependan del secreto y comprobaría después su funcionamiento. Cambiar la contraseña de base de datos sin actualizar la aplicación puede dejar la web fuera de servicio. Cambiarla únicamente dentro de una instalación todavía controlada por el atacante puede entregarle la nueva. La contención y la recuperación deben permitir hacer esa rotación sobre un entorno que podamos administrar con confianza.

Revisaría métodos de recuperación, cuentas alternativas y accesos de terceros. Un administrador nuevo, una regla de correo o una clave añadida pueden conservar capacidad de entrada aunque hayamos cambiado la contraseña principal. Registraría la revocación realizada y su comprobación sin copiar el secreto en el informe. «Clave renovada y acceso anterior revocado» es un dato; la clave completa es un problema distinto.

Una posible lectura de datos necesita su propia investigación

Cuando el fallo permite consultar datos, determinaría qué podía alcanzar la operación vulnerable y con qué permisos. Incluiría información de usuarios, formularios, reservas, pedidos, documentos, configuraciones e integraciones, según la instalación. La presencia de una SQL injection no permite afirmar que se extrajo toda la base; tampoco permite descartar una lectura porque no haya cambiado un archivo.

Evaluaría los registros disponibles, el periodo de exposición y los indicadores de uso. Si no hay evidencia suficiente para determinar qué se leyó, lo dejaría expresado y decidiría medidas proporcionales al riesgo. Entre ellas puede estar invalidar sesiones, sustituir secretos o exigir renovación de contraseñas. Los hashes de contraseña tienen protecciones propias, pero su posible exposición también debe valorarse con el resto del acceso, el algoritmo y la reutilización de credenciales.

Si hay datos personales, involucraría al responsable del tratamiento y a quien lleve protección de datos. La AEPD explica que la notificación a la autoridad debe hacerse cuando proceda por el riesgo, sin dilación indebida y, de ser posible, dentro de las 72 horas desde que se tiene constancia de la brecha. La comunicación a las personas afectadas se valora por el alto riesgo; no es el mismo trámite ni tiene automáticamente ese mismo plazo.^[35]

La decisión debe documentarse, incluida la razón para notificar o para no hacerlo. No esperaría a terminar un rediseño para evaluar una brecha, ni convertiría cualquier aviso de versión vulnerable en una obligación automática de avisar a todos los clientes. La investigación técnica debe aportar hechos, límites y medidas para que esa decisión se tome con la información disponible.

SEO, correo y comprobación final

Una recuperación termina devolviendo al negocio una web que se puede utilizar y mantener. Hay que comprobar las funciones por las que alguien la visita: encontrar información, enviar una consulta, reservar, comprar o acceder a su cuenta. Quitar el malware y dejar el formulario bloqueado por una regla demasiado amplia puede resolver una parte del incidente y conservar el teléfono muy tranquilo durante bastante tiempo.

Search Console y las URLs que dejó el ataque

En Search Console revisaría Problemas de seguridad y Acciones manuales, además de los propietarios, usuarios y métodos de verificación. Buscaría cambios de sitemaps, páginas ajenas al negocio, redirecciones y destinos alterados. El informe de seguridad ofrece ejemplos y un procedimiento de revisión; Google advierte que sus ejemplos no tienen por qué representar todas las páginas afectadas.^[36]

Para las URLs creadas por el atacante decidiría la respuesta según su contenido y su función. Una página de spam que debe desaparecer puede requerir un 404 o 410; una página legítima eliminada durante el incidente puede necesitar recuperación. No redirigiría todas las URLs desconocidas a la portada por comodidad. Tampoco bloquearía el rastreo de forma que impida a Google observar la respuesta que necesitamos que vuelva a comprobar.

Revisaría los sitemaps enviados, las canónicas, el marcado, los títulos y los enlaces de las páginas comerciales. Si alguien añadió una verificación de propiedad, retirarla exige comprobar el método correspondiente y los permisos que siguen vigentes. Cambiar únicamente la contraseña de la cuenta que usabas para entrar no elimina necesariamente otro método de verificación.^[36]

Después contrastaría clics e impresiones por páginas y consultas con las fechas del incidente y de la recuperación. La guía para interpretar clics, impresiones y CTR en Search Console ayuda a separar esas medidas. Una búsqueda con site: puede aportar pistas, pero no la trataría como un inventario completo de lo que Google conoce.

Si hubo una advertencia de seguridad, pediría su revisión cuando se haya resuelto el problema y explicaría los cambios. La retirada temporal de resultados no sustituye la reparación de las páginas. Y enviar un sitemap o solicitar indexación no acredita que Google haya procesado la recuperación. En los informes separaría lo enviado, lo aceptado y el estado que se observa después.

También evitaría atribuir cualquier pérdida al último update de Google. Antes comprobaría si hay un bloqueo nuevo, una redirección, una página retirada o un fallo de medición. El recopilatorio de cambios de Google desde el core update de mayo ofrece el contexto del buscador; el historial de la propia web tiene que acompañarlo. Mountain View ya tiene bastante trabajo como para responsabilizarse también de nuestro archivo de configuración.

Correo y pedidos: contrastar el resultado fuera de Joomla

Si la exposición incluía formularios o un posible relay de correo, pediría registros SMTP y comprobaría actividad, destinatarios desconocidos, rebotes, límites y alertas del proveedor. Revisaría las credenciales y su posible exposición, además de SPF, DKIM y DMARC cuando corresponda. Esos mecanismos de autenticación del dominio no corrigen una función de la web que permite abusar del envío.

Para un formulario que debe seguir funcionando, comprobaría recepción y destino de la respuesta, además del mensaje que ve el visitante. La captura de «enviado correctamente» no prueba que el mensaje llegase al buzón. En el ensayo utilizaría datos y destinatarios controlados; una prueba real posterior debe tener un alcance claro y evitar mensajes a clientes o campañas involuntarias.

En una tienda contrastaría los pedidos con el proveedor de pagos: importe, moneda, identificador de operación, fecha y estado. Un registro marcado como pagado dentro del gestor no acredita por sí solo un cobro. Si se sospecha manipulación, revisaría los cambios y evitaría corregir estados en bloque sin reconciliar la información. Las facturas y la información de clientes requieren además valorar quién pudo consultarlas.

Para reservas o solicitudes haría una comprobación equivalente: qué se recibió, qué se confirmó y qué necesita recuperar el negocio. La analítica de un clic para contactar describe una intención. Una conversación recibida, una consulta atendida y una reserva confirmada requieren evidencias distintas. Un incidente de seguridad tampoco debería servir para sumar todas esas cosas bajo la misma cifra.

Qué evidencia dejaría para cerrar la incidencia

El cierre incluiría una relación de versiones y correcciones aplicadas, las vías de acceso revisadas, los archivos y configuraciones recuperados, las credenciales revocadas y las funciones comprobadas. Dejaría constancia de los datos conservados y de cualquier reconciliación. El informe también debe indicar sus límites: registros que faltan, componentes sin comprobar o dudas sobre el alcance de una lectura.

La monitorización posterior debería avisar de nuevos administradores, cambios sensibles, archivos inesperados, tareas desconocidas o picos de correo, según el sitio. Las alertas tienen que llegar a alguien que pueda revisarlas. Un panel que lleva meses acumulando avisos sin destinatario ofrece una tranquilidad bastante particular: la de no enterarse de nada.

También dejaría claro quién mantiene cada parte: núcleo, extensiones, servidor, copias y servicios externos. En una web pequeña puede ser la misma persona; en otra pueden intervenir varios proveedores. Lo necesario es que cada tarea tenga un responsable y que el negocio pueda consultar el registro de cambios y recuperar sus accesos.

Si necesitas que revise una instalación, puedes contarme qué versión de Joomla utiliza, qué extensiones tiene y qué has observado. No envíes contraseñas, tokens ni copias completas mediante el formulario. Para empezar, una versión, una fecha y el síntoma permiten plantear una revisión sin repartir las llaves por el camino.

Mi objetivo al actualizar esta guía es poder responder qué se corrigió, qué se comprobó y qué sigue sin saberse. Hay instalaciones que necesitan un parche, otras una migración y algunas una recuperación completa. Para decidirlo hace falta revisar su estado. El siguiente aviso de seguridad llegará cuando llegue; mientras tanto, podemos dejar de confiar toda la seguridad al color del último mensaje del panel.