🔧 Flat-price WordPress fixes from $69 — start with a free diagnosis, no card. Get a free diagnosis →

Security

Stop WordPress Brute-Force Login Attacks Fast

Sep 10, 2026 · 10 min read · By the Mend engineering team

If bots are hammering your login page, the fastest safe fix is to limit or block repeated login attempts, harden your login page, and check whether your site is already compromised. Start with backups, then add protection at the edge or in WordPress, because brute-force traffic can be a nuisance on its own or a sign of a deeper security problem.

The goal is not to “win” against every bot forever. It is to make your login system expensive to attack, easy to monitor, and hard to abuse even if your username is known.

What brute-force login attacks look like

Brute-force attacks are automated attempts to guess your WordPress username and password. Most are noisy and repetitive, but some are slow and distributed, which makes them harder to spot.

You may notice:

  • Repeated login failures in your security plugin or host logs
  • Slow admin pages because of constant authentication attempts
  • Unexpected account lockouts for real users
  • Spammy XML-RPC or REST API requests, depending on the attack pattern
  • Email alerts about failed logins, sometimes in bursts at odd hours

In many cases, the site still works normally on the front end. That does not mean you can ignore it. Repeated login attacks can waste server resources, fill logs, trigger account lockouts, and sometimes succeed if weak passwords or leaked credentials are in play.

The likely causes

WordPress is a common target because it is widely used and its login endpoints are predictable. Attackers often rely on a few things:

  • Weak or reused admin passwords
  • Publicly known usernames like “admin”
  • Unrestricted login attempts at /wp-login.php
  • XML-RPC enabled when it is not needed
  • No rate limiting, firewalling, or 2FA
  • Leaked passwords from other sites that get tried here too

If your site was recently migrated, restored, or handed over by another team, also check whether old admin accounts still exist. Brute-force attacks become much more dangerous when there are unused accounts, stale passwords, or poorly protected hosting panels.

Step 1: Make sure the site is not already compromised

Before you harden anything, confirm that this is truly just login abuse and not a breach. If an attacker has already logged in, changing one setting will not solve the underlying problem.

Look for these warning signs:

  • Unknown admin users
  • New plugins or themes you did not install
  • Redirects, injected code, or strange popups
  • Sending email from WordPress that you did not configure
  • Hosting alerts about malware or suspicious files

If anything looks off, follow a proper cleanup path first. Our guide on how to clean up a hacked WordPress site safely explains the safer order of operations. If you are seeing lockout symptoms instead, Locked Out of WordPress Admin: Why It Happens and How to Fix It covers account recovery without making the problem worse.

Step 2: Back up before changing security settings

Even security changes can break logins for real users, especially on sites with membership features, custom login plugins, SSO, or aggressive host firewalls. Back up the database and files first, and if possible test the backup restore path too.

If you want a practical backup approach that does not become busywork, read The Smart WordPress Backup Plan and Restore Test or A Sensible WordPress Backup Strategy You Can Actually Use.

Step 3: Add login rate limiting

The most effective first defense is to limit repeated login attempts. You can do this with a security plugin, a host-level firewall feature, or a web application firewall. The safest option depends on your stack, but the outcome should be the same: repeated failures from the same source should slow down or stop.

When choosing a method, prefer:

  • Server-side or firewall-based rate limiting when your host provides it
  • A reputable security plugin if you manage the site yourself
  • Lockout rules that expire automatically, so real users are not blocked forever

Be careful with overly strict settings. Too many failed attempts from shared office IPs, mobile carriers, or legitimate users who mistype passwords can create support headaches. Start conservatively, then tighten as needed.

Step 4: Protect the login page itself

WordPress login protection usually works best in layers. Here are the safest and most useful additions:

  • Use strong passwords for every admin, editor, and host account.
  • Enable two-factor authentication for accounts that can publish, install, or update.
  • Rename or hide the login path only if your setup supports it cleanly; some custom-login plugins can conflict with caching, SSO, or membership tools.
  • Restrict access by IP if only a small team needs admin access and your IPs are stable.
  • Require CAPTCHA sparingly if bots are overwhelming the form and your audience can tolerate the friction.

Two-factor authentication is one of the best returns on effort. If a password is reused or leaked elsewhere, 2FA can stop the attack from becoming a real compromise.

Step 5: Decide whether to block XML-RPC

Many brute-force campaigns use xmlrpc.php because it can be abused for login attempts and pingback spam. If you do not need XML-RPC for Jetpack, remote publishing, or another specific integration, disabling or restricting it can remove an easy attack path.

Do not disable it blindly on sites that depend on it. Some hosts, plugins, or integrations still use XML-RPC, and turning it off can break legitimate workflows. If you are unsure, check your plugin list and host documentation before changing it.

Step 6: Add a firewall or CDN in front of the site

A web application firewall or CDN can block obvious bot traffic before it reaches WordPress. This is especially useful if attacks are causing load spikes or filling logs faster than WordPress plugins can handle them.

Look for protections such as:

  • Login rate limiting
  • Bot filtering
  • Country or ASN blocking when appropriate
  • Rules for /wp-login.php and /xmlrpc.php

This layer is often the best place to absorb the noise. It reduces server work and can also protect against other common attacks. But do not treat it as your only defense; keep strong credentials and 2FA in place.

Step 7: Clean up weak points that make attacks easier

Brute-force attempts are much more dangerous when the site has avoidable weak points. Tighten these up:

  • Delete unused admin accounts
  • Rename administrator roles where practical through proper user management, not hacks
  • Review password reset settings and user registration behavior
  • Remove outdated plugins and themes you do not use
  • Keep WordPress, plugins, and themes updated on a safe schedule

It is also worth checking whether your site is slow or unstable, because attackers often generate the same load that exposes performance problems. If brute-force traffic is contributing to general slowness, our guide on Speed Up WordPress: Why Your Site Is Slow and How to Fix It can help you separate security issues from performance issues.

How to monitor the problem after you fix it

Once protections are in place, watch for a few days. You want to know whether the attack is blocked, whether legitimate users are being affected, and whether there is a second problem hiding behind the login noise.

Monitor:

  • Failed login counts
  • Lockout events
  • New admin account creation
  • Changes to plugin or theme files
  • Traffic spikes to login endpoints

If your host provides logs, check whether the requests are coming from one IP, a small set of IPs, or a distributed network. Distributed attacks usually need edge-level protection rather than a simple IP block.

How to prevent brute-force attacks long term

The best long-term setup is layered and boring, which is exactly what you want. Use a strong password manager, 2FA for privileged accounts, automatic backups, timely updates, and a firewall or security layer that can rate limit login abuse.

For sites that cannot afford downtime or lockouts, a managed care plan can be the difference between “annoying” and “handled.” Mend’s Care Plan covers updates, backups, security, and uptime monitoring, which is useful if you want ongoing protection without maintaining it yourself.

When to call a professional

Bring in a WordPress engineer if you see any of the following: repeated lockouts across multiple users, suspicious admin accounts, malware warnings, blocked payment or membership logins, or attacks that keep returning after you harden the site. You should also get help if your host says the site is abusing resources or if you are not sure whether XML-RPC, caching, SSO, or a firewall change will break something.

If you need a fast diagnosis, start with free diagnosis. If the site is under active attack or you are already locked out, Emergency Rescue is the better path. Mend’s senior engineers work backup-first, usually fix the issue the same day, and send a plain-English report showing the root cause and exactly what changed. If you want to connect the site securely without sharing passwords, use Mend Connect.


Brute-force login attacks are common, but they are manageable. The practical fix is not one plugin or one setting; it is layered protection, strong credentials, and monitoring that tells you when the story changes from “bots are noisy” to “someone got in.”

If you want a broader playbook for login abuse, read WordPress Brute-Force Attacks: Stop Bot Login Spam after this article for another angle on the same problem.

Frequently asked questions

Should I disable XML-RPC to stop brute-force attacks?

Maybe, but only if your site does not need it for legitimate features. It can reduce attack surface, but disabling it blindly can break plugins or workflows that depend on it.

Is a CAPTCHA enough to stop login bots?

No. CAPTCHA can help, but it should be one layer in a larger setup that includes rate limiting, strong passwords, and 2FA.

What’s the safest first step if I think my site is under attack?

Back up the site, then check whether there are any signs of compromise. After that, add login rate limiting and stronger authentication controls.

How do I know if this is brute-force traffic or a hacked site?

Brute-force traffic usually shows repeated failed logins with no file changes or strange users. If you find unknown admin accounts, altered files, or redirects, treat it as a security incident and clean it up first.