Introducción
Core-Admin incorpora una infraestructura de reglas de mitigación de amenazas conocidas (threat rules), un mecanismo de tipo WAF que bloquea en el servidor web las llamadas asociadas a vulnerabilidades críticas de aplicaciones como WordPress o Joomla, antes de que lleguen a la aplicación.
Estas reglas se aplican de forma transparente a todos los alojamientos activos del servidor y se distribuyen y activan automáticamente con las actualizaciones de Core-Admin, sin necesidad de intervención por alojamiento. Cuando una petición coincide con la firma de un ataque conocido, el servidor responde con un 403 Forbidden y la petición nunca alcanza el CMS.
Es importante subrayar que estas reglas son una medida de contención adicional (defensa en profundidad): reducen la ventana de exposición y frenan el escaneo/explotación masiva, pero no sustituyen a la actualización de WordPress, Joomla y sus extensiones a las versiones corregidas.
Vulnerabilidades mitigadas
Actualmente se aplican mitigaciones para las siguientes vulnerabilidades, todas ellas de gravedad alta o crítica y con explotación activa observada:
| CVE(s) | Aplicación afectada | Qué se bloquea |
|---|---|---|
| CVE-2026-63030 y CVE-2026-60137 (wp2shell) | WordPress (core) | RCE no autenticada a través de la ruta batch de la API REST. Se bloquean ambas formas de la ruta: /wp-json/batch/v1 y ?rest_route=/batch/v1. |
| CVE-2026-48908 | Joomla — SP Page Builder (JoomShaper) | Subida de fichero arbitraria no autenticada que permite dejar una webshell. Se bloquea la llamada a la tarea asset.uploadCustomIcon del componente. |
| CVE-2026-49049 | Joomla — Helix3 (JoomShaper) | Escritura/borrado de ficheros y sobrescritura de plantilla sin autenticación a través del manejador AJAX de la plantilla. Se bloquea la llamada al handler com_ajax de helix3. |
Puedes consultar en cualquier momento las reglas aplicadas en un servidor con:
crad-webhosting-mgr.pyc --list-threat-rules
Salida de ejemplo:
Id Active Date Label CVEs Scope URI match Query match Code
-- ------ ---- ----- ---- ----- --------- ----------- ----
1 |[*] |2026-07-24 |wp2shell |CVE-2026-63030, CVE-2026-60137 |all |^/wp-json/batch/v1 |(^|&)rest_route=/batch/v1 |403
2 |[*] |2026-07-24 |sppagebuilder-uploadicon |CVE-2026-48908 |all | |(?=.*option=com_sppagebuilder)(?=.*task=asset\.uploadCustomIcon) |403
3 |[*] |2026-07-24 |helix3-ajax |CVE-2026-49049 |all | |(?=.*option=com_ajax)(?=.*plugin=helix3) |403
La columna Active ([*]) indica que la regla está activa, Scope all que se aplica a todos los alojamientos y Code 403 la respuesta que devuelve el servidor cuando bloquea una petición.
Cómo comprobar que la protección está activa
Puedes verificar el bloqueo con curl contra un dominio del servidor. Con --resolve fuerzas que la petición se resuelva contra el propio nodo, y -w "%{http_code}" imprime el código de respuesta. Una respuesta 403 significa que la petición ha sido bloqueada correctamente.
Sustituye $DOMINIO por un dominio real alojado en el servidor:
DOMINIO=midominio.com
wp2shell — por ruta y por query (ambas formas):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "wp2shell path : %{http_code}\n" "https://$DOMINIO/wp-json/batch/v1"
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "wp2shell query: %{http_code}\n" "https://$DOMINIO/?rest_route=/batch/v1"
SP Page Builder (CVE-2026-48908):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "sppagebuilder: %{http_code}\n" "https://$DOMINIO/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon"
Helix3 (CVE-2026-49049):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "helix3: %{http_code}\n" "https://$DOMINIO/index.php?option=com_ajax&plugin=helix3"
Nota: las reglas bloquean por la ruta o los parámetros de la petición, con independencia del método HTTP, por lo que un simple
GETconcurlya dispara el403; no hace falta reproducir el POST del exploit. Si pruebas por HTTP (puerto 80), cambia:443:por:80:yhttpsporhttp.
Gestión de las reglas (listar, activar, desactivar)
La gestión del día a día se reduce a tres operaciones, todas desde crad-webhosting-mgr.pyc:
Listar las reglas registradas y su estado:
crad-webhosting-mgr.pyc --list-threat-rules
Desactivar una regla concreta (por su Id, sin eliminarla):
crad-webhosting-mgr.pyc --disable-threat-rule=<id>
Reactivar una regla previamente desactivada:
crad-webhosting-mgr.pyc --enable-threat-rule=<id>
Al activar o desactivar una regla, Core-Admin regenera y recarga automáticamente la configuración del servidor web, por lo que el cambio surte efecto de inmediato.
¿Cuándo desactivar una regla?
En algunos casos, una regla puede interferir con un uso legítimo de una aplicación. El ejemplo típico es la regla de Helix3: bloquea el manejador AJAX de la plantilla, que también puede utilizarse de forma legítima al editar la configuración de una plantilla Helix3. Si detectas que un sitio con plantilla Helix3 legítima tiene problemas de edición, puedes desactivar esa regla en ese servidor con --disable-threat-rule=<id>.
El estado de activación es local a cada servidor y se respeta: una regla que desactives no se volverá a activar sola en las siguientes actualizaciones ni sincronizaciones del catálogo.
Recomendación: desactivar una regla debe ser la excepción y una medida temporal. La solución definitiva siempre es actualizar el CMS y las extensiones afectadas a la versión corregida.
Distribución y actualización automática
Las reglas de amenazas conocidas viajan con Core-Admin: se incorporan al catálogo del producto y se instalan y aplican de forma automática en cada servidor durante el proceso de actualización habitual. Cuando se publica una regla nueva para un CVE reciente, los servidores la reciben y la aplican por sí solos en su siguiente ciclo de actualización, sin ninguna acción manual.
Esto permite que toda la plataforma quede protegida frente a una amenaza recién divulgada en cuestión de horas, mientras los administradores planifican la actualización de las aplicaciones afectadas.
Preguntas frecuentes
¿Estas reglas ralentizan el servidor web?
No de forma apreciable. Son comprobaciones ligeras sobre la ruta y los parámetros de la petición, integradas en la misma configuración que ya usa Core-Admin para el bloqueo de bots.
¿Afectan a sitios que no usan la aplicación vulnerable?
No. Un sitio que no reciba esas rutas/parámetros nunca activa la regla; para él son transparentes.
Si actualizo WordPress/Joomla, ¿tengo que quitar las reglas?
No es necesario. Una vez actualizada la aplicación dejas de ser vulnerable, y la regla simplemente no vuelve a activarse en el tráfico normal. Puede permanecer como capa adicional de contención frente a reintentos de escaneo.
¿Puedo registrar mis propias reglas?
Sí. Existen opciones adicionales de administración avanzada para registrar reglas propias y forzar la sincronización del catálogo. Quedan fuera del alcance de este artículo, centrado en el uso habitual (consulta, activación y desactivación).
Para cualquier duda o si observas un falso positivo con alguna de estas reglas, contacta con el equipo de soporte.