Hardening WordPress: servidor, login, plugins y cabeceras

#Vectores de ataque más comunes contra WordPress en 2026

El ecosistema WordPress enfrenta un perfil de amenazas fundamentalmente diferente al de hace apenas dos años. Según el informe anual de Patchstack de 2025, el 97% de las vulnerabilidades de WordPress se originaron en plugins y temas, no en el núcleo de WordPress. El software base ha madurado significativamente, pero el ecosistema a su alrededor permanece como el vector de ataque principal.

Lo que realmente cambió en el panorama de amenazas en 2026:

• Los ataques a la cadena de suministro contra los mecanismos de actualización de plugins van en aumento, aunque ningún conjunto de datos público cifra el cambio interanual
• Ataques impulsados por IA ahora generan emails de phishing contextualmente relevantes dirigidos a administradores WordPress en su idioma nativo
• La ventana de exploit zero-day se sigue estrechando, pero el repetido “menos de 48 horas” no tiene ningún conjunto de datos detrás

Los vectores de ataque se han desplazado hacia cadenas de suministro de plugins, abuso de REST API, vulnerabilidades de deserialización en capas de caché de objetos y secuestro de sesiones a través de cookies de autenticación mal configuradas. Las medidas de seguridad tradicionales siguen siendo necesarias pero insuficientes por sí solas.

#Hardening del servidor para WordPress

El servidor es tu primera línea de defensa. Ninguna cantidad de seguridad a nivel de WordPress compensa un servidor mal configurado.

#Versión crítica de seguridad de PHP el 21 de octubre de 2026

Situación tras la publicación, 21 de octubre de 2026. El equipo de PHP ha publicado PHP 8.5.12, 8.4.27, 8.3.36 y 8.2.35. Estas versiones corrigen dos vulnerabilidades críticas: CVE-2026-109618 (GHSA-w8hw-w9fx-j79w) y CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). Según php.net, ambas pueden permitir la ejecución remota de código sin autenticación. La publicación llegó antes de la hora anunciada, las 14:00 UTC: los dos avisos en GitHub tienen hora de publicación 13:34 UTC (15:34 en la España peninsular). Los avisos dan como afectados los rangos < 8.2.35, < 8.3.36, < 8.4.27 y < 8.5.12.

php.net considera en riesgo cualquier instalación de PHP que atienda peticiones web, incluidos PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP y LiteSpeed. El riesgo más alto, según php.net, está en mod_php: el ataque demostrado allí funciona con una petición sin autenticación antes de que se ejecute ningún código de la aplicación, es decir, antes de que carguen WordPress y sus plugins.

PHP es software de servidor y no forma parte de WordPress, así que las actualizaciones automáticas del núcleo, los plugins y los temas no lo cambian. Según WordPress.org, no hace falta ni está prevista ninguna actualización de WordPress (WordPress.org). Qué hacer:

• Comprueba la versión de PHP en el escritorio (Herramientas > Salud del sitio > Información > Servidor) o con php -v en el servidor. La línea de comandos y PHP-FPM pueden usar versiones distintas, y Salud del sitio muestra la que usa la web. La corrección está en 8.5.12, 8.4.27, 8.3.36, 8.2.35 y versiones posteriores de cada rama. Son los números de versión de php.net. Las distribuciones Linux aplican la corrección en paquetes con número propio: Ubuntu 24.04, por ejemplo, corrigió PHP con el paquete 8.3.6-0ubuntu0.24.04.13 (USN-8948-1), así que Salud del sitio muestra 8.3.6. Con PHP de una distribución, consulta el aviso de seguridad de la distribución o el registro de cambios del paquete y, en un hosting, pregunta a tu empresa de hosting.
• Averigua quién actualiza PHP. En alojamiento compartido y gestionado lo hace el proveedor; en un VPS o servidor dedicado, tú o tu programador. php.net indica que las distribuciones Linux y los proveedores de soporte LTS recibieron los parches por adelantado, así que consulta a tu proveedor por los paquetes actualizados. Los paneles de alojamiento y las imágenes de contenedores pueden recibir la corrección más tarde. Si instalas PHP desde el repositorio rpms.remirepo.net, php.net recomienda pasar a los paquetes de la distribución o compilar desde el código fuente, porque ese repositorio no tendrá actualizaciones el día de la publicación.
• Antes de tocar el servidor, haz copia de los archivos y de la base de datos y comprueba que se puede restaurar. Después de actualizar, comprueba en Salud del sitio que la web ya funciona con la nueva versión.
• Según la lista de versiones con soporte de php.net, reciben correcciones de seguridad las ramas 8.2 (hasta el 31 de diciembre de 2026), 8.3, 8.4 y 8.5. PHP 8.1 y anteriores no tienen nueva versión del proyecto PHP. El equipo de seguridad de PHP publicó correcciones mínimas de código fuente para 7.4, 8.0 y 8.1 para quien compila PHP por su cuenta, y algunas distribuciones y proveedores LTS ofrecen correcciones propias. Si tu web funciona con alguna de estas versiones, pide una corrección a tu proveedor o pasa a una versión con soporte después de probarla en una copia de staging.

Los pasos para el propietario del sitio, desde comprobar la versión de PHP hasta qué preguntar al proveedor de alojamiento, están en qué hacer con PHP2Shell en un sitio WordPress.

Si no puedes actualizar hoy, php.net indica medidas temporales. Reducen el riesgo en vías de ataque concretas, pero según php.net no hacen segura la instalación: “No hay mitigaciones completas, actualizar es la única opción segura” (php.net, traducción propia). En un alojamiento compartido normalmente no puedes cambiar estos ajustes tú mismo, así que la lista es para el administrador del servidor o para preguntar a tu proveedor:

• session.upload_progress.enabled=0 en php.ini, en un pool de FPM o en una configuración del servidor que se aplique antes de analizar la petición, y después reinicia todos los procesos de PHP. ini_set() (es decir, una línea en wp-config.php o en un plugin) y un archivo .user.ini de FPM no sirven aquí. Esto bloquea las vías confirmadas a través de sesiones, pero no otras variantes (CVE-2026-109619).
• En PHP 8.5, además, fatal_error_backtraces=0 y reinicio de todos los procesos. Esto bloquea solo la vía confirmada a través de la traza de errores fatales.
• memory_limit=-1, fijado de forma que las aplicaciones no puedan cambiarlo, por ejemplo con php_admin_value en el pool de FPM o en la configuración de Apache. Comprueba que ningún pool, directorio o ajuste de la aplicación vuelva a poner un límite finito. php.net advierte que un fallo de asignación de memoria a más bajo nivel todavía puede llegar a la vía vulnerable (CVE-2026-109618).
• Un post_max_size bajo: 8M si la web no acepta archivos, 32M si los acepta (una web WordPress con biblioteca de medios suele aceptarlos). upload_max_filesize debe quedar por debajo de post_max_size.
• Límites en el servidor web o el proxy para el tamaño de la petición decodificada, el número de campos del formulario, de partes multipart y de cabeceras y la profundidad de anidamiento, también para peticiones sin una cabecera Content-Length utilizable.
• Un límite de memoria del contenedor o del cgroup como frontera de disponibilidad, a ser posible uno que termine solo el proceso afectado. No uses RLIMIT_AS ni RLIMIT_DATA en su lugar, porque pueden provocar ellos mismos el fallo de asignación vulnerable.
• Elimina ajustes de PHP no válidos u obsoletos aplicados en cada petición que generen avisos antes de la inicialización. En mod_php, el aviso GHSA-6wmf-4rv5-p3rp menciona aquí las directivas php_value y php_flag de .htaccess. Ocultar los avisos con error_reporting, display_errors o @ no ayuda. Ejemplo nuestro, no de php.net: desde PHP 8.3 todos los ajustes INI assert.* están obsoletos, así que en PHP 8.3 y versiones posteriores revisa .htaccess, los pools de FPM y php.ini en busca de entradas assert.* que hayan quedado, por ejemplo php_value assert.active.
• Corrige los errores fatales y los tiempos de ejecución agotados que pueda provocar un atacante, también en funciones de retorno, en la subida y la importación de archivos y en la limpieza tras la petición.

El 21 de octubre de 2026, Wiz Research publicó sus conclusiones. Según Calif, los fallos los descubrieron Calif, OpenAI y Wiz. Además de la ejecución remota de código, uno de los fallos permite leer sin autenticación memoria de un proceso de trabajo de PHP: PHP la devuelve codificada como URL en una cookie PHPSESSID de la respuesta, incluso cuando la aplicación nunca llama a session_start(). Según Wiz, esa memoria “puede contener contraseñas, tokens de autenticación, claves de API y certificados que pertenecen a otras peticiones o al propio servidor” (Wiz Research, traducción propia). Wiz afirma también que todas las versiones de PHP publicadas en la última década tienen al menos uno de estos fallos, hasta PHP 5.4 (los avisos de php.net no indican límite inferior), y que demostró ejecución de código sin autenticación en la imagen de contenedor wordpress:latest. Existen otras variantes, y solo el parche de PHP las corrige todas.

Esta es nuestra recomendación, no la de Wiz: si la web atendió peticiones con una versión de PHP sin parchear, después de actualizar plantéate cambiar los secretos que viven en la memoria de PHP, porque Wiz dice que la fuga puede exponerlos:

• Las claves y las sales de wp-config.php. El generador oficial de WordPress.org da valores nuevos, y el cambio cierra la sesión de todos los usuarios.
• La contraseña de la base de datos (DB_PASSWORD). Cámbiala primero en el servidor de la base de datos y después en wp-config.php.
• Las claves de API de las integraciones de pago y de correo. Genéralas de nuevo en la cuenta de cada proveedor.

Para quien lee los registros del servidor, Wiz señala tres indicios: “peticiones multipart inusuales seguidas de errores de límite de memoria o de respuestas HTTP 500 repetidas, cookies PHPSESSID de respuesta inesperadamente grandes o malformadas y una rotación inexplicada de procesos de trabajo de PHP” (Wiz Research, traducción propia). Los fallos actúan por debajo de la capa de aplicación, así que los registros de WordPress pueden tener poco contexto.

#Ajustes seguros de php.ini para WordPress

WordPress requiere PHP, pero la configuración predeterminada de PHP es permisiva. Refuérzala en php.ini o la configuración por sitio:

; Deshabilitar funciones peligrosas
disable_functions = exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,eval

; Ocultar versión PHP
expose_php = Off

; Restringir acceso a archivos
open_basedir = /var/www/tusitio:/tmp
doc_root = /var/www/tusitio

; Seguridad de sesión
session.cookie_httponly = 1
session.cookie_secure = 1
session.cookie_samesite = Strict
session.use_strict_mode = 1

; Límites de subida (restringir a lo que el sitio realmente necesita)
upload_max_filesize = 10M
post_max_size = 12M
max_execution_time = 30
max_input_time = 30
memory_limit = 256M

; Manejo de errores (nunca mostrar errores en producción)
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

#Permisos de archivos en WordPress

Los permisos de archivos incorrectos son una de las malas configuraciones más comunes a nivel de servidor:

# Archivos: legibles por propietario y grupo, no world-writable
find /var/www/tusitio -type f -exec chmod 644 {} \;

# Directorios: ejecutables por propietario y grupo
find /var/www/tusitio -type d -exec chmod 755 {} \;

# wp-config.php: restrictivo - solo lectura por propietario
chmod 400 /var/www/tusitio/wp-config.php

# .htaccess: lectura/escritura solo por propietario
chmod 644 /var/www/tusitio/.htaccess

# wp-content/uploads: escribible por el servidor web
chown -R www-data:www-data /var/www/tusitio/wp-content/uploads

#SSH y control de acceso

• Deshabilita la autenticación SSH por contraseña completamente. Usa pares de claves SSH con un mínimo de RSA de 4096 bits o Ed25519.
• Cambia el puerto SSH predeterminado de 22 a un puerto no estándar.
• Implementa fail2ban para bloquear intentos SSH fallidos repetidos.
• Usa un bastion host o VPN para acceder a servidores de producción - nunca expongas SSH directamente a internet.
• Deshabilita el login root vía SSH. Usa un usuario de deployment dedicado con privilegios sudo.

# /etc/ssh/sshd_config
PasswordAuthentication no
PermitRootLogin no
Port 2222
MaxAuthTries 3
AllowUsers deploy-user

#Cómo proteger wp-config.php, XML-RPC y la REST API

#Ajustes seguros en wp-config.php

El archivo wp-config.php es el archivo más sensible en una instalación WordPress. Muévelo un directorio por encima de la raíz web e implementa estas configuraciones:

<?php
// Claves de seguridad y salts - generar valores frescos
// https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY',         'frase-única-aqui');
define('SECURE_AUTH_KEY',  'frase-única-aqui');
define('LOGGED_IN_KEY',    'frase-única-aqui');
define('NONCE_KEY',        'frase-única-aqui');
define('AUTH_SALT',        'frase-única-aqui');
define('SECURE_AUTH_SALT', 'frase-única-aqui');
define('LOGGED_IN_SALT',   'frase-única-aqui');
define('NONCE_SALT',       'frase-única-aqui');

// Forzar SSL para admin y logins
define('FORCE_SSL_ADMIN', true);
define('FORCE_SSL_LOGIN', true);

// Deshabilitar edición de archivos en admin
define('DISALLOW_FILE_EDIT', true);

// Deshabilitar instalación de plugins/temas vía admin (producción)
define('DISALLOW_FILE_MODS', true);

// Prefijo de tabla de base de datos personalizado (establecer durante instalación)
$table_prefix = 'wp8x_';

// Limitar revisiones de entradas
define('WP_POST_REVISIONS', 5);

// Bloquear peticiones HTTP externas (lista blanca solo lo necesario)
define('WP_HTTP_BLOCK_EXTERNAL', true);
define('WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,downloads.wordpress.org');

// Deshabilitar WordPress cron (usar system cron en su lugar)
define('DISABLE_WP_CRON', true);

// Debug - desactivado en producción
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

#Cómo desactivar XML-RPC en WordPress

XML-RPC es un protocolo legado que permite ataques de amplificación de fuerza bruta y DDoS. A menos que lo necesites específicamente para Jetpack o la app móvil de WordPress, deshabilítalo completamente:

// En functions.php o un plugin de seguridad personalizado
add_filter('xmlrpc_enabled', '__return_false');

// Eliminar endpoint XML-RPC del head
remove_action('wp_head', 'rsd_link');

Adicionalmente, bloquea XML-RPC a nivel de servidor en .htaccess:

<Files xmlrpc.php>
    Require all denied
</Files>

Actualización, 2 de noviembre de 2026. El filtro de arriba hace menos de lo que promete su nombre. La referencia de WordPress indica que xmlrpc_enabled solo desactiva los métodos que exigen iniciar sesión y deja activos los pingbacks. Ahora importa: el 22 de octubre Google publicó CVE-2026-111497, una escritura fuera de límites en el decodificador Brotli (versiones 1.0.3 a 1.2.0, CVSS 4.0: 9,2, corregida en 1.0.10, 1.1.1 y 1.2.1). Según Wordfence, la prueba de concepto pública llega a la librería a través del pingback, que no requiere autenticación: WordPress descarga una URL remota y el servidor puede descomprimir la respuesta en Brotli. Actualizar WordPress o los plugins no lo corrige, porque la librería forma parte del servidor. Elimina también los métodos de pingback, mantén el bloqueo en el servidor y pregunta a tu proveedor de hosting si la librería Brotli de tu servidor ya está parcheada.

// Pingbacks are unauthenticated, so xmlrpc_enabled does not stop them
add_filter('xmlrpc_methods', function ($methods) {
    unset($methods['pingback.ping'], $methods['pingback.extensions.getPingbacks']);
    return $methods;
});

Si no sabes sobre qué software de servidor funciona tu web, nuestra auditoría de seguridad de WordPress empieza justo por ese inventario.

#Cómo restringir la REST API de WordPress

La REST API de WordPress expone enumeración de usuarios y datos de contenido por defecto. Restringe a usuarios autenticados para endpoints sensibles:

add_filter('rest_authentication_errors', function ($result) {
    if (true === $result || is_wp_error($result)) {
        return $result;
    }

    if (!is_user_logged_in()) {
        return new WP_Error(
            'rest_not_logged_in',
            __('No estás autenticado.'),
            ['status' => 401]
        );
    }

    return $result;
});

// Deshabilitar enumeración de usuarios vía REST API
add_filter('rest_endpoints', function ($endpoints) {
    if (isset($endpoints['/wp/v2/users'])) {
        unset($endpoints['/wp/v2/users']);
    }
    if (isset($endpoints['/wp/v2/users/(?P<id>[\d]+)'])) {
        unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    }
    return $endpoints;
});

#Cómo proteger el login de WordPress

#Passkeys (WebAuthn/FIDO2)

Las Passkeys son el avance de autenticación más significativo para WordPress en 2026. Basadas en el estándar WebAuthn/FIDO2, las Passkeys reemplazan completamente las contraseñas con pares de claves criptográficas almacenadas en el dispositivo del usuario (teléfono, portátil o llave de seguridad hardware).

Por qué las Passkeys importan para WordPress:

• Resistentes al phishing: La clave privada nunca sale del dispositivo. No hay contraseña que robar.
• Sin credential stuffing: Cada Passkey está vinculada al dominio específico. Una Passkey para tusitio.com no puede usarse en un dominio imitador.
• Mejor UX: Los usuarios se autentican con biometría (huella dactilar, rostro) o PIN del dispositivo - más rápido que escribir una contraseña más código 2FA.

Para implementar Passkeys en WordPress, usa un plugin como WP-WebAuthn o Passwordless WP que implementa el estándar WebAuthn. Configúralo para:

1. Requerir registro de Passkey para todas las cuentas de administrador y editor.
2. Permitir login solo con Passkey (deshabilitar el respaldo de contraseña para cuentas con altos privilegios).
3. Soportar autenticadores de plataforma (biometría del dispositivo) y autenticadores roaming (YubiKey, etc.).

#Autenticación de dos factores (2FA)

Para usuarios que no pueden usar Passkeys, impón 2FA usando apps TOTP (Time-based One-Time Password) como Authy, Google Authenticator o 1Password. Evita 2FA basado en SMS debido a vulnerabilidades de SIM-swapping.

#Protección de WordPress contra fuerza bruta

Implementa limitación de tasa en múltiples niveles:

// Limitar intentos de login - functions.php o plugin personalizado
function custom_login_rate_limit() {
    $ip = $_SERVER['REMOTE_ADDR'];
    $transient_key = 'login_attempts_' . md5($ip);
    $attempts = get_transient($transient_key);

    if ($attempts === false) {
        set_transient($transient_key, 1, HOUR_IN_SECONDS);
    } elseif ($attempts >= 5) {
        wp_die('Demasiados intentos de login. Inténtalo de nuevo más tarde.', 429);
    } else {
        set_transient($transient_key, $attempts + 1, HOUR_IN_SECONDS);
    }
}
add_action('wp_login_failed', 'custom_login_rate_limit');

Adicionalmente:

• Cambia la URL de login de /wp-login.php a una ruta personalizada.
• Implementa CAPTCHA en la página de login para autenticación no-Passkey.
• Establece políticas de contraseñas requiriendo mínimo 16 caracteres con tipos de caracteres mixtos.

#Cómo proteger la base de datos de WordPress

#Cambiar el prefijo de tablas wp_

Nunca uses el prefijo predeterminado wp_. Establece un prefijo personalizado durante la instalación de WordPress:

$table_prefix = 'wp8x_';

Para instalaciones existentes, cambia el prefijo usando WP-CLI o un script de migración de base de datos, actualizando tanto las tablas de la base de datos como la referencia en wp-config.php.

#Prepared statements con $wpdb->prepare()

Todas las consultas personalizadas a la base de datos deben usar el método $wpdb->prepare() de WordPress para prevenir inyección SQL:

global $wpdb;

// CORRECTO: consulta parametrizada
$results = $wpdb->get_results(
    $wpdb->prepare(
        "SELECT * FROM {$wpdb->prefix}posts WHERE post_author = %d AND post_status = %s",
        $author_id,
        'publish'
    )
);

// NUNCA: interpolación directa de variables
// $results = $wpdb->get_results("SELECT * FROM wp_posts WHERE post_author = $author_id");

#Estrategia de backup para WordPress

• Backups diarios automatizados de base de datos y archivos.
• Encriptar backups en reposo usando AES-256.
• Almacenar backups off-site en una ubicación geográficamente separada (S3, B2, etc.).
• Probar procedimientos de restauración mensualmente - un backup que no puedes restaurar no es un backup.
• Retener backups por un mínimo de 30 días con una política de retención rotativa.

#Cómo elegir y actualizar plugins de forma segura

#Cómo revisar un plugin antes de instalarlo

Antes de instalar cualquier plugin o tema, evalúa:

1. Fecha de última actualización - rechaza todo lo que no se haya actualizado en los últimos 6 meses.
2. Instalaciones activas - prefiere plugins con más de 10.000 instalaciones activas.
3. Actividad del foro de soporte - verifica si el desarrollador responde a informes de seguridad.
4. Revisión de código - para plugins críticos, revisa el código fuente para vulnerabilidades obvias (eval, output sin escapar, consultas directas a la base de datos).
5. Historial de vulnerabilidades - consulta las bases de datos de vulnerabilidades de Patchstack, WPScan y Wordfence.
6. Reputación del desarrollador - empresas WordPress establecidas y desarrolladores con historial comprobado.

#Actualizaciones automáticas de plugins y temas

Habilita actualizaciones automáticas de seguridad para plugins y temas:

// Habilitar auto-actualizaciones para todos los plugins
add_filter('auto_update_plugin', '__return_true');

// Habilitar auto-actualizaciones para todos los temas
add_filter('auto_update_theme', '__return_true');

// Habilitar auto-actualizaciones para versiones menores de WordPress (comportamiento predeterminado)
add_filter('allow_minor_auto_core_updates', '__return_true');

Para sitios de misión crítica, usa un entorno de staging para probar actualizaciones antes de desplegar en producción. Herramientas como WP Engine Smart Plugin Manager o MainWP automatizan este flujo de trabajo.

Actualización, 2 de noviembre de 2026. WordPress 7.1.4 (28 de octubre) es un lanzamiento de seguridad. La corrección más grave es una condición de carrera no autenticada en el proceso de actualización del core que puede llevar a ejecución remota de código mientras un paquete completo se descomprime en una ruta predecible bajo wp-content/upgrade/ (notas HelpHub, Wordfence, 29 de octubre de 2026). Wordfence la registra como CVE-2026-119977 con CVSS 8.1: la copia en staging incluye el instalador, así que una petición a setup-config.php staged en esa ventana corta puede acabar en ejecución PHP. La complejidad del ataque es alta (segundos en laboratorio), pero Wordfence registró más de 18.500 peticiones a rutas de instalador en staging en las primeras 21 horas tras su regla de firewall, con el primer acierto nueve minutos después del deploy. 7.1.4 aleatoriza el directorio de staging, añade un index guard y bloquea la promoción insegura de staged configuration; los backports llegan hasta 4.7. Confirma en Escritorio > Actualizaciones que tienes 7.1.4 (o el backport de la rama). Wordfence Premium, Care y Response recibieron la regla el 28 de octubre a las 20:30 UTC; Wordfence Free recibe la misma regla el 27 de noviembre de 2026. Como el exploit pide el PHP staged sin cargar WordPress, activa Extended Protection en el firewall de Wordfence; la regla no sustituye la actualización del core. Tras el parche, revisa logs de acceso a PHP bajo wp-content/upgrade/ y lanza un escaneo de malware.

Actualización, 3 de noviembre de 2026. La versión de arriba no es un caso aislado. El equipo de seguridad de WordPress informa de cuatro versiones de seguridad en 41 días (7.1.1 el 17 de septiembre, 7.1.2 el 22 de septiembre, 7.1.3 el 6 de octubre y 7.1.4 el 28 de octubre), siete desde mediados de julio, más de 50 vulnerabilidades Critical o High cerradas y cada corrección llevada a todas las ramas hasta la 4.7. Su programa en HackerOne recibía antes entre 20 y 30 informes al mes; en julio recibió 450, en agosto 773 y este año más de 3000 (Make WordPress Security, The Core Security Initiative: two months in). El equipo usa ahora herramientas de IA para clasificar informes y buscar vulnerabilidades en el núcleo antes de que alguien las notifique. La conclusión para ti es práctica: deja activadas las actualizaciones automáticas menores y, tras cada versión de seguridad, comprueba que la web se actualizó de verdad. Esa comprobación forma parte de mi mantenimiento de WordPress.

#Escaneo de vulnerabilidades en WordPress

Ejecuta escaneos de vulnerabilidades automatizados regularmente:

• WPScan - herramienta CLI para escaneó de vulnerabilidades WordPress.
• Patchstack - monitorización de vulnerabilidades en tiempo real con parcheo virtual.
• Wordfence CLI - escaneó de malware del lado del servidor.

# WPScan desde CLI
wpscan --url https://tusitio.com --enumerate vp,vt,u --api-token TU_TOKEN

#Cómo configurar Content Security Policy en WordPress

Las cabeceras CSP son tu defensa más fuerte contra cross-site scripting (XSS). Le dicen a los navegadores qué fuentes de contenido son confiables:

# Configuración CSP en .htaccess
Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.tusitio.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com; connect-src 'self' https://api.tusitio.com; frame-ancestors 'self'; base-uri 'self'; form-action 'self';"

Para sitios WordPress que usan scripts inline (común con page builders), comienza con Content-Security-Policy-Report-Only para identificar violaciones sin romper funcionalidad:

Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; report-uri /csp-report-endpoint;"

Refuerza progresivamente la política añadiendo nonces para scripts inline legítimos y eliminando unsafe-inline de la directiva script-src.

#Configurar un WAF para WordPress con Cloudflare y ModSecurity

Un WAF filtra tráfico malicioso antes de que llegue a tu aplicación WordPress. Despliega en el borde de la red para máxima protección.

#Cloudflare WAF

El conjunto de reglas gestionado de Cloudflare incluye reglas específicas para WordPress. Configura:

1. Habilita el conjunto de reglas WordPress en Security > WAF > Managed Rules.
2. Crea reglas personalizadas para bloquear patrones de ataque conocidos:
   • Bloquea peticiones a wp-login.php de países donde no tienes usuarios.
   • Limita las peticiones a la página de login a 5 por minuto por IP.
   • Bloquea peticiones que contengan patrones de inyección SQL en query strings.
3. Habilita Bot Management para distinguir bots legítimos (Googlebot) de crawlers maliciosos.
4. Configura Reglas de Acceso IP para añadir a la lista blanca tu IP de oficina y bloquear rangos maliciosos conocidos.

Actualización, 2 de noviembre de 2026. El DDoS Threat Report de Cloudflare del 3.º trimestre de 2026 (Cloudforce One, 29 de octubre) explica por qué un origin WooCommerce pequeño cae con «solo» unos cientos de Mbps. En la red de Cloudflare el trimestre sumó unos 18,2 millones de ataques DDoS de capa de red y 14,4 billones de peticiones HTTP DDoS: unos 8200 ataques de red por hora. Ráfagas cortas de menos de 10 minutos y de menos de 1 Gbps subieron un 208% interanual y dominaron el volumen; los ataques por encima de 1 Tbps cayeron cerca de un 69% respecto al 2.º trimestre tras acciones contra grandes botnets IoT. Cambió la reflexión: CLDAP se desplomó, la amplificación DNS subió un 215% y otros floods UDP casi duplicaron su cuota.

Para una tienda WordPress la práctica sigue igual: mitigación en el edge antes de PHP. Mantén activas las reglas HTTP y de red DDoS en Cloudflare, limita wp-login.php y xmlrpc.php, y no abras el origin «por velocidad». Un enjambre por debajo de 1 Gbps basta para agotar el hosting compartido, aunque no llegue a titulares en Tbps.

#ModSecurity para WordPress: configuración del OWASP Core Rule Set

Para entornos self-hosted, configura ModSecurity con el OWASP Core Rule Set. El CRS cubre de fábrica las clases de ataque del OWASP Top 10; el trabajo específico de WordPress está en las reglas de exclusión, porque el CRS sin ajustar genera falsos positivos con tráfico legítimo de wp-admin:

# Habilitar ModSecurity
SecRuleEngine On

# Reglas OWASP CRS
Include /etc/modsecurity/crs/crs-setup.conf
Include /etc/modsecurity/crs/rules/*.conf

# Excepciones específicas de WordPress (para evitar falsos positivos)
SecRule REQUEST_URI "@beginsWith /wp-admin" "id:1000,phase:1,pass,nolog,ctl:ruleRemoveById=941160"

#Configuración de TLS y HSTS para WordPress

La encriptación TLS es innegociable. Más allá de instalar un certificado, configura TLS correctamente:

# Configuración TLS Nginx
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;

# HSTS - decir a los navegadores que siempre usen HTTPS
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;

# OCSP Stapling
ssl_stapling on;
ssl_stapling_verify on;
resolver 1.1.1.1 8.8.8.8 valid=300s;

Prácticas clave:

• Usa TLS 1.2 como mínimo, prefiere TLS 1.3 para rendimiento y seguridad.
• Deshabilita TLS 1.0 y 1.1 completamente - tienen vulnerabilidades conocidas.
• Habilita HSTS con un max-age mínimo de un año (31536000 segundos).
• Envía tu dominio a la lista HSTS preload en hstspreload.org.
• Automatiza la renovación de certificados con Let’s Encrypt y certbot.
• Prepárate para los certificados de 64 días de Let’s Encrypt. Desde el 10 de febrero de 2027 será la validez por defecto, y el último certificado de 90 días caducará el 11 de mayo de 2027. Según el anuncio, el entorno de staging pasó a certificados de 64 días el 14 de octubre de 2026, así que prueba allí la renovación. En 2028 el valor por defecto bajará a 45 días.
• Elimina las fechas de renovación fijas. Renueva hacia dos tercios de la validez y busca en tareas cron, scripts y procedimientos valores fijos de 83, 80 o 60 días. El periodo de reutilización de autorizaciones se reduce de 30 a 10 días.
• Prueba tu configuración con SSL Labs (ssllabs.com/ssltest).

Actualización, 2 de noviembre de 2026. El 19 de octubre de 2026 Cloudflare reveló que ocho certificados intermedios de eMudhra usaban claves privadas trivialmente débiles (incluido el entero 4), así que cualquiera podía falsificar un certificado para cualquier dominio que un cliente sin parche aceptara (Cloudflare). La nota del 30 de octubre cuenta unos 22.000 handshakes con esas claves en la red de Cloudflare y certificados falsificados en menos de una hora tras la divulgación pública; Cloudflare no confirma interceptación de sus propias conexiones (patching). Para una tienda WordPress detrás de Cloudflare las acciones son concretas: actualiza Cloudflare Tunnel (cloudflared) a 2026.10.2 o posterior, actualiza los clientes Cloudflare One / WARP / 1.1.1.1 a los builds que lista Cloudflare, revisa certificados de origen con Full (strict) SSL y renueva cualquier trust store mutual TLS que hayas subido. No “arregles” errores de certificado desactivando la verificación. Los navegadores modernos parchean antes que bots y WebViews embebidos - las sondas de challenge de Cloudflare seguían viendo grandes cuotas que aceptaban la cadena débil una semana después.

Captura: Cloudflare Blog, 4 real? Tracking exploitation and patching of eMudhra’s weak keys, 30 de octubre de 2026.

#Cómo monitorizar WordPress y actuar ante un hackeo

#Monitorización en tiempo real

Implementa monitorización en múltiples capas:

• Monitorización de integridad de archivos: Detectar cambios no autorizados en archivos del núcleo, plugins y temas. Herramientas como OSSEC, Tripwire o detección de cambios de archivos de Wordfence.
• Registro de actividad de login: Registrar todos los intentos de login exitosos y fallidos con IP, user agent y timestamp.
• Registro de consultas a la base de datos: Monitorizar patrones de consultas inusuales que indiquen intentos de inyección SQL.
• Monitorización de uptime: Detectar defacement o toma de control del sitio inmediatamente.

#Plan de respuesta a incidentes en WordPress

Cada sitio WordPress debería tener un plan de respuesta a incidentes documentado:

1. Detección: Alertas automatizadas por cambios de archivos, detección de malware, picos de tráfico inusuales.
2. Contención: Poner el sitio comprometido offline inmediatamente o detrás de una página de mantenimiento. Revocar todas las credenciales de admin.
3. Erradicación: Identificar el vector de ataque. Eliminar malware. Restaurar desde un backup limpio conocido.
4. Recuperación: Poner el sitio online de nuevo. Restablecer todas las contraseñas. Actualizar todos los plugins y temas. Verificar integridad.
5. Revisión Post-Incidente: Documentar qué ocurrió, cómo se detectó, cuál fue el impacto y qué medidas preventivas se implementarán.

#¿Es más seguro WordPress headless?

Ejecutar WordPress en una arquitectura headless - donde WordPress sirve como API de contenido y el sitio público se construye con un framework como Astro, Next.js o Nuxt - proporciona ventajas de seguridad significativas:

• Superficie de ataque reducida: Los visitantes interactúan con un front-end estático o renderizado en servidor. Nunca tocan PHP o WordPress directamente.
• Sin vulnerabilidades de temás: El sitio público no ejecuta temas WordPress, eliminando toda una clase de vulnerabilidades XSS y de inyección.
• Admin detrás de un firewall: El admin de WordPress puede colocarse detrás de un VPN o lista blanca de IP, haciéndolo invisible para internet público.
• Solo exposición de API: Solo los endpoints REST API o GraphQL están expuestos, y estos pueden protegerse con autenticación y limitación de tasa.
• Arquitectura CDN-first: Los sitios estáticos se despliegan en nodos CDN edge, proporcionando protección DDoS inherente a través de arquitectura distribuida.

En wppoland.com construyo arquitecturas WordPress headless que maximizan tanto la seguridad como el rendimiento. Si prefieres delegar este trabajo en lugar de aplicar el endurecimiento por tu cuenta, nuestra auditoría de seguridad WordPress profesional evalúa toda tu pila y proporciona una hoja de ruta de endurecimiento detallada.

#A qué autoridad notificar una brecha de datos en España

Las guías en inglés dicen „notifica a la autoridad de protección de datos” como si hubiera una sola. En España la general es la AEPD, pero existen autoridades autonómicas con competencia propia sobre el sector público de su territorio, como la APDCAT en Cataluña o la AVPD en el País Vasco. Si el proyecto es de una administración catalana, notificar a la AEPD es notificar al organismo equivocado.

El plazo de 72 horas no empieza con el ataque, sino con el conocimiento. En un WordPress comprometido eso suele ser el momento en que salta un escáner o aparece un fichero desconocido, no la llamada del cliente. Por eso la retención de los registros decide si puedes acreditar cuándo empezó a contar.

La segunda vía es la que más se olvida. La notificación por brecha de datos personales y la notificación de incidente de ciberseguridad son obligaciones distintas ante destinatarios distintos, no una misma comunicación con dos copias.

La consecuencia práctica para el endurecimiento descrito en esta guía es directa: los registros deben escribirse en un destino que un atacante con permisos sobre el servidor web no alcance. Quien puede modificar wp-content también puede borrar los ficheros de log que estén allí. Sin destino externo, el momento del conocimiento no se puede reconstruir después, y con él se pierde la prueba de haber cumplido el plazo.

#Requisitos del RGPD para sitios WordPress

La seguridad y la protección de datos están entrelazadas. Bajo el RGPD (y regulaciones similares como LGPD y DSGVO), una brecha de seguridad que involucre datos personales requiere notificación a las autoridades supervisoras dentro de 72 horas.

Consideraciones RGPD específicas de WordPress:

• Encriptar datos personales en reposo y en tránsito.
• Implementar minimización de datos: Recoger solo lo necesario. Eliminar lo que ya no se necesita.
• Usar las herramientas de privacidad integradas de WordPress: Solicitudes de exportación y eliminación de datos (Herramientas > Exportar Datos Personales / Borrar Datos Personales).
• Auditar la recolección de datos de plugins: Muchos plugins recopilan datos personales (analytics, formularios, comentarios). Documentar qué datos procesa cada plugin.
• Consentimiento de cookies: Implementar un banner de consentimiento de cookies compatible con RGPD que bloquee scripts de rastreo hasta que se otorgue el consentimiento.
• Política de privacidad: Mantener una política de privacidad precisa que describa todas las actividades de procesamiento de datos.
• Acuerdos de Procesamiento de Datos: Asegurar que existen APDs con todos los servicios de terceros que procesan datos personales (hosting, email, analytics).

#Mejores plugins de seguridad WordPress en 2026

Aunque el endurecimiento del servidor y las buenas prácticas importan más que cualquier plugin, los plugins de seguridad añaden valiosas capas de monitorización y protección automatizada. Estas son las opciones que vale la pena considerar:

#Top 10 plugins de seguridad WordPress comparados

Al evaluar plugins de seguridad, concéntrate en estos criterios en lugar del número de funcionalidades:

1. Tasa de falsos positivos. Un escáner que marca archivos legítimos desperdicia más tiempo del que ahorra.
2. Impacto en rendimiento. Algunos plugins de seguridad añaden 200-500ms a cada carga de página. Usa Query Monitor para medir antes de comprometerte.
3. Calidad del WAF. Los WAF basados en la nube (Cloudflare, Sucuri) superan a los WAF a nivel de plugin porque bloquean el tráfico malicioso antes de que llegue a tu servidor.
4. Frecuencia de actualizaciones. Las definiciones de amenazas del plugin deben actualizarse más rápido de lo que aparecen nuevas vulnerabilidades. Actualizaciones semanales son el mínimo.
5. Compatibilidad. Los plugins de seguridad que se enganchan a cada acción de WordPress pueden entrar en conflicto con cache, constructores de páginas y endpoints de REST API.

Nuestra recomendación: Wordfence o Patchstack para protección activa, WP Activity Log para registros de auditoría de cumplimiento, y un WAF en la nube (Cloudflare) como primera línea de defensa. Cuando el incidente ya está en curso y un desarrollador general lo rechazó, eso es trabajo de especialista WordPress, no otro plugin. No acumules múltiples plugins de seguridad — un escáner, un WAF, un registro de auditoría es suficiente. Para una guía detallada sobre la selección de plugins relacionados con seguridad, consulta nuestra guía de plugins esenciales WordPress.

#Checklist de hardening WordPress en 25 puntos

Usa esta lista de comprobación de 25 puntos para auditorías de seguridad trimestrales:

#Nivel del servidor

1. La versión de PHP es 8.2+ con funciones peligrosas deshabilitadas
2. Los permisos de archivos son 644 (archivos) y 755 (directorios)
3. wp-config.php tiene permiso 400 y está por encima de la raíz web
4. SSH usa autenticación solo con claves con login root deshabilitado
5. El software del servidor (Nginx/Apache) está actualizado y parcheado
6. Fail2ban o equivalente está activo y configurado

#Aplicación WordPress

7. El núcleo de WordPress es la última versión estable
8. Todos los plugins están actualizados y activamente mantenidos
9. Todos los temas están actualizados (eliminar temas no utilizados)
10. XML-RPC está deshabilitado a nivel de servidor y aplicación
11. Los endpoints de usuarios de la REST API están restringidos
12. La edición de archivos está deshabilitada (DISALLOW_FILE_EDIT)
13. Las modificaciones de archivos están deshabilitadas en producción (DISALLOW_FILE_MODS)
14. El modo debug está desactivado en producción
15. Las claves de seguridad y salts son únicas y recientemente rotadas

#Autenticación

16. Passkeys o 2FA están impuestas para todas las cuentas admin
17. La URL de login está cambiada del predeterminado wp-login.php
18. La protección contra fuerza bruta con limitación de tasa está activa
19. La política de contraseñas impone mínimo 16 caracteres

#Red y cabeceras

20. SSL/TLS 1.2+ con certificado válido y HSTS habilitado
21. WAF está activo con conjunto de reglas específico para WordPress
22. Las cabeceras CSP están configuradas y probadas
23. Todas las cabeceras de seguridad están presentes (X-Frame-Options, X-Content-Type-Options, Referrer-Policy)

#Monitorización y cumplimiento

24. La monitorización de integridad de archivos está activa con alertas
25. Los backups automatizados se ejecutan diariamente con almacenamiento off-site encriptado y procedimientos de restauración probados

Cada elemento debe ser verificado, documentado y cualquier fallo remediado dentro de un SLA definido. Para una auditoría de seguridad profesional de tu instalación WordPress, contáctame para una evaluación completa.

#Conclusión

La seguridad WordPress en 2026 requiere defensa en profundidad - ninguna medida individual es suficiente. Desde el endurecimiento PHP a nivel de servidor a través de la configuración de aplicación, autenticación moderna con Passkeys, protección de base de datos, despliegue de WAF y monitorización continúa - cada capa contribuye a una postura de seguridad resiliente.

El enfoque más efectivo combina endurecimiento técnico con disciplina de proceso: auditorías regulares, procedimientos de respuesta a incidentes probados, escaneó automático de vulnerabilidades y una cultura que trata la seguridad como una práctica continúa en lugar de una configuración única.

Comienza con la lista de comprobación de esta guía. Implementa las medidas sistemáticamente, empezando desde el nivel del servidor y subiendo por la pila de la aplicación. Prueba cada cambio en un entorno de staging antes de desplegar en producción. Y recuerda - el sitio WordPress más seguro es uno que se mantiene activamente, se monitoriza y se audita regularmente.