Brute force attacks on WordPress, and what actually stops them

Every WordPress site on the internet receives login attempts constantly. If you installed a security plugin recently and were alarmed by the numbers, this is normal — it has been happening the whole time, you just could not see it.

Here is what is actually going on, and which defences matter.

What you are seeing

Bots scan the internet for /wp-login.php and /xmlrpc.php and try credentials. Nobody chose your site. There is no person at the other end.

Two distinct things get lumped together:

Brute force — trying many passwords against one username. Slow, noisy, and largely obsolete because it is easily blocked.

Credential stuffing — trying username and password pairs leaked from other breaches. This is the real threat. It is not guessing; it is checking whether you reused a password from a site that got breached. Far fewer attempts, far higher success rate, and rate limiting barely touches it because each pair is only tried once.

What actually stops them

Two-factor authentication. The complete answer. A correct password is no longer sufficient, so both attacks fail regardless of how many attempts are made. Ten minutes to set up.

Unique passwords. Kills credential stuffing at the source. If the password on your site exists nowhere else, a leak elsewhere is irrelevant.

A username that is not "admin". Halves the attacker's job when it is predictable. Not a defence on its own, but free.

Rate limiting. Locks an IP out after a few failures. Genuinely useful against brute force, mostly cosmetic against credential stuffing, and valuable for a different reason — see below.

Blocking xmlrpc.php multicall. XML-RPC allowed hundreds of password attempts in a single request, which made brute force cheap. Restrict the system.multicall method rather than disabling XML-RPC entirely, which breaks the mobile app.

The real cost of the attempts

Even when they all fail, the traffic costs you something. Every attempt is a full WordPress load: PHP runs, the database is queried, resources are consumed. On shared hosting, a sustained wave can slow the site noticeably or trip a resource limit.

That is the genuine argument for rate limiting — not that it prevents a breach, but that it stops your server doing pointless work.

Why the numbers in your report mean little

"4,281 attacks blocked this month" is a number chosen because it is large. It tells you bots exist, which was already true.

What would actually be worth reporting: whether any attempt succeeded, whether any came from a credential pair that matches a known breach, and whether any account is being targeted specifically rather than sprayed. Almost no report tells you that. More on reports worth reading.

What to do, in order

1. Two-factor on every administrator. This alone closes the category.
2. Unique password on every admin account, generated by a password manager.
3. No predictable usernames.
4. Rate limiting — to protect resources, not primarily to protect access.
5. Restrict XML-RPC multicall.
6. Stop reading the block counts. They are weather, not signal.

Twenty minutes of work for the first three, and then the login is effectively not the way in any more.

Which matters, because attention spent on login noise is attention not spent on the thing that actually compromises sites — an outdated plugin with a published flaw. The login page is loud; the vulnerable plugin is silent. Guess which one gets fixed.