Ataques de fuerza bruta en WordPress: cómo defenderte

«`html Actualizado el 22/08/2026: sumamos la guía completa de detección por logs de servidor (con ejemplo de línea real y snippet para registrar intentos fallidos), los pasos manuales de protección sin plugins, la comparativa ampliada de cuatro herramientas —incluye Solid Security, ex iThemes Security— y la rutina de monitoreo continuo para que la protección no quede desactualizada.

Los ataques de fuerza bruta contra WordPress se duplicaron en lo que va de 2026. No es una exageración: según los datos que manejan las empresas de seguridad como Patchstack, el volumen de intentos automatizados de adivinar contraseñas creció más del 100% respecto al año anterior. Si tenés un WordPress sin protección, las probabilidades de que te lo estén escaneando ahora mismo son altísimas. Muy altas.

Un ataque de fuerza bruta en WordPress es un método automatizado donde un bot prueba miles de combinaciones de usuario y contraseña contra la pantalla de login hasta dar con la correcta. A diferencia de un ataque dirigido que explora vulnerabilidades específicas, acá el atacante apuesta al volumen: lanza diccionarios de credenciales comunes —»admin/admin123″, «test/test2026″— y espera que alguna funcione. La protección contra fuerza bruta en WordPress no es opcional en 2026; es la primera capa que separa un sitio funcional de uno comprometido.

Y sí, WordPress es particularmente regalado para este tipo de ataque. No porque sea mal software, sino porque tiene tres características que lo ponen en la mira permanente: la URL de login es conocida por cualquiera, no trae límite de intentos por defecto, y el usuario «admin» sigue siendo el nombre más común del planeta WordPress. El combo perfecto para que un script de 20 líneas haga estragos.

Patchstack es un sistema de seguridad para WordPress desarrollado por Patchstack OÜ, diseñado para proteger sitios web mediante un cortafuegos de aplicaciones web y un motor de parches virtuales que mitiga vulnerabilidades conocidas.

¿Por qué WordPress es especialmente vulnerable a ataques de fuerza bruta?

No voy a endulzarlo: WordPress viene de fábrica con la puerta sin llave. Cualquiera que sepa lo mínimo del CMS sabe que el login está en /wp-login.php o /wp-admin. No es información reservada, es la estructura estándar, y eso ya te pone en desventaja frente a un atacante automatizado. El script no tiene que adivinar dónde pegar, ya lo sabe.

Lo segundo es que, por defecto, WordPress no limita los intentos de login. Podés probar cien contraseñas por minuto durante horas y el CMS no te va a frenar —ni siquiera te va a avisar. El servidor recibe todas esas peticiones POST, procesa cada una, consulta la base de datos, y solo cuando el atacante acierta (o se cansa) el ataque termina. El costo en recursos es para el sitio atacado, no para el atacante.

Lo tercero es cultural: el usuario administrador por defecto se llamó «admin» durante años, y aunque las instalaciones nuevas piden un nombre personalizado desde hace tiempo, la base instalada de sitios viejos —y los que simplemente no cambiaron la costumbre— sigue siendo enorme. Dale a un bot el nombre de usuario más probable del mundo y solo le falta la contraseña, que está a fuerza bruta de distancia.

Según los datos públicos de Wordfence, su firewall bloqueó más de 100 mil millones de ataques originados desde 74 millones de direcciones IP distintas. No es ciencia ficción. Y de esos, una porción gigantesca son intentos de fuerza bruta automatizados que pegan contra cualquier dominio WordPress que encuentran. Si tu sitio está indexado, ya está en la lista de objetivos.

¿Cómo limitar los intentos de login en WordPress?

Acá la solución es directa y no cuesta un mango: instalás un plugin que ponga un límite y te olvidás del problema base. El más usado —y con buena razón— es Limit Login Attempts Reloaded, con más de 2 millones de instalaciones activas y versión gratuita completa. Configurarlo te lleva literalmente dos minutos.

La configuración que yo recomiendo y que viene funcionando bien en la mayoría de los casos: 4 o 5 intentos permitidos, bloqueo de 1 hora tras superarlos. Con eso cortás el 99% de los ataques automatizados genéricos, que tiran cientos de combinaciones por minuto. Si necesitás ser más restrictivo —ponele que manejás datos sensibles— bajá a 3 intentos y subí el bloqueo a 4 horas. El costo es mínimo: un usuario real que se olvidó la contraseña tiene el reset por mail, no necesita 20 intentos seguidos. Complementá con nuestra guía de configuración de Sucuri.

Eso sí, ojo con algo importante: si estás detrás de un proxy inverso o usás Cloudflare, asegurate de que el plugin tome la IP real del visitante y no la del proxy. Limit Login Attempts Reloaded tiene opción para eso en su configuración avanzada. Si no lo hacés, podés terminar bloqueando la IP de Cloudflare y dejando a todos afuera (sí, me pasó una vez en 2018 y todavía me acuerdo).

¿Plugin de límite de intentos o firewall completo?

Alternativa: Wordfence ya incluye protección de fuerza bruta en su firewall gratuito, así que si estás armando la seguridad desde cero, quizás te convenga ir directo por ese camino y tener todo en un solo plugin. Pero si ya tenés otro esquema de seguridad y solo necesitás limitar intentos, Limit Login Attempts Reloaded es liviano y va directo al grano sin meter 40 funcionalidades que no pediste. Más abajo tenés la comparativa completa de las cuatro opciones principales.

¿Cómo implementar autenticación de dos factores (2FA) en WordPress?

Ponele que hiciste todo bien, limitaste los intentos, cambiaste la URL de login… y aún así alguien obtiene tu contraseña por una filtración, un keylogger o porque la tenías anotada en un papelito (no me mirés así, todos lo hicimos). Ahí es donde el 2FA te salva las papas: sin el segundo factor, la contraseña es un pisapapeles.

Un 2FA bien implementado detiene el 100% de los bots automatizados, incluso si la contraseña fue robada. El bot puede tener «admin» y «m1c0ntr4s3ñ4», pero no tiene el código temporal que cambia cada 30 segundos, ni mucho menos tu llave física.

Los dos protocolos principales son:

• TOTP (Time-based One-Time Password): es el que usan Google Authenticator, Authy, FreeOTP. Un código de 6 dígitos que cambia cada 30 segundos. Gratis, universal, y no depende de SMS (importante porque el SIM-swapping es real).
• U2F/FIDO2 (llaves físicas): YubiKey, Google Titan, Feitian. Conectás la llave, tocás un botón, y listo. Imposible de phishear remotamente. Para sitios con datos sensibles o acceso administrador, es la opción más segura, pero requiere comprar hardware.

Para WordPress, tenés dos caminos limpios:

• Wordfence 2FA: viene incluido en la versión gratuita de Wordfence. Soporta TOTP, es fácil de activar, y ya está integrado con el firewall. Si ya usás Wordfence, activarlo son tres clics.
• Two Factor: es el plugin oficial del repositorio de WordPress, mantenido por colaboradores del core. Soporta TOTP, U2F (con extensión), y backup codes. Si preferís algo más minimalista sin todo el paquete Wordfence, este es el camino.

Lo que no te recomiendo es usar 2FA por SMS. WordPress no lo trae nativo, y los plugins que lo agregan dependen de servicios de terceros que cobran por mensaje y son vulnerables a SIM-swapping. TOTP es más seguro y no cuesta nada.

¿Cómo cambiar la URL de login y por qué no alcanza con solo eso?

Si alguna vez revisaste los logs de acceso de un WordPress sin protección, sabés que /wp-login.php recibe más visitas que una heladería en enero. Automatizar el POST a esa URL es lo primero que hace cualquier script de fuerza bruta. Cambiarla es sacarle el blanco fijo al atacante.

El plugin más directo para esto es WPS Hide Login. Lo instalás, definís una URL personalizada —algo que no sea obvio como /login o /entrar— y listo: /wp-login.php y /wp-admin pasan a devolver un 404 para cualquier visitante no autenticado. Los bots automatizados que pegan contra la URL estándar se estampan contra una pared.

Ahora bien, hay que ser honestos: esto es defensa por oscuridad. Si alguien está haciendo un ataque dirigido contra tu sitio específicamente —no un barrido genérico—, puede encontrar la nueva URL revisando el HTML de la página (muchos themes dejan expuesto el link en el meta widget), o escaneando con herramientas más avanzadas. No reemplaza las capas anteriores, pero saca de juego a la enorme mayoría de los ataques oportunistas. Y en seguridad, capas son capas.

En paralelo a cambiar la URL, eliminá el usuario «admin». Creá uno nuevo con nombre no predecible —idealmente algo que no incluya «admin», «webmaster», «root» ni nada parecido—, asignale permisos de administrador, y borrá o degradá el usuario viejo. WordPress te deja transferir el contenido durante el proceso, así que no perdés nada. Con eso, incluso si el atacante encuentra la nueva URL de login, todavía le falta adivinar un nombre de usuario que no está en ningún diccionario de fuerza bruta. Lo explicamos a fondo en activar la verificación en dos pasos.

¿Cómo detectar si mi sitio está siendo atacado por fuerza bruta?

A veces el ataque no es obvio. No ves un cartel de «te están hackeando», pero tu sitio empieza a arrastrarse, el panel de administración tarda una eternidad en cargar, y no tenés idea de por qué. Spoiler: muy probablemente haya un ataque de fuerza bruta en curso consumiendo los recursos del servidor.

Los síntomas más comunes:

• Rendimiento degradado sin explicación: el sitio va lento, el panel de admin casi no responde, y no cambiaste nada ni tuviste un pico de tráfico legítimo.
• Muchas líneas POST a /wp-login.php en los logs: si revisás los logs de acceso del servidor (Apache/Nginx), vas a ver cientos o miles de peticiones POST seguidas a la URL de login, desde una misma IP o desde varias. Eso no es tráfico normal.
• Consumo anómalo de CPU o memoria: tu hosting —si estás en un plan compartido o VPS, por ejemplo en donweb.com— puede avisarte que estás excediendo los límites de recursos. Un ataque de fuerza bruta dispara procesos PHP de autenticación a repetición.

Si tenés Wordfence instalado, la detección es inmediata: el dashboard muestra los intentos bloqueados en tiempo real, con IP, país de origen, y cantidad de intentos. Podés activar notificaciones por mail cuando se bloquean múltiples IPs en un período corto, que suele indicar un ataque distribuido. También filtrás por usuario atacado —si ves que el blanco es «admin», confirmaste que tenés el usuario por defecto activo y deberías ocuparte de eso ya mismo.

Un patrón más sofisticado que creció en 2026: los atacantes hacen consultas WHOIS al dominio y generan variaciones de contraseña basadas en el nombre del titular o la empresa registrante. No es solo fuerza bruta de diccionario genérico, es fuerza bruta con contexto. Si tu dominio está a nombre de «Juan Pérez Soluciones Web», esperá combinaciones con «juanperez», «solucionesweb», «jpsoluciones» y derivados. La consulta WHOIS es pública y gratuita; no necesitás ser un genio para automatizarla.

Si querés entender el mecanismo completo de estos ataques desde la base, Ayuda WordPress tiene una explicación detallada de cómo funciona la fuerza bruta aplicada a este CMS.

¿Cómo revisar los logs de WordPress para detectar intentos fallidos?

Los logs de acceso del servidor son el registro más temprano y objetivo de un ataque: cada intento de login deja una línea con fecha, IP y recurso pedido, mucho antes de que el sitio muestre síntomas. WordPress no guarda estos intentos por su cuenta, así que la fuente primaria está a nivel de servidor. La documentación oficial de WordPress sobre ataques de fuerza bruta recomienda justamente este tipo de revisión como primer diagnóstico.

Dónde buscar según tu entorno:

• Hosting compartido con cPanel: entrá a la sección «Métricas» y abrí «Acceso bruto» (Raw Access). Descargás el archivo del día y lo leés con cualquier editor de texto.
• VPS o servidor dedicado: los archivos están en /var/log/apache2/access.log o /var/log/nginx/access.log, según el servidor web que uses.
• Plesk o DirectAdmin: traen visor de logs integrado por dominio, sin bajar nada.

Una línea típica de ataque se ve así:

45.155.205.233 - - [20/Aug/2026:04:17:02 -0300] "POST /wp-login.php HTTP/1.1" 200 3814 "-" "python-requests/2.31"

Se lee de izquierda a derecha: IP de origen, fecha y hora, petición POST contra el login, código de respuesta y user-agent. Dos detalles delatan al bot. Primero: WordPress devuelve un 200 incluso cuando la contraseña falla, así que el código HTTP no sirve para filtrar; hay que contar repeticiones. Segundo: «python-requests» no es un navegador, es una librería de scripting. Un humano entra con Chrome o Firefox; un bot se identifica solo.

El umbral práctico: decenas de POST a /wp-login.php por minuto desde una misma IP, o repartidas entre muchas IPs pero con idéntico user-agent, significan ataque en curso. Si preferís tener esto dentro del panel de admin, el plugin WP Activity Log registra cada intento fallido con usuario, IP y fecha, filtrable por tipo de evento.

Alternativa sin plugin: activá WP_DEBUG_LOG en wp-config.php y agregá este snippet en un mu-plugin para volcar los fallos al debug.log:

add_action( 'wp_login_failed', function( $username ) {
 error_log( 'Login fallido: ' . $username . ' | IP: ' . ( $_SERVER['REMOTE_ADDR'] ?? 'n/d' ) );
} );

Con eso, cada intento rechazado queda escrito en wp-content/debug.log y lo filtrás con un simple grep. Es rudimentario, pero funciona y no agrega carga al sitio.

¿Cómo bloquear ataques de fuerza bruta en WordPress sin instalar plugins?

Se puede endurecer un WordPress a mano, sin sumar código extra, y en varios casos conviene hacerlo para no cargar el sitio con otro plugin más. Estas son las medidas manuales con mejor relación entre esfuerzo y resultado:

• Contraseñas largas y únicas por usuario: dieciséis caracteres mínimo, generadas con un gestor y distintas en cada sitio. Suena básico, pero la mayoría de los diccionarios sigue ganando por contraseñas cortas reutilizadas. Si publicás desde apps móviles, usá las contraseñas de aplicación de WordPress en lugar de la principal.
• Restringir wp-login.php por IP en .htaccess: si tu equipo tiene IP fija, cerrás el login para el resto del mundo con tres líneas. La contra: con IP dinámica te terminás bloqueando vos mismo, así que evaluá tu caso antes.
• Desactivar el editor de archivos: agregá define( 'DISALLOW_FILE_EDIT', true ); al wp-config.php. Si un atacante consigue entrar, esta línea le impide editar themes y plugins desde el panel, y un acceso comprometido se vuelve mucho menos rentable.
• Mantener core, plugins y temas al día: la fuerza bruta abre la puerta; las vulnerabilidades conocidas son lo que se usa después. Actualizar cierra esas puertas secundarias y toma minutos.

La regla de .htaccess para el login queda así (reemplazá la IP por la tuya; en Nginx el equivalente va en el bloque server con directivas deny/allow):

<Files wp-login.php>
Order Deny,Allow
Deny from all
Allow from 190.210.45.12
</Files>

Una salvedad honesta: estas medidas reducen la superficie de ataque, pero no reemplazan el límite de intentos. Si gestionás varios autores que entran desde IPs cambiantes, la restricción por IP se vuelve inviable y ahí el 2FA pasa a ser la medida manual más valiosa. Lo ideal es combinar: endurecimiento a mano más un plugin liviano de rate limiting. En reforzar el login con doble factor profundizamos sobre esto.

Comparativa de plugins para bloquear ataques de fuerza bruta en WordPress

No todos los sitios necesitan el mismo arsenal. Un blog personal arranca bien con un limitador de intentos; una tienda con varios administradores justifica un paquete completo con firewall y 2FA. Esta tabla resume las cuatro opciones más usadas del repositorio oficial:

Plugin	Precio	Bloqueo por IP	2FA	Interfaz	Soporte
Limit Login Attempts Reloaded	Gratuito (plan premium opcional)	Sí, configurable	No	Mínima, una pantalla	Foro de WordPress.org
Wordfence	Gratuito; Premium desde USD 119/año	Sí, con reglas avanzadas	Sí, TOTP integrado	Completa, dashboard propio	Email en Premium; foro en gratuito
Solid Security (ex iThemes Security)	Gratuito; Pro desde USD 99/año	Sí, lista de baneos	Solo en Pro	Asistente guiado inicial	Foro en gratuito; tickets en Pro
WPS Hide Login	Gratuito	No (oculta la URL, no bloquea)	No	Una sola opción	Foro de WordPress.org

Lectura rápida de la tabla. Limit Login Attempts Reloaded hace una sola cosa y la hace bien. Wordfence es el todo-en-uno: firewall, escáner y 2FA en el mismo paquete. Solid Security pisa fuerte en hardening general del sitio, pero su 2FA quedó detrás del paywall Pro, lo cual hoy pesa. Y WPS Hide Login ni siquiera es un antifuerza bruta: lo sumamos porque complementa a cualquiera de los otros tres cambiando la puerta de entrada.

Mi recomendación según perfil: si querés cero costo y máxima simpleza, el combo Limit Login Attempts Reloaded + WPS Hide Login cubre el 90% de los escenarios. Si preferís un solo plugin que resuelva todo, Wordfence gratuito bien configurado alcanza para la mayoría de los sitios chicos y medianos.

¿Qué es un WAF y cómo ayuda contra ataques de fuerza bruta?

WAF es Web Application Firewall: un filtro que se pone entre el tráfico entrante y tu WordPress para bloquear peticiones maliciosas antes de que lleguen al CMS. La diferencia con un plugin que corre dentro de WordPress es que el WAF externo opera a nivel de red —la petición ni siquiera toca tu servidor si es maliciosa—, mientras que el WAF por plugin ya está consumiendo recursos de PHP y base de datos para tomar la decisión.

Tenés dos sabores principales:

• WAF externo (Cloudflare, Sucuri): la protección corre en los servidores del proveedor. Las IPs maliciosas se bloquean en el borde, tu servidor no las ve. Cloudflare tiene rate limiting incluso en el plan gratuito, y podés configurar reglas para que, si una IP pega más de X veces al login en Y minutos, automáticamente reciba un challenge o bloqueo. La contra es que el plan gratuito de Cloudflare no cubre ataques muy sofisticados, pero para fuerza bruta genérica sobra.
• WAF a nivel plugin (Wordfence Firewall): corre dentro de WordPress y usa reglas para filtrar peticiones antes de que lleguen a la lógica de autenticación. Bloquea patrones conocidos, limita intentos, y en su versión premium actualiza las reglas en tiempo real. La versión gratuita recibe las reglas con 30 días de retraso, lo cual para fuerza bruta no es crítico porque los patrones no cambian tanto.

La pregunta es cuál conviene. Mi postura: si tu sitio es chico o mediano, Wordfence gratuito bien configurado (límite de intentos + 2FA) alcanza y sobra. Si manejás tráfico pesado, e-commerce o datos de clientes, poné Cloudflare adelante y Wordfence adentro. La latencia extra de Cloudflare es mínima y ganás una capa de protección que no depende de que WordPress esté funcionando para operar.

¿Cómo proteger XML-RPC y otras vías de ataque?

El login por formulario no es la única puerta. WordPress tiene XML-RPC, una API que permite interactuar con el CMS remotamente —la usan las apps móviles de WordPress, Jetpack, y algunas herramientas de publicación externa—. El problema es que XML-RPC también acepta credenciales, y los bots lo saben. Un ataque de fuerza bruta contra XML-RPC puede probar cientos de contraseñas en una sola llamada con el método system.multicall, lo que lo hace mucho más eficiente para el atacante que ir una por una contra el formulario de login.

Qué hacer:

• Si no usás apps móviles ni Jetpack: deshabilitá XML-RPC por completo. Podés hacerlo con un snippet en functions.php (add_filter('xmlrpc_enabled', '__return_false');) o desde la configuración avanzada de Wordfence. No perdés funcionalidad real si tu flujo de publicación es 100% web.
• Si necesitás XML-RPC: al menos bloqueá el método system.multicall, que es el que permite probar múltiples contraseñas en una sola petición. Wordfence lo bloquea por defecto en su configuración recomendada.

Otra vía menos conocida: la API REST de WordPress (/wp-json/wp/v2/users) expone los nombres de usuario públicos. Cualquiera puede hacer un GET y obtener la lista de usuarios con sus slugs. No es una vulnerabilidad en sí —es una feature de la API—, pero es información que el atacante usa para no desperdiciar intentos con nombres que no existen. Si no necesitás esa exposición, podés deshabilitarla con un filtro o con Wordfence.

Errores comunes al proteger WordPress de fuerza bruta

Después de 15 años viendo sitios caer por lo mismo, hay patrones que se repiten con puntualidad de tren suizo. Estos son los que más encuentro:

1. Instalar el plugin de límite de intentos y dejarlo con la configuración por defecto eternamente

La configuración por defecto de algunos plugins permite 20 intentos antes de bloquear. Con 20 intentos, un bot medianamente rápido ya probó las 20 contraseñas más comunes del planeta en menos de un minuto. Bajalo a 4 o 5 intentos como máximo. Si un usuario real necesita más que eso para acordarse su propia contraseña, el problema es otro —y para eso está el «olvidé mi contraseña». Cubrimos ese tema en detalle en blindar tu WordPress contra los hackers.

2. Activar 2FA solo para administradores y olvidarse de los editores

Un editor con contraseña débil y sin 2FA es una puerta lateral perfecta. El atacante no necesita entrar como administrador para hacer daño: desde un perfil de editor puede publicar contenido malicioso, modificar páginas existentes, inyectar redirecciones. El 2FA tiene que cubrir todos los roles con capacidad de escritura, no solo el admin. Si tuviera que reducirlo por resistencia de los usuarios —cosa que pasa—, mínimo editores y administradores.

3. Pensar que el WAF externo hace innecesario proteger a nivel WordPress

Cloudflare filtra una bocha, pero si el atacante descubre la IP real de tu servidor —y hay formas, como buscar registros DNS históricos o forzar mails de WordPress que revelen la IP—, puede pegarle directo salteando el proxy. La protección tiene que estar también en el servidor de origen. Siempre.

4. No monitorear los logs después de implementar las protecciones

Ponés todo en marcha, ves que el contador de intentos bloqueados sube, y te relajás. Pero los patrones de ataque cambian. Lo que en enero era fuerza bruta contra el formulario, en junio puede ser contra XML-RPC con multicall. Sin monitoreo, no te enterás de que hay una vía nueva que tus protecciones actuales no están cubriendo. Wordfence manda alertas configurables; activalas y leelas de vez en cuando.

Monitoreo continuo y mantenimiento de seguridad

La protección contra fuerza bruta no se instala una vez y se olvida: los patrones de ataque cambian y las configuraciones quedan viejas. Lo que sostiene la defensa a largo plazo es una rutina corta y constante, no una configuración perfecta hecha una sola vez. Así se ve esa rutina en la práctica:

Si querés profundizar en esto, tenemos un artículo donde explicamos paso a paso cómo «`html activar 2FA en WordPress con Wordfence. «`

Si querés profundizar en esto, tenemos un artículo sobre ataques de fuerza bruta donde explicamos cómo activar el 2FA en WordPress paso a paso.

Rutina semanal (cinco minutos):

• Revisar el contador de bloqueos del plugin: un aumento brusco respecto a la semana anterior anticipa campañas nuevas antes de que afecten el rendimiento.
• Chequear usuarios recién creados: un administrador que nadie creó es la señal más grave posible; significa que alguien ya entró.
• Leer las alertas por mail: Wordfence y Limit Login Attempts Reloaded avisan ante bloqueos masivos. Configurá el destinatario a una casilla que realmente revises, no a la bandeja del dominio que nadie abre.

Rutina mensual (quince minutos):

• Auditar roles y accesos: bajá la lista de usuarios, verificá que cada uno tenga el rol mínimo necesario y eliminá cuentas inactivas.
• Actualizar todo y probar el acceso: core, plugins y temas al día, y de paso verificá que tus códigos de respaldo del 2FA funcionen antes de necesitarlos de verdad.
• Mirar tendencias, no picos: recibir miles de intentos por día es ruido normal en cualquier dominio indexado. Lo que importa es si el volumen crece semana a semana o si aparece algún login exitoso desde una IP desconocida.

Según la documentación de Wordfence sobre fuerza bruta, la combinación de límite de intentos más bloqueo automático por IP detiene la gran mayoría de las campañas automatizadas antes de que consuman recursos del servidor. Si aun así el volumen escala, es la señal para sumar la capa WAF externa que vimos más arriba. Y un último consejo: documentá tu configuración —qué plugin, qué umbrales, quién recibe las alertas—. Cuando algo falle un domingo a las 3 de la mañana, ese documento vale oro.

Preguntas Frecuentes

¿Qué es un ataque de fuerza bruta en WordPress?

Es un ataque automatizado donde un script prueba miles de combinaciones de nombre de usuario y contraseña contra la pantalla de login de WordPress hasta encontrar una que funcione. A diferencia de ataques que explotan vulnerabilidades de código, la fuerza bruta no necesita bugs: solo necesita tiempo, poder de cómputo y que la contraseña sea débil o común.

¿Cómo detectar un ataque de fuerza bruta en mi sitio?

Los síntomas principales son degradación de rendimiento sin explicación, cientos de líneas POST a /wp-login.php en los logs del servidor, y consumo anómalo de CPU. Para confirmarlo, revisá el access.log de Apache o Nginx buscando peticiones repetidas desde la misma IP. Con Wordfence instalado, el dashboard muestra los intentos bloqueados en tiempo real con IP y país de origen.

¿Cuál es el mejor plugin para limitar intentos de login?

Limit Login Attempts Reloaded es el más instalado con más de 2 millones de activaciones, es gratuito y hace exactamente lo que promete sin agregar funcionalidades innecesarias. Si preferís un paquete completo de seguridad, Wordfence incluye limitación de intentos en su firewall gratuito junto con escáner de malware y 2FA. Cualquiera de los dos cumple, la elección depende de si querés una herramienta puntual o un combo integral.

¿El 2FA realmente detiene ataques de fuerza bruta?

Sí, detiene el 100% de los bots automatizados incluso si la contraseña fue robada o adivinada. El atacante necesitaría acceso físico a tu dispositivo TOTP o a tu llave U2F, algo que un script remoto simplemente no puede tener. Lo que no detiene el 2FA es un ataque dirigido con ingeniería social para robar el código en tiempo real, pero ese es un escenario completamente distinto y mucho menos frecuente.

¿Cuáles son los pasos manuales para proteger mi sitio sin plugins?

Sin plugins, las medidas de mayor impacto son: contraseñas únicas de más de dieciséis caracteres para cada usuario, restricción de wp-login.php por IP mediante .htaccess y desactivación del editor de archivos con DISALLOW_FILE_EDIT en wp-config.php. Sumado a mantener todo actualizado, este set cierra la mayor parte de la superficie automatizada. La limitación es clara: si tus usuarios entran desde IPs dinámicas, la restricción por IP deja de ser práctica y ahí el 2FA se vuelve imprescindible.

¿Dónde veo los registros de intentos fallidos de login?

En los logs de acceso del servidor: /var/log/apache2/access.log o /var/log/nginx/access.log, o desde la sección «Acceso bruto» de cPanel. Buscá peticiones POST repetidas a /wp-login.php desde la misma IP. Como WordPress no guarda estos intentos de forma nativa, para verlos dentro del panel necesitás un plugin como WP Activity Log o un snippet que registre el hook wp_login_failed.

Conclusión

El panorama de agosto de 2026 muestra una presión récord: el volumen de ataques de fuerza bruta contra WordPress se duplicó según Patchstack, y las campañas ahora consultan datos públicos del dominio para armar diccionarios personalizados. En ese contexto, detectar dejó de ser opcional. Los logs de acceso del servidor son hoy la primera señal delata­ble, visible días antes de cualquier síntoma de rendimiento, y revisarlos toma menos tiempo que escribir un ticket de soporte.

Bloquear, en cambio, sigue recetando lo mismo de siempre, precisamente porque funciona: límite de intentos, 2FA y URL de login personalizada forman una base gratuita que frena la enorme mayoría de los bots. La diferencia entre un sitio que aguanta y uno que cae casi nunca es el presupuesto; es haber aplicado esas tres capas y revisarlas con una rutina simple de seguimiento semanal y mensual.

De acá en adelante, tres tareas concretas: revisá hoy los últimos siete días de tu access.log buscando POST a wp-login.php; si todavía no tenés límite de intentos ni 2FA, instalalos esta semana; y agendá una auditoría mensual de usuarios, roles y actualizaciones. Media hora de trabajo inicial y quince minutos por mes. Comparado con limpiar un sitio comprometido, es la mejor relación esfuerzo-beneficio que existe en seguridad WordPress.

Fuentes

• WordPress.org — Ataques de fuerza bruta (documentación oficial)
• Wordfence — Protección contra fuerza bruta en el firewall
• WordPress.org — Plugin Limit Login Attempts Reloaded
• Ayuda WordPress — Fuerza bruta: qué es y cómo defenderse
• Seguridad en WordPress — Brute Force en WordPress: detección y bloqueo