WordPress brute force protection, 8 ways to stop login attacks
Every WordPress website is being tried by bots guessing usernames and passwords. Here is how WordPress brute force protection works, the 8 steps that stop login attacks, and how WPCentrify stops them on every site you manage.
The short answer
WordPress brute force protection stops bots from guessing their way into your website. Use strong, unique passwords and two-factor authentication, limit login attempts with lockouts that grow, close XML-RPC, hide usernames and turn attackers away before WordPress loads. On many websites, block an attacker everywhere once it has been seen anywhere.
Disclosure: WPCentrify is our product. Facts about WordPress and other tools come from their own pages, checked 31 October 2026.
What is a brute force attack on WordPress?
A brute force attack is an automated attempt to sign in to a WordPress website by trying username and password combinations until one works. Bots run through lists of common usernames and leaked passwords day and night, mostly against the login page (wp-login.php) and XML-RPC (xmlrpc.php). Most website owners never see it happening, but their server does: thousands of wasted requests, slower pages for real visitors, and sometimes a warning from the hosting company.
WordPress runs around 40 percent of all websites, according to W3Techs, and every one of them has the same login address, so every WordPress website on the internet is being tried. The attacks come in a few shapes:
| Kind of attack | What it looks like | What stops it |
|---|---|---|
| Simple guessing | One machine tries common passwords for admin, test or the site name | Strong passwords, no admin account, lockouts |
| Credential stuffing | Real username and password pairs leaked from other websites | A unique password for every website, two-factor authentication |
| Distributed attack | Thousands of machines each try a few passwords, so no single address trips a lockout | Limits on attempts per account, attackers blocked across many websites |
| XML-RPC amplification | One request to xmlrpc.php carries hundreds of guesses | XML-RPC sign-ins switched off or restricted |
How do you know your WordPress site is under attack?
You rarely see a brute force attack on the website itself. These are the signs to look for:
- A sudden rise in failed sign-ins in your security plugin or activity log.
- Many requests to
wp-login.phporxmlrpc.phpin your server access logs. - Sign-in attempts for usernames that do not exist on your website, such as admin, test or administrator.
- Pages that are slower than usual, or a hosting warning about CPU or memory use.
- Floods of password reset emails nobody asked for.
None of these means the attacker got in. A sign-in that succeeded after a run of failures is the one to act on straight away.
Why protecting each website on its own is not enough
Most security plugins protect one website on its own. That leaves two gaps. First, distributed attacks spread their guesses across thousands of machines, so each address only tries a few passwords and never reaches a lockout. Second, an attacker turned away from one website simply moves on to the next and starts again, and that website has no idea the attacker was just seen somewhere else.
That is why the strongest protection works on two levels: per account, so an attack aimed at one user from many places is slowed down, and across websites, so an attacker seen on several of them is turned away from all of them.
How to stop brute force attacks on WordPress, in 8 steps
Each step stops a different kind of attack, so use them together.
1. Use strong, unique passwords and never the username admin
Most brute force attacks are not clever. They try the passwords people actually use, against the usernames people actually choose. A long, unique password from a password manager defeats the guessing, and an account that is not called admin removes the first name on every bot's list.
Keep WordPress, plugins and themes updated too. A guessed password is one way in; an outdated plugin with a known hole is another, and attackers try both.
2. Turn on two-factor authentication for administrators
Two-factor authentication means a correct password is not enough: the person signing in also needs a code from their phone or a security key. The WordPress handbook on brute force attacks recommends it, and notes that WordPress core does not include it, so it comes from a plugin or your sign-in provider.
For a team that signs in to many client websites, one-click WordPress login from a dashboard means nobody has to share or store an admin password in the first place.
3. Limit login attempts with lockouts that grow
WordPress lets anyone try to sign in as many times as they like. Limiting login attempts fixes that: after a run of wrong passwords from one address, that address is locked out for a while. The best lockouts grow, so a bot that comes back is locked out for longer each time, and a bot that guesses usernames that do not exist is stopped almost at once, because a real person rarely forgets their own username.
One warning: lock out the attacker, never the account. If protection locks an account after wrong passwords, an attacker can keep you out of your own website just by guessing badly on purpose.
4. Close or restrict XML-RPC
XML-RPC (the file xmlrpc.php) is an older way for apps to talk to WordPress. It matters for brute force because one request can carry many sign-in attempts. In Cloudflare's own test of this technique, one request carried 1,000 sign-in attempts, so a login limiter that only counts visits to wp-login.php may never notice the guessing at all.
If nothing on your website uses XML-RPC, turn off password sign-ins through it. In a small plugin or your theme's functions file, this one line switches off the XML-RPC methods that need a password:
add_filter( 'xmlrpc_enabled', '__return_false' );Check first: Jetpack and some older mobile and publishing apps still use XML-RPC.
5. Stop username discovery and show one vague login error
You cannot guess a password without a username, and WordPress gives usernames away in several places. An author archive such as /?author=1 often redirects to an address containing the login name, the REST API can list the people who have published posts, and the login form tells a visitor whether the username they typed exists.
Close those leaks: hide usernames from author archives and the REST API for visitors who are not signed in, and show one vague message for every failed sign-in, whatever went wrong.
6. Protect the password reset and registration forms
The lost password and registration forms are doors too. Bots use them to test which usernames and email addresses exist, and to send floods of reset emails that bury real messages. Rate-limit both forms, and switch registration off entirely if your website does not need it. The same thinking applies to spam on your contact forms.
7. Turn attackers away before WordPress loads
A blocked attempt still costs something if WordPress has to load every plugin before it says no. Thousands of them slow your pages for real visitors and can earn a warning from your hosting company. Turn attackers away as early as you can: at a firewall or CDN, at the web server, or at the very start of the request, before the rest of WordPress loads. The WordPress handbook makes the same point: security plugins still run PHP for every attempt under a heavy attack, so rate limits at the edge spare the server.
8. Watch what was stopped and get alerted to real risk
Protection you cannot see is protection you cannot trust. Keep a count of what was stopped, but do not ask for an email per blocked bot: that is how important alerts end up ignored. The alert that matters is the rare one, someone signing in successfully after a run of wrong passwords, because that can mean a guess worked. If you suspect one did, follow our guide on what to do when a WordPress site is hacked, and check who changed what in the WordPress audit log.
Does hiding the login page or adding a CAPTCHA help?
A little. Moving the login page to a new address cuts some automated traffic, but bots still find it, and it does nothing for XML-RPC. A CAPTCHA or a quiet check such as Cloudflare Turnstile slows bots on the login form, but it adds a step for real people and, again, leaves XML-RPC open. Both are fine extras. Neither replaces lockouts, strong passwords and two-factor authentication.
Login limiter, security plugin, host firewall or network protection?
There are four common ways to add WordPress brute force protection, and they stop different things:
| Approach | Good at | Watch out for |
|---|---|---|
| Login limiter plugin on each site | Repeated guessing from one address | Distributed attacks; some only watch wp-login.php; runs after WordPress has loaded |
| Security plugin on each site | Lockouts plus extras such as two-factor and a firewall | Settings to tune on every site; knows only what it saw itself |
| Host or CDN firewall | Turning bot traffic away before it reaches the server | Depends on your host or CDN plan, and is set up outside WordPress |
| Network protection across many sites | Attackers seen on other websites, blocked early everywhere | Still needs strong passwords and two-factor authentication |
Jetpack, for example, gives sites running it free brute force protection. If you run one website, a well kept security plugin and strong passwords go a long way. If you look after many, the gaps above multiply with every website you add.
How WPCentrify protects your WordPress websites from brute force attacks
WPCentrify is a WordPress management tool that monitors, manages and secures multiple WordPress websites across your portfolio. It stops brute force attacks quietly on every website you manage, without another security plugin and without a single setting to tune. It is part of Sentinel, WPCentrify's WordPress security monitoring.
Protection that works together across every website
When an attacker shows up across several websites we look after, that attacker is recognized and turned away from the sign-in pages of every website on the WPCentrify network. A website can be protected from an attack before that attack has even reached it. Blocks are temporary and lift on their own, and they only apply to the sign-in pages, so a visitor who happens to share an internet connection with an attacker, in an office or on a mobile network, can still browse and buy as normal.
Stopping repeated guessing on every website
- Repeat offenders are locked out, and each time they come back the lockout gets longer.
- Guessing usernames that do not exist is treated as a clear sign of a bot, and is stopped almost straight away.
- Attacks spread across many machines are slowed down. When one account is targeted from many places at once, new arrivals are limited, while the real owner and the people who normally sign in carry on as usual. Accounts are never locked, so attackers cannot use the protection to keep you out of your own website.
- The password reset and registration forms are protected too, so attackers cannot use your website to flood inboxes.
Closing the doors bots rely on
Many attacks never touch the normal login page. They use older or hidden entry points most website owners have never heard of. WPCentrify closes these automatically on every website, so most automated traffic never gets as far as trying a password. Popular plugins that genuinely need those entry points, such as Jetpack, are recognized and keep working. WPCentrify also stops bots from easily discovering the usernames on your website, because you cannot guess a password without first knowing a username.
Light on your hosting
WPCentrify turns attackers away at the earliest possible moment, before the rest of the website has to load. Blocked attempts cost the server almost nothing and are not written to your database one by one, so your website stays fast for real visitors and your hosting company has nothing to complain about.
You can never be locked out of your own website
- One-click sign-in from the WPCentrify dashboard always works, even while an attack is being blocked.
- The people who normally sign in carry on as usual.
- Owners stay in control. Every protection appears as a simple switch in the Sentinel security screen. You can turn one off for a single website, or let a trusted address through, in a couple of clicks.
You see what was stopped
WPCentrify shows how many sign-in attempts were stopped on your websites, including those stopped by the network-wide protection, and sends a single weekly summary instead of a flood of alerts. If something genuinely needs your attention, such as someone signing in after a run of wrong passwords, you hear about it straight away.
On by default, on every plan
Brute force protection is not a premium extra. It is switched on by default for every website connected to WPCentrify, on every plan, including the free plan, and every website that joins makes the network a little stronger for everyone else. If you manage multiple WordPress sites, that is one less plugin to install, configure and update on each of them.
Your WordPress brute force protection checklist
- No account is called admin, and every administrator has a long, unique password.
- Two-factor authentication is on for every administrator.
- Login attempts are limited, and lockouts grow for repeat offenders.
- XML-RPC sign-ins are off, or restricted to the tools that need them.
- Usernames are hidden, and failed sign-ins show one vague message.
- The password reset and registration forms are rate-limited.
- Attackers are turned away before WordPress loads.
- You get one alert for a sign-in after failed attempts, not one per blocked bot.
For the rest of your security, see how to scan a WordPress site for malware and how to look after WordPress security for multiple sites.
Sources
- Brute Force Attacks, WordPress Developer Resources
- xmlrpc_enabled filter, WordPress Developer Resources
- A look at the new WordPress brute force amplification attack, Cloudflare, October 2015
- Brute force attack protection, Jetpack
- Usage statistics of WordPress, W3Techs
All sources checked on 31 October 2026.
Questions about WordPress brute force protection
A brute force attack is an automated attempt to sign in to a WordPress website by trying username and password combinations until one works. Bots run through lists of common usernames and leaked passwords day and night, usually against wp-login.php and xmlrpc.php.
Use strong, unique passwords and never the username admin, turn on two-factor authentication for administrators, limit login attempts with lockouts that grow, close XML-RPC if you do not need it, hide usernames and block attackers before WordPress loads. One layer alone is not enough, because each one stops a different kind of attack.
The usual signs are a sudden rise in failed sign-ins, many requests to wp-login.php or xmlrpc.php in your server logs, a slower site or a warning from your hosting company about high resource use. Sign-in attempts for usernames that do not exist on your website, such as admin or test, are another clear sign.
No. WordPress lets anyone try to sign in as many times as they like. You need a security plugin, your host, a firewall or a management tool such as WPCentrify to limit login attempts and lock out repeat offenders.
Yes. Every attempt that reaches WordPress makes the server do work, so thousands of attempts can slow pages for real visitors or use up your hosting resources, even when no password is ever guessed. That is why it helps to turn attackers away before the rest of WordPress loads.
Disable it, or at least password sign-ins through it, if nothing on your site uses it. XML-RPC lets one request try many passwords at once. Some tools still need it, Jetpack and older mobile apps among them, so check before you turn it off.
It cuts down some automated traffic, but it does not stop an attacker who finds the new address, and it does nothing for XML-RPC. Treat it as an extra, not as your protection. Lockouts, strong passwords and two-factor authentication do the real work.
Not on its own. Modern attacks spread their guesses across thousands of machines, so each address only tries a few times and never reaches a lockout. Good protection also slows attacks aimed at one account from many places, and blocks attackers already seen on other websites.
It stops a guessed password from being enough to get in, which is the outcome that matters most. It does not stop the attempts themselves, so the server still does the work, which is why two-factor authentication works best alongside lockouts and early blocking.
Badly built protection can, if it locks an account rather than an attacker. WPCentrify never locks accounts, the people who normally sign in carry on as usual, and one-click sign-in from the WPCentrify dashboard always works, even while an attack is being blocked.
A brute force attack guesses passwords, often from lists of common ones. Credential stuffing tries real username and password pairs leaked from other websites, betting that people reuse passwords. The same protection stops both, and a unique password for every website makes credential stuffing useless.
Yes. Brute force protection is switched on by default for every website connected to WPCentrify, on every plan, including the free plan. It is not a premium extra.
Related reading
Sentinel security monitoring
A plain-English security verdict for every WordPress site you manage, with login protection switched on.
See the featureWordPress site hacked?
What to do first, in order, if a password was guessed or a site was broken into.
Read the guideOne-click WordPress login
Sign in to any site you manage without sharing passwords, and close the login page for good.
See the featureMore on this topic: how to scan a WordPress site for malware and WordPress user roles and permissions.
Stop login attacks on every site you manage
WPCentrify turns brute force attacks away on every connected website, blocks attackers across the whole network, and never locks you out of your own site.
Plan prices to be revealed. Start free on one website today.
Explore related Sentinel security features
Manage repeated login attempts with brute force protection in WPCentrify.
Review unused remote access with xml-rpc protection in WPCentrify.