Security
How to Stop WordPress Brute-Force Login Attacks Fast
To stop a WordPress brute-force login attack immediately, block or rate-limit request access to wp-login.php and xmlrpc.php using a web application firewall (WAF) like Cloudflare or web server rules in your .htaccess or Nginx configuration. You can then secure the account permanently by enforcing two-factor authentication (2FA), disabling XML-RPC entirely, and installing a limit login attempts plugin.
Brute-force login attacks are among the most common threats facing WordPress websites today. Unlike targeted hacks designed to exploit a specific plugin vulnerability, brute-force attacks rely on automated botnets that bombard your site's login entry points with thousands of username and password combinations per minute. Even if the attack fails to guess your credentials, the sheer volume of server requests can overload your database, spike your CPU usage, and cause severe slowdowns or server crashes.
Symptoms of an Active Brute-Force Attack
Because brute-force attacks operate automatically in the background, you might not notice one immediately until your hosting server begins to struggle under the load. Common indicators include:
- Unusually slow admin dashboard response times: Navigating around
/wp-admin/feels sluggish or frequently times out with a 504 Gateway Timeout error. - High CPU or memory usage spikes: Your web hosting control panel shows maximum account resource usage, even when public visitor traffic is low.
- Unexpected account lockouts: Security plugins repeatedly notify you that IP addresses are being blocked for failed login attempts.
- Elevated POST traffic in server logs: Your raw server access logs show hundreds or thousands of
POST /wp-login.phporPOST /xmlrpc.phprequests coming from disparate IP addresses. - Excessive bandwidth consumption: Unexplained spikes in data transfer over short periods.
The Two Entry Points Automated Bots Target
Botnets usually target two specific files on every default WordPress installation:
1. wp-login.php
This is the standard web endpoint where users enter their credentials. Bots send HTTP POST requests directly to this file, testing common administrative usernames like admin, administrator, or the site domain name paired with massive lists of leaked passwords.
2. xmlrpc.php
WordPress includes an XML-RPC API endpoint designed to allow external applications (like mobile apps or remote posting tools) to communicate with your site. However, XML-RPC features a function called system.multicall. This function allows a single HTTP request to test hundreds of username/password pairs at once. This makes XML-RPC an ideal target for attackers looking to bypass traditional single-request login throttles while consuming minimal attacker bandwidth.
Step 1: Emergency Triage (Stopping Server Overhead)
If your site is currently crashing or unusable due to an active attack, PHP plugins alone may not solve the problem because loading WordPress on every failed request still consumes database and memory resources. You must stop the bad requests at the server edge before they reach PHP.
Option A: Turn on Cloudflare Under Attack Mode
If your domain routes through Cloudflare, log in to your Cloudflare dashboard and enable Under Attack Mode on the Overview page. This presents a brief JavaScript challenge to all visitors before they hit your origin server, immediately filtering out dumb script bots and easing your server load within seconds.
Option B: Block xmlrpc.php at the Server Level
Unless you actively use Jetpack or mobile publishing apps, you should completely block public access to xmlrpc.php.
If your server uses Apache (standard cPanel hosting), add the following code block to your top-level .htaccess file before making changes, ensure you back up the file:
# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order allow,deny
deny from all
</Files>
If your server uses Nginx, add this directive inside your site's server block configuration:
# Block access to xmlrpc.php
location = /xmlrpc.php {
deny all;
access_log off;
log_not_found off;
}
Step 2: Secure wp-login.php
Once you have neutralized XML-RPC attacks, turn your attention to protecting the actual browser login screen.
Method 1: Password-Protect wp-login.php with HTTP Basic Auth
Adding a secondary server-level authorization step forces the visitor browser to present a server password before WordPress PHP even executes. Botnets trying to POST to wp-login.php are instantly rejected with a 401 Unauthorized status.
On cPanel hosting, this can be set up visually using the Directory Privacy or Password Protect Directories tool for the wp-login.php file. Alternatively, add an .htpasswd reference to your .htaccess file:
<Files wp-login.php>
AuthType Basic
AuthName "Restricted Area"
AuthUserFile /home/username/.htpasswd
Require valid-user
</Files>
Method 2: Restrict Login to Specific IP Addresses
If your administration team works from fixed IP addresses, you can restrict access to wp-login.php exclusively to those IPs in .htaccess:
<Files wp-login.php>
Order Deny,Allow
Deny from all
# Replace with your actual IP address
Allow from 203.0.113.15
</Files>
Step 3: Implement Software-Level Protections
If server configuration files are inaccessible or your team works from dynamic IP addresses, apply security application rules within WordPress.
1. Install a Limit Login Attempts Plugin
Plugins like Limit Login Attempts Reloaded or built-in modules in Wordfence and Solid Security track IP addresses that enter invalid credentials. After a set number of failed attempts (such as 3 to 5 attempts), the plugin temporarily or permanently bans that IP address from submitting further requests.
2. Enforce Two-Factor Authentication (2FA)
Even if an attacker successfully guesses a password, 2FA prevents them from logging in without an authenticator app code (TOTP) from an authorized mobile device. Tools like Two-Factor or WP 2FA ensure stolen passwords cannot compromise an admin account.
3. Eliminate Default Usernames
Ensure no active account uses the username admin or administrator. If your primary account is named admin:
- Create a new user account with a custom username (e.g.,
jdoe_admin). - Assign the Administrator role to the new user.
- Log out of WordPress and log in under the new administrator account.
- Delete the old
adminaccount and attribute all existing posts and content to your new account.
Should You Rename the WordPress Login URL?
Plugins like WPS Hide Login allow you to change /wp-login.php to a custom path like /my-custom-login-path. While this provides minor defense through obscurity by frustrating generic bots, it is not a complete security solution on its own.
Bot scripts can sometimes discover hidden login pages through automated form scans or publicly exposed endpoints like registration handlers. Treat URL hiding as an optional secondary measure rather than your main security wall.
How to Prevent Future Attacks
Long-term protection against brute-force attacks requires proactive monitoring and baseline security hygiene. Review our guide on how WordPress sites get hacked to understand how modern attack vectors operate.
- Use Web Application Firewalls (WAF): Cloud-based firewalls (Cloudflare, Sucuri, Fastly) inspect incoming HTTP traffic and reject known malicious botnet IPs before requests ever reach your web server host.
- Keep WordPress Core and Plugins Updated: Ensure authentication mechanisms are updated against unauthenticated bypass bugs.
- Set Up Strong Password Policies: Mandate complex, high-entropy passwords generated by password managers for all users with publishing or management privileges.
- Monitor Server Health: Set up automated alert notifications with your host when CPU or RAM usage spikes abnormally.
When to Call a Professional
If a brute-force attack has resulted in your server completely locking you out, if your site is showing a 500 Internal Server Error due to configuration missteps, or if you suspect credentials were compromised and malicious users gained entry, professional intervention is necessary.
You may also find yourself locked out of WordPress admin due to aggressive firewall rules or IP lockouts. If you suspect an attacker successfully logged in and dropped unauthorized backdoors, read our step-by-step guide on how to find and remove WordPress malware.
When server management feels overwhelming or your site is down during an active attack, Mend can step in immediately. Our senior engineers handle emergency site rescues on a safe, backup-first workflow. If you need immediate assistance resolving access issues or clearing server lockouts, request an Emergency Rescue, or get a Free Diagnosis to secure your site before permanent damage occurs.
Frequently asked questions
What is a WordPress brute-force login attack?
A brute-force attack uses automated scripts to rapidly attempt thousands of username and password combinations against wp-login.php or xmlrpc.php until it finds the correct credentials or crashes the server.
Will changing my login URL completely stop brute-force attacks?
Renaming your login URL deters simple bots that specifically target wp-login.php, but it does not fix underlying vulnerabilities like exposed XML-RPC endpoints or weak user credentials.
How do I unblock myself if I get locked out by a security plugin?
You can regain access by logging into your site via FTP or cPanel File Manager, navigating to wp-content/plugins/, and temporarily renaming the security plugin's folder to disable it.
Why is XML-RPC such a major target for brute-force attacks?
XML-RPC supports a multicall feature that allows attackers to test hundreds of password combinations within a single HTTP request, bypassing traditional one-request-at-a-time rate limits.