WordPress Brute-Force Attacks: Stop Bot Login Spam

If bots are hammering your WordPress login page, the fastest safe fix is to block repeated attempts at the edge, add layered login protection, and confirm your admin accounts are still secure. Don’t just hide the login page and hope for the best; stop the attack patterns first, then harden the site so the same traffic doesn’t come back through another door.

Brute-force login attacks usually look noisy rather than subtle: dozens or thousands of failed logins, alerts from your host, a slow admin area, or security plugin notifications about repeated authentication failures. On some sites, the attack is mostly background noise. On others, it causes real problems such as CPU spikes, database strain from failed sessions, lockouts for real users, or a compromised account if a weak password gets guessed.

This article focuses on a fresh, practical angle: what to do when bot login spam is the problem and you need to reduce it quickly without locking yourself out or breaking legitimate logins. If you also suspect the site has already been compromised, stop here and read WordPress Site Hacked? Here's How to Clean It Up — Safely first.

What brute-force login attacks actually do

A brute-force attack is a high-volume guessing game. Bots repeatedly try username and password combinations against wp-login.php, XML-RPC endpoints, or other auth surfaces. Most attempts fail, but the traffic still costs something: server resources, log noise, and sometimes account lockouts or suspicious password reset activity.

WordPress itself is not “broken” by these attacks, but the surrounding environment can be stressed. Shared hosting often shows this first because CPU and entry-process limits are lower. Managed hosts may absorb the traffic better, but you’ll still want to reduce it.

Signs the attack is real, not just normal traffic

• Repeated failed login alerts from your host or security plugin
• Dozens of attempts from the same IPs or many rotating IPs
• Slow admin logins or intermittent lockouts
• Unexpected password reset requests
• XML-RPC login attempts in logs, even when no one is using Jetpack or remote publishing
• New user accounts, changed email addresses, or admin role changes you did not make

If you see unauthorized changes, treat it as a possible compromise, not just an attack. Brute force often leads to takeover when a weak password, reused password, or stale admin account is available.

The safest way to stop it

Before changing anything, back up the site. If your host provides one-click backups, use it. If not, create a fresh backup through your backup tool or host panel. Security changes are usually safe, but it is still wise to have a restore point before you tighten access.

1) Confirm the attack surface

Check whether the login traffic is hitting /wp-login.php, /wp-admin, XML-RPC, or a custom login URL from a plugin. This matters because different protections work better at different layers. Your host logs, security plugin logs, or a web application firewall dashboard can help.

If the attacker is using XML-RPC, you may not need to disable it entirely. Some sites still use it legitimately through Jetpack, the WordPress mobile app, or remote publishing tools. Disable it only if you know you do not need it.

2) Put rate limiting in front of the site

The most effective fix is to stop bad requests before WordPress has to process them. A firewall, CDN security layer, or host-level rate limiting can block repeated login attempts by IP, country, or request pattern. This is usually better than only relying on a WordPress plugin, because it reduces load before PHP and MySQL are involved.

If your host offers login protection or brute-force mitigation, turn it on. If you use a CDN or WAF, add a rule for excessive requests to login endpoints. If you use a security plugin, enable its brute-force protection, but do not assume it is enough on its own for a busy attack.

3) Add login throttling and two-factor authentication

Two-factor authentication is one of the best defenses for WordPress admin accounts because a guessed password still won’t be enough. Enable it for every user who can edit content, install plugins, or access critical settings. For sites with multiple editors, this is often the best long-term control after rate limiting.

Login throttling is also useful. It temporarily delays or blocks repeated failures from the same IP or account. Set it conservatively so real users are not punished for a typo. If you are unsure, start with gentler limits and monitor the results for a day or two.

4) Remove weak or unused admin accounts

Attackers look for old accounts, shared admin usernames, and users with predictable roles. Go to Users and review every account. Delete accounts that are no longer needed, downgrade anyone who does not require admin access, and make sure no one is still using admin or another obvious username.

Also check for stale staging users that were copied to production. Those accounts are easy to forget and often retain elevated privileges longer than they should.

5) Reset passwords for all privileged users

If the attack has been going on for a while, change passwords for every admin and editor account, not just one. Use long, unique passwords stored in a password manager. If the same password was reused elsewhere, change it there too.

Do not send passwords by email or chat. WordPress passwords should be reset through the built-in process or directly by the account owner. If you are locked out during this process, the guide Locked Out of WordPress Admin: Why It Happens and How to Fix It can help.

6) Harden the login page carefully

Some owners try to “hide” wp-login.php with a plugin. That can reduce noise, but it is not a complete defense. It can also create support headaches if the plugin breaks, caches the login page incorrectly, or interferes with password resets.

If you do rename or move the login URL, document it clearly and test recovery steps before relying on it. Make sure you know how to disable the plugin from the file system if you get locked out. Hiding the login page is best treated as an extra layer, not the primary fix.

7) Protect XML-RPC only if you can afford to

XML-RPC is a common brute-force target because it can accept many login attempts in a single request. If your site does not need it, block it at the server or firewall level. If you do need it, restrict it with a WAF or security plugin rather than disabling it blindly.

Site behavior here is host-dependent. Some managed hosts already throttle XML-RPC aggressively; others do not. Test legitimate features after any change.

8) Check whether bots are bypassing the login form

Some attacks do not hit the visible login page at all. They try REST API auth flows, XML-RPC methods, or even password reset forms. Review logs for patterns, not just page views. If you only block one endpoint, the bot may move to the next one.

A good security setup watches all auth-related surfaces, not just wp-login.php.

What not to do

• Do not install three different security plugins that all try to block logins in different ways
• Do not block all anonymous traffic to the whole site unless you are running a private site
• Do not disable password resets unless you have another recovery process
• Do not assume changing the login URL alone has “fixed” the problem
• Do not ignore the attack if account alerts keep appearing

The goal is to reduce attack volume and protect accounts without breaking normal use. A heavy-handed fix can leave you with the same security problem plus a support problem.

How to tell if the site has already been breached

Brute-force attacks are sometimes just noise, but they are also a common path to compromise. Look for signs such as new admin users, strange plugin installations, changed site URLs, injected links, altered homepage content, or outbound spam. If you see any of that, take a full incident response approach rather than only tightening login protection.

If you want a safe walkthrough for that situation, start with WordPress Site Hacked? Here's How to Clean It Up — Safely. If you are not sure whether the issue is just attacks or a deeper infection, the safest next step is a triage review through free diagnosis.

How to prevent brute-force attacks from becoming a repeat problem

Prevention is mostly about layered controls and basic account hygiene. Use unique passwords, enable two-factor authentication, keep admin access limited to the people who truly need it, and make sure your host or firewall is filtering abusive traffic before it reaches WordPress.

Regular updates matter too. Security plugins, themes, and WordPress core are not a substitute for login protection, but outdated code can make recovery harder if something goes wrong. For a safe update process, see How to Safely Update WordPress Plugins, Themes, and Core.

Finally, test your backup and recovery plan. If a security change locks out the wrong user or a host rule blocks a legitimate workflow, you need a quick rollback path. A restore test is worth doing before you are under pressure, not after.

When to call a professional

Bring in a WordPress engineer if the attack is causing downtime, if you cannot tell whether the site is compromised, if your host is rate-limiting legitimate visitors, or if login protections are locking out real users. It is also worth getting help if you need to protect a business site quickly and do not have time to test every change.

Mend can usually handle this fast with a backup-first workflow, a plain-English root-cause report, and flat upfront pricing. If you want a senior engineer to inspect the login surface, harden the site safely, and confirm whether the attack is just brute force or something worse, start with free diagnosis. For urgent sites, Emergency Rescue is the fastest path.

If you want ongoing protection after the immediate problem is fixed, a managed plan with updates, backups, security monitoring, and uptime monitoring can keep the same issue from coming back. You can review that at Care Plan.

Bottom line: stop brute-force attacks at the edge, secure every admin account, add two-factor authentication, and verify the site is not already compromised. That combination fixes the problem safely without turning your login page into a maintenance project.