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. |
| CVE-2026-119977 | WordPress (core) | Condición de carrera del actualizador: mientras se aplica una actualización completa del núcleo, la nueva versión se descomprime en una carpeta predecible y accesible por web (wp-content/upgrade/...), y un atacante sin autenticar puede ejecutar el instalador setup-config.php de esa copia para apoderarse del sitio. WordPress nunca sirve esa carpeta por HTTP, así que se bloquea todo wp-content/upgrade/. La regla debe seguir activa tras actualizar: la primera actualización a la versión corregida la realiza todavía el actualizador antiguo, vulnerable. |
| CVE-2026-114432 | WordPress — Contact Form 7 (6.2 a 6.2.3) | Subida de fichero arbitraria sin autenticar a través de un campo de fichero del formulario, que queda olvidado en wp-content/uploads/wpcf7_uploads/. La subida viaja en el cuerpo de la petición y no se puede filtrar por ruta, así que se bloquea el segundo paso: cualquier acceso web a wpcf7_uploads/, carpeta que Contact Form 7 nunca sirve por HTTP. La configuración por defecto de Core-Admin ya impide la ejecución, pero un .htaccess mal configurado (del usuario, de un plugin o de un atacante) podría habilitarla; esta regla se aplica antes que cualquier .htaccess y no puede ser anulada por él. La solución definitiva es actualizar a la 6.2.4 o superior. |
| CVE-2026-115252 | WordPress — Confection WordPress Cable (0.4.0 a 0.4.7) | Ejecución remota de código sin autenticar: cualquiera puede guardar los ajustes del plugin a través de admin-ajax.php o admin-post.php, y el valor guardado acaba escrito sin escapar en un fichero PHP del plugin. El guardado solo se produce si la URL lleva page=confection-options-page, así que se bloquea cualquier petición con ese valor, también codificado (%HH). Efecto secundario: la propia página de ajustes del plugin en el escritorio de WordPress queda bloqueada. El plugin está retirado de wordpress.org y no hay versión corregida: la solución es desinstalarlo. |
| CVE-2026-87902 | WordPress (core), corregido en 7.1.2 y versiones equivalentes de ramas anteriores | Recorrido de rutas sin autenticar al resolver la plantilla de página: un nombre de página manipulado (pagename) con secuencias ../ permite incluir cualquier fichero .php legible del servidor, lo que puede acabar en ejecución de código. Se bloquean las secuencias ../ (también codificadas) en la ruta de la URL y, en la query, junto al parámetro pagename, además de cualquier referencia a pearcmd. Si el parámetro se envía en el cuerpo de un POST, la regla no puede verlo: la solución definitiva es mantener WordPress actualizado (las actualizaciones de seguridad menores se aplican solas por defecto). |
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
4 |[*] |2026-11-09 |wp-upgrade-staging |CVE-2026-119977 |all |/wp-content/upgrade(/|$) | |403
5 |[*] |2026-11-09 |cf7-wpcf7-uploads |CVE-2026-114432 |all |/wp-content/uploads/wpcf7_uploads(/|$) | |403
6 |[*] |2026-11-09 |confection-options |CVE-2026-115252 |all | |(?i)(c|%63)(o|%6f)(n|%6e)(f|%66)(e|%65)...(e|%65) |403
7 |[*] |2026-11-09 |wp-pagename-traversal |CVE-2026-87902 |all |(?i)(\.|%2e)(\.|%2e)(/|%2f) |(?i)(?=.*(p|%70)(a|%61)...(d|%64) |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"
Actualizador de WordPress (CVE-2026-119977) — la carpeta y el instalador de la copia temporal (no hace falta que existan):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "wp-upgrade dir : %{http_code}\n" "https://$DOMINIO/wp-content/upgrade/"
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "wp-upgrade setup : %{http_code}\n" "https://$DOMINIO/wp-content/upgrade/wordpress-7.1.3/wordpress/wp-admin/setup-config.php?step=2"
Contact Form 7 (CVE-2026-114432):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "cf7 uploads: %{http_code}\n" "https://$DOMINIO/wp-content/uploads/wpcf7_uploads/0123456789/shell.phar"
Confection (CVE-2026-115252) — en claro y codificado:
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "confection : %{http_code}\n" "https://$DOMINIO/wp-admin/admin-post.php?page=confection-options-page"
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "confection enc: %{http_code}\n" "https://$DOMINIO/wp-admin/admin-ajax.php?page=confection%2Doptions%2Dpage"
Plantillas de página de WordPress (CVE-2026-87902) — por query, doblemente codificado y por ruta (--path-as-is evita que curl elimine los ..):
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "pagename query : %{http_code}\n" "https://$DOMINIO/?pagename=templates/../../../../x"
curl -sk --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "pagename dblenc: %{http_code}\n" "https://$DOMINIO/?pagename=templates/%252e%252e/%252e%252e/x"
curl -sk --path-as-is --resolve $DOMINIO:443:127.0.0.1 -o /dev/null -w "pagename path : %{http_code}\n" "https://$DOMINIO/templates/%2e%2e/%2e%2e/x"
La tercera puede devolver 400 o 404 en lugar de 403 si Apache normaliza la ruta antes de aplicar las reglas: en ese caso la petición tampoco llega a WordPress.
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.