WordPress seguro en 2026: checklist de lo que un atacante ve

Todo artículo de "WordPress seguro" termina recomendando el mismo plugin de firewall y dos cambios en el wp-config.php. Eso resuelve la mitad del problema. La otra mitad vive en lo que cualquier visitante anónimo puede ver sin tocar tu panel de admin.

Este checklist es lo que un atacante prueba primero. Corré la lista. Lo que aparezca en rojo, arreglalo hoy.

1. Versión expuesta en el fuente de la página

Abrí el sitio en pestaña incógnita, ver-fuente, buscá wp-content/themes/ o wp-content/plugins/. Vas a ver:

?ver=6.4.3
?ver=4.9.8

Ese ?ver= es el número de versión del plugin/theme expuesto al mundo. El atacante cruza con la WPScan Vulnerability Database y sabe exactamente qué exploit probar.

Mitigación: sacá la query string de versión de los assets en producción (filtros style_loader_src y script_loader_src), o usá un plugin de cache que minifica todo en un solo archivo.

2. /wp-json/wp/v2/users abierto

Accedé a https://tusitio.com/wp-json/wp/v2/users. Si devuelve JSON con la lista de usuarios (incluyendo el slug — que es el login del admin en WordPress), acabás de entregar la mitad del brute-force.

Mitigación: deshabilitar endpoints REST de users para no autenticados:

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;
});

3. /?author=1 revela el login

https://tusitio.com/?author=1 redirige a /author/tu-login-real/. En segundos, el atacante tiene el usuario y va al brute force en /wp-login.php.

Mitigación: bloqueá la redirección vía template_redirect, o cambiá el slug del usuario admin a algo distinto del login.

4. /wp-admin/ sin rate-limit

Equivocá la contraseña 10 veces seguidas. Si en la 11ª todavía podés probar, no hay rate-limit. Los bots prueban 50 contraseñas por minuto hasta cansarse.

Mitigación: Limit Login Attempts (plugin), Fail2Ban en el servidor, o una regla challenge de Cloudflare para /wp-login.php.

5. Backups olvidados en la carpeta pública

El peor. Los atacantes prueban a ciegas:

/backup.zip
/site.sql
/db.sql
/database.sql
/wp-content/backups/
/wp-content/uploads/2024/db.sql
/.git/config
/wp-config.php.bak
/wp-config.old

Cada una de esas pega en alguna tienda online hoy. Dump SQL expuesto = base de datos entera filtrada, incluido hash de contraseña de cliente.

Mitigación: nunca dejar backup en carpeta servida por HTTP. Usá S3, FTP off-site, o un directorio por encima del public_html. Y negá *.sql, *.zip, *.bak, *.old, .git/ en .htaccess o nginx.conf.

6. xmlrpc.php habilitado

/xmlrpc.php acepta autenticación XML-RPC. Los atacantes usan system.multicall para probar 500 contraseñas por request — burlando el rate-limit de /wp-login.php.

¿Usás Jetpack, la app mobile de WP o pingbacks? ¿No? Bloqueá.

Mitigación: Deny from all en xmlrpc.php en .htaccess, o bloqueo en Cloudflare.

7. Versión de PHP y Apache en el header

curl -I https://tusitio.com/ y mirá:

Server: Apache/2.4.18 (Ubuntu)
X-Powered-By: PHP/7.2.34

PHP 7.2 no tiene soporte desde 2020. Apache 2.4.18 tiene CVE crítico. Esos headers le gritan al atacante "probá esto".

Mitigación: expose_php = Off en php.ini, ServerTokens Prod en Apache, server_tokens off en nginx.

8. Plugin abandonado

Mirá tus plugins activos. ¿Alguno sin update hace más de 2 años? Un plugin con 50 mil instalaciones y último commit en 2022 es vector preferido de ataque masivo — cuando sale el exploit, todos caen juntos.

Mitigación: cambiar por alternativa mantenida. Plugin de 2 años sin actualización no es estable, está abandonado.

9. wp-content/uploads/ con PHP ejecutable

Subí una imagen llamada test.php.jpg. Accedela. Si el servidor la ejecuta como PHP, tenés RCE servido en bandeja desde cualquier plugin con upload roto.

Mitigación: negar ejecución de .php dentro de /uploads/:

location ~* /wp-content/uploads/.*\.php$ {
    deny all;
}

10. HTTPS sin redirección y sin HSTS

¿El sitio responde en http:// y https://? ¿No tiene Strict-Transport-Security en el header? Las cookies de sesión pueden filtrarse en red pública.

Mitigación: redirect 301 de HTTP a HTTPS en el servidor, y header Strict-Transport-Security: max-age=31536000; includeSubDomains; preload.

Cómo Sentinela cubre esto automáticamente

Corremos este barrido todas las noches en tu dominio:

• Versiones de WP, plugin y theme expuestas
• Endpoints REST sensibles abiertos
• Archivos de backup probados en 200+ paths conocidos
• Headers de servidor y PHP filtrando
• xmlrpc.php activo
• Auth vía /?author=N
• Certificado SSL y HSTS
• CVE matching para cada versión detectada

Cuando conectás el repo, además corremos SAST y secret scanning solo en tu código — sin ahogar el reporte en ruido del core de WP (un anti-patrón común que ya contamos antes).

El plan Free es gratis para siempre. Cargá tu dominio y en 10 minutos vas a ver cuántos de estos 10 ítems tenés abiertos. Para profundizar en headers específicamente, mirá 5 cabeceras de seguridad HTTP.

La regla simple

La mayoría de los sitios WordPress hackeados en 2026 no cae por exploit caro. Caen por una de estas 10 cosas. Corré la lista hoy.