How to Stop WordPress Brute-Force Login Attacks

If your WordPress login page is getting hammered, the safest first move is to reduce how many guesses an attacker can make and make those guesses less useful. Start by backing up your site, then enable login protection, add rate limiting at the server or firewall level if available, and harden admin access with strong passwords and two-factor authentication.

Brute-force login attacks usually do not mean your site has already been hacked. They mean automated bots are trying username and password combinations until one works. The goal is to make those attempts expensive, noisy, and mostly useless.

What brute-force login attacks look like

You may notice repeated failed logins, a spike in traffic to /wp-login.php or /wp-admin/, alerts from your host or security plugin, or unfamiliar usernames being tried over and over. Sometimes there is no obvious symptom at all until server resources start climbing or a real user gets locked out.

Common signs include:

• Many failed login attempts from the same IPs or many different IPs
• Slow admin pages during attack bursts
• Security emails about blocked logins or suspicious activity
• Unexpected account lockouts after repeated guesses
• Bot traffic focused almost entirely on login URLs

If you are seeing actual unauthorized admin access, changed passwords, new admin users, file modifications, or malware warnings, that is no longer just brute force. Treat it as a compromise and move to a cleanup workflow such as WordPress Site Hacked? Here's How to Clean It Up — Safely.

Why brute-force attacks keep happening

WordPress login pages are public by design. Attackers know that many sites still use weak passwords, reused passwords, or common usernames such as admin. They also rely on the fact that many sites allow unlimited login attempts, return clues about usernames, or expose XML-RPC in ways that can be abused for password guessing.

The most common causes are not exotic:

• Weak or reused passwords
• Predictable usernames, especially admin
• No rate limiting on login attempts
• XML-RPC left open when it is not needed
• Missing two-factor authentication
• Shared hosting or a weak firewall with no bot filtering

The safest way to stop them

Work from least risky to most invasive. If you are not sure which layer you have access to, check your host control panel, your security plugin, and your firewall or CDN first. Always make a backup before changing login, plugin, or server rules.

1) Change the passwords that matter most

Start with every admin account, then any FTP/SFTP, hosting panel, database, and email passwords connected to the site. A brute-force attack on WordPress is often only dangerous if the same password is reused elsewhere.

Use long, unique passwords. A password manager makes this much easier and reduces the temptation to reuse credentials.

2) Remove or rename risky accounts

If you still have an administrator account named admin, create a new administrator account with a unique username, log in with that new account, and then delete or downgrade the old one if it is not needed. Also review user roles and remove any admin accounts that should not exist.

Do not just change display names. Attackers care about the actual username used to log in.

3) Add two-factor authentication

Two-factor authentication blocks a successful login even if a password is guessed. It is one of the most effective protections for WordPress admin accounts because it protects the login itself, not just the password.

Enable it for all administrator accounts and, if practical, for editors or anyone else with elevated access. Make sure you keep recovery codes in a safe place before you turn it on.

4) Limit login attempts or add rate limiting

You want the site to slow or block repeated failed logins from the same source. Many security plugins can do this, and some hosts or firewalls can enforce it before WordPress loads. That is better than relying only on WordPress itself because it reduces load on the server.

If you use a plugin, choose one that can:

• Lock out repeated failures after a small number of tries
• Increase delays between attempts
• Alert you when lockouts spike
• Whitelist trusted IPs only when necessary

Be careful not to lock yourself out. If you administer the site from a fixed IP, note that address before enabling aggressive limits.

5) Protect or disable XML-RPC if you do not use it

XML-RPC is a WordPress feature that can be useful for some apps and services, but it is also a common target for login abuse. If you do not need it, disable it at the firewall or application layer if your host supports that. If you do need it, protect it with host-level rules or a security layer that understands WordPress traffic.

Whether you can safely disable XML-RPC depends on your setup. Some plugins, mobile workflows, or publishing tools still rely on it. Check first, then test after any change.

6) Use a firewall or CDN to block bot traffic earlier

A web application firewall can stop obvious attack patterns before they reach WordPress. This is especially useful when bots rotate IPs or hit your site from many locations. Cloud-based firewalls and some managed WordPress hosts can filter bad login traffic without you having to maintain blocklists manually.

This is one of the best places to stop attacks because it protects the login endpoint and reduces server load at the same time.

7) Hide usernames from easy discovery

Attackers often try to discover valid usernames through author archives, REST endpoints, or public content. If your site exposes author slugs or usernames publicly, that gives them a head start. Some security plugins and hardening settings can reduce this exposure, though the exact method depends on your theme and WordPress version.

Do this carefully. Do not break author pages or APIs your site actually needs. Test after changing any username visibility setting.

8) Tighten admin access where possible

If your workflow allows it, you can add extra restrictions around the login area. Some sites use IP allowlisting for /wp-admin/, especially on internal or low-traffic sites. Others protect the login page with basic authentication at the server level.

These measures are effective, but they can also block legitimate users, mobile admins, or remote contractors. Use them only if you can support the added friction.

What not to do

Do not rely on obscurity alone. Renaming /wp-login.php or using a hidden login URL may reduce generic bot noise, but it is not a complete defense. If your password policy is weak, your site is still exposed.

Do not install multiple security plugins that all try to manage logins. Overlapping rules can create false lockouts, compatibility issues, and confusing alerts. Pick one security approach and test it.

Do not wait to patch WordPress, plugins, and themes. Attackers often combine brute-force attempts with known vulnerabilities. Keeping software updated is part of the defense, not separate from it.

How to tell whether the attack is under control

You should see fewer failed attempts reaching WordPress, fewer login-related alerts, and less load on the site during attack windows. If your firewall or plugin reports lockouts, the counts should settle down after the initial spike.

Watch for:

• Stable admin access for real users
• No unexplained new admin accounts
• No repeated login attempts after protections are enabled
• Normal server performance during busy periods

If attacks continue at a high rate after you have added rate limiting, 2FA, and firewall protections, the issue may be broader than WordPress alone. In that case, the host or network layer may need attention.

How to prevent the next wave

The best long-term defense is layered protection. Use unique passwords, two-factor authentication, a sensible login limit, and a firewall that can block malicious traffic early. Keep users to the minimum roles they need, and review admin accounts regularly.

It also helps to make recovery easy. If a bad login attempt turns into a real problem, a recent backup and a tested restore path matter more than almost anything else. If you have not tested your backup restore process recently, read The Backup Test Most WordPress Sites Never Do.

For ongoing prevention, a managed maintenance plan can keep WordPress updates, backups, security monitoring, and uptime checks moving together instead of leaving you to assemble them piecemeal. That is the kind of setup many site owners choose through Mend Care Plan when they want less security firefighting.

When to call a professional

Call for help if you are locked out of wp-admin, if your site keeps getting hit after you add protections, if your host is flagging abusive traffic you do not know how to filter, or if you suspect the attacker already got in. Also call a professional if you need to harden a busy site without breaking logins for your team.

If you want a senior engineer to handle the hardening for you, Mend can triage the issue first with a free diagnosis and quote a flat price before any work starts. For active incidents, the Emergency Rescue path is the fastest option, and for smaller login hardening jobs, Quick Fix is often enough. Access is handled securely through the Mend Connect plugin, so no passwords are shared.

Brute-force attacks are annoying, but they are usually very fixable once you stop treating the login page as a soft target. Put the controls in layers, test them, and keep your recovery path ready.