A WordPress brute force attack is a bot that tries many username and password pairs against wp-login.php or xmlrpc.php until one works. You stop it with limits on login attempts, long unique passwords, two-factor login for admins, and by restricting xmlrpc.php if you do not use it.
That summary follows the WordPress developer documentation on brute force attacks, last modified 14 October 2026. The rest of this page explains each part and how to check whether it is happening to you. For the wider question of risk, see is WordPress secure.
How a brute force attack works
Every WordPress site keeps its login page at the same address, wp-login.php. A bot does not need to find it. It sends login requests and reads the reply.
- The bot picks a username. "admin" and the site's domain name are common first guesses.
- It pairs the username with passwords from a list, often passwords exposed in earlier data breaches.
- It submits the pair and checks whether WordPress accepted it.
- It repeats, usually from many IP addresses at once, so that no single address looks busy.
The WordPress documentation notes that these attempts are automated and often come from botnets, and that even failed attempts can overload a site. A site with no limit on failed logins accepts guesses for as long as the bot runs.
What xmlrpc.php adds
xmlrpc.php is a second entry point, built for remote publishing tools and mobile apps. The WordPress documentation calls it a frequent brute force target, especially the system.multicall method. That method lets one request carry several calls, so one request can carry many login guesses. A limit that counts requests to wp-login.php does not see those guesses.
If you do not publish from an app or an external tool, you can disable xmlrpc.php. If you need it, restrict and rate limit it.
How to spot a brute force attack in your logs
Open your server access log and look for these signs:
- Many POST requests to /wp-login.php or /xmlrpc.php in a short period.
- The same few IP addresses repeating, or hundreds of different addresses each sending a few requests.
- A spike in server load or a slow admin screen with no change in real visitors.
- Failed login entries for usernames you never created.
On EasWrk you can ask WrkMate to read your error log in plain language, so you do not have to find the file first. A busy log is normal on a public site. What matters is a sudden change.
How to handle a brute force attack
Handle a brute force attack in six steps: confirm it, add a limit, change weak passwords, turn on two-factor login, close xmlrpc.php and check for damage. The steps follow the WordPress developer documentation, last modified 14 October 2026.
- Confirm it in the logs. Note the target (wp-login.php or xmlrpc.php) and the time it started.
- Add a limit. The WordPress documentation recommends rate limiting /wp-login.php and /xmlrpc.php at the server, using a managed firewall or CDN, or throttling logins with a security plugin if the host does not do it. It also names Fail2ban for banning abusive addresses.
- Change weak passwords. Remove the "admin" username and keep administrator accounts to the few people who need them.
- Turn on two-factor login for administrators. WordPress core does not ship it, so use a plugin or an identity provider.
- Close xmlrpc.php if nothing uses it.
- Check for damage. Look for administrator accounts you did not create and files that changed recently. If you find any, restore from a clean backup and change every password.
No limit makes a login page immune. The aim is a site that costs a bot more time than the next site on its list, with a clean backup ready if a guess succeeds.
What stops a brute force attack
The layers that matter are a limit on failed logins, strong unique passwords, two-factor login, and a firewall in front of the site. EasWrk includes a firewall and DDoS protection on every plan, so some hostile traffic is dropped before it reaches WordPress. We list what is included, and what is not claimed, in our security approach. For the exact login limits on your plan, ask support.
Questions people ask
How does a brute force attack work?
According to the WordPress developer documentation, last modified 14 October 2026, a brute force attack repeatedly tries username and password combinations until one works. The attempts are automated and often come from botnets. A limit on failed logins, long unique passwords and two-factor login stop most of them.
How do I handle a brute force attack?
Confirm the attack in your access log, then add a limit on login attempts. The WordPress documentation of October 2026 recommends rate limiting /wp-login.php and /xmlrpc.php. Change weak passwords, turn on two-factor login and close xmlrpc.php if unused. If you find unknown administrators, restore a clean backup.
How do I know if my WordPress site is under a brute force attack?
Open your server access log and look for many POST requests to wp-login.php or xmlrpc.php in a short time. Other signs are the same few IP addresses repeating, failed logins for usernames you never created and a spike in server load without a rise in real visitors.