Protect wp-login from brute force

Protecting wp-login from brute force means closing the one entry point every bot already knows by heart. On an unmodified WordPress install, the login page always sits at the same address, and the bots know it. The result: thousands of sites get hit every day by waves of automated attempts running through username and password combinations one after another. Here’s how to cut off that traffic and shut the door before a weak password gives way.

why wp-login.php and xmlrpc.php get hammered so much

WordPress puts its login page at a fixed address: yoursite.com/wp-login.php (or yoursite.com/wp-admin/, which redirects to the same thing). That URL is identical across millions of sites. So a bot has nothing to guess: it already knows the address and goes straight to the attack.

xmlrpc.php is the other target. This file powers the XML-RPC protocol, historically used by the WordPress mobile app, by some plugins, and for pings between sites. The problem: it lets an attacker send hundreds of password guesses in a single request thanks to the system.multicall method. For an attacker, that’s far more efficient than pounding wp-login.php one attempt at a time.

In practice, these attacks cause three things:

• Server load climbing. Each attempt eats memory and CPU. At scale, the site slows down or goes offline.
• Saturated logs and a flood of alerts if you’ve set any up.
• The real risk: if your admin password is short or reused elsewhere, the bot eventually finds it. From there, it has access to your dashboard.

The good news is that most of these attacks are dumb and automated. A few simple measures are enough to make them useless.

the basics: a strong password and two-factor authentication

Before any technical setting, fix the password. A brute-force attack only succeeds if the password is guessable. With a long, random, unique password, even millions of attempts lead nowhere.

• Use at least 16 randomly generated characters, stored in a password manager (Bitwarden, 1Password, KeePass).
• Never reuse this password anywhere else. If another breach exposes it, your WordPress goes down with it.
• Check every admin account, not just yours. An old forgotten account with a weak password is an open door.

Then add two-factor authentication (2FA). This is the measure that changes the most: even with the right password, the attacker doesn’t get in without the temporary code generated on your phone. Plugins like WP 2FA, Two-Factor (the official one), or Wordfence’s 2FA module install in a few minutes and work with an authenticator app (Google Authenticator, Authy, and so on).

If you were only going to do two things, these would be them.

limit the number of login attempts

By default, WordPress lets you try a password as many times as you want. A login-limiting plugin blocks an IP address after a set number of failures (say five), for a duration you choose.

Limit Login Attempts Reloaded is the most common option and it’s free. After installing, the defaults are mostly fine: number of allowed attempts, lockout duration, and an option to block XML-RPC attempts too. Wordfence and iThemes Security (now Solid Security) include the same feature if you’d rather use an all-in-one tool.

This measure doesn’t hide the page, but it makes brute force useless: a bot that gets only five tries every twenty minutes goes nowhere.

hide or rename the login page

If bots can’t find wp-login.php anymore, they can’t attack it. The WPS Hide Login plugin moves the login page to an address of your choice, for example yoursite.com/my-private-access. Any attempt to reach the old URL returns a 404 error.

It’s quick to set up and brutally effective against automated traffic, which only hits the standard address. Two things to watch:

• Note the new address carefully and save it in your password manager. If you forget it, you’ll have to disable the plugin over FTP to get back in.
• This isn’t absolute protection, just shelter from the noise. Keep a strong password and 2FA behind it anyway.

disable xmlrpc.php if you don’t use it

Most sites no longer need XML-RPC. If you don’t publish from the WordPress mobile app and no plugin requires it (Jetpack is one, check before), disable it.

The simplest method, without a plugin, goes through the .htaccess file at the root of the site, at the top of the file:

# Bloquer l'accès à xmlrpc.php
<Files xmlrpc.php>
  Require all denied
</Files>

On an older Apache setup, use this instead:

<Files xmlrpc.php>
  Order Deny,Allow
  Deny from all
</Files>

After saving, test the site and the admin login. If everything works, XML-RPC attempts are shut down. You can also get the same result with a plugin like Disable XML-RPC if you’d rather not touch .htaccess.

add a CAPTCHA

A CAPTCHA on the login form stops bots that can’t solve it cold. Several plugins add one in a few clicks: Google reCAPTCHA, hCaptcha, or the CAPTCHA modules built into Wordfence and Solid Security.

Favor an invisible or low-friction version (reCAPTCHA v3, for example) so you don’t bother your real users on every login. It’s one more layer, useful mainly if you have client or subscriber accounts and can’t hide the page.

restrict wp-admin and wp-login by IP via .htaccess

If you always log in from the same IP address (an office with a static IP, for instance), you can block everything else. This is the strictest protection. Add this block to the .htaccess at the root:

# Restreindre wp-login.php à des IP autorisées
<Files wp-login.php>
  Require ip 203.0.113.42
  Require ip 198.51.100.7
</Files>

Replace the addresses with your own (find your public IP by searching “my IP” on a search engine). You can allow several, one per line.

A warning: only do this if your IP is stable. With a consumer connection whose IP changes regularly, you risk locking yourself out. In that case, stick with attempt limiting and page hiding. If you lock yourself out by accident, you’ll have to edit or delete this block over FTP to regain access.

change the “admin” username

An attacker needs two things: the username and the password. If your account is called admin, you’re handing them half the work. Plenty of brute-force attacks assume the account is named admin for exactly that reason.

WordPress doesn’t let you rename a username directly, but the workaround is simple:

1. Create a new admin account with a non-obvious username (avoid your first name alone or the site name too).
2. Log in with this new account.
3. Delete the old admin account, assigning its content to the new account when WordPress offers.

While you’re at it, check that your username doesn’t show up publicly in author URLs (/author/your-username/), which would hand it to the bots.

put up an application firewall

An application firewall (WAF) filters malicious traffic before it reaches WordPress. It blocks known attack patterns, including brute force, without you having to tune every detail.

Two approaches:

• A plugin-level WAF, like Wordfence or Solid Security. Easy to install, it acts inside WordPress.
• A network-level WAF, like Cloudflare or Sucuri, which filters traffic before it even touches your server. That’s more effective against large attacks and it takes load off your hosting.

For most site owners, free Cloudflare plus a security plugin already gives a solid level of protection.

frequently asked questions

Do I need to set everything up at once? No. Start with a strong password, 2FA, and attempt limiting. Those three measures cover most of the risk. The rest gets added as you need it.

Is hiding the login page enough? It removes almost all bot traffic, but it isn’t complete protection. Keep a strong password and 2FA behind it, in case the address leaks.

Can disabling xmlrpc.php break my site? Only if a service depends on it (the WordPress mobile app, Jetpack, some remote publishing tools). Check your plugins, test after the change, and keep a backup before.

what if the damage is already done

These measures protect a clean site. If you have any doubt about an intrusion already underway, see what to do if the site is already compromised before hardening anything. To dig into the causes, read why WordPress sites get hacked, and for the full hardening rundown, keep the complete security checklist handy.

Suspect your site is already affected? WP-Detox runs a free scan to tell you where you stand. If a cleanup is needed, we handle it in about thirty minutes, for €149 all-in, with a backup taken before any work. If we can’t clean it, you get refunded.