By default WordPress allows unlimited login attempts. Automated bots exploit that by hammering /wp-login.php with large-scale automated attacks per minute. Without a protective layer, the question is not whether a breach will happen, but when a weak password will fall.
Why this matters
A large share of WordPress site breaches start with a successful brute-force attack against a privileged user. Modern bots use credential-stuffing lists - username and password combinations stolen in unrelated breaches. If a user on your site reused the password they had on LinkedIn, Adobe or Dropbox before those leaked, the pair is already in the list and a bot that knows their username can sign in on the first try. Beyond security, untreated brute force creates real server load. A site on shared hosting receiving 200,000 login attempts a month will see slowdowns, resource overage charges, and occasional account suspensions from the provider.
How to detect
The audit looks for signatures of well-known protection plugins: Wordfence, Solid Security, Limit Login Attempts Reloaded, Loginizer, ITSec. It checks the active plugins list and the presence of their hooks. Manually: open the failed-login log (typically /wp-admin/admin.php?page=wordfence-login-security) or query wp_login_failed - if you see hundreds of rows from different IPs within a few hours, you are under attack.
How to fix
- Layer 1 - rate limiting. Install Wordfence (free) or Limit Login Attempts Reloaded. Set IP blocking to 5 failed attempts, lock-out for 15 minutes, and a 24-hour ban on repeat offenders.
- Layer 2 - two-factor authentication. Enable 2FA for every administrator and editor. Wordfence Login Security (free) or Two Factor Authentication offer TOTP (Google Authenticator). This is the single most important defence - even if the password leaks, the attacker cannot get in without the code.
- Layer 3 - hidden login URL. Move /wp-login.php to a random slug via RankPlus or WPS Hide Login. It is not a replacement for the first two layers but it removes 99% of log noise.
- Add reCAPTCHA to the login form - it blocks automated bots that cannot solve the challenge.
- Consider geo-blocking countries you do not serve - if your audience is Hebrew or English, blocking traffic from China, Russia or Vietnam at the firewall edge (Cloudflare, Sucuri) is fast and effective.
- Block /xmlrpc.php as well - it is a parallel brute-force vector that bypasses /wp-login.php protections.
Common mistakes
Do not rely on rate limiting alone - 2FA is essential. An attacker with a credential-stuffing list can succeed on the first try from a clean IP, and no rate limit will catch that. Do not enable reCAPTCHA without testing the theme - sometimes the widget fails to load and locks admins out. Do not assume a honeypot alone is enough - it stops only the simplest bots. Do not lock yourself out by mistake; have an emergency path ready (FTP, an mu-plugin that disables the protection plugin).
Verifying the fix
From a different device, try to sign in six times with the wrong password - you should be blocked. Verify 2FA: sign out and back in, and a code prompt should appear. Check the logs after a week - real blocks should show up (Wordfence > Login Security > Activity).