Imagine sitting inside your house while someone stands at your front door, trying thousands of different keys every single second. They don’t know which key fits, but they have a massive ring of millions of them, and they are willing to stand there until they find the right one.
In the digital world, this is a brute force attack.
Because WordPress powers over 40% of the internet, it is the number one target for these types of automated break-ins. If your website security isn’t properly configured, you are essentially leaving your front door exposed to an infinite number of key-turners.
Here is exactly how brute force attacks work, why they are dangerous even if they fail, and how to lock them out of your WordPress site for good.
How a brute force attack works
A brute force attack is a trial-and-error method used by cybercriminals to guess login credentials, encryption keys, or hidden web pages.
Don’t picture a human hacker sitting at a keyboard typing in passwords. Instead, attackers use automated software and botnets — networks of hijacked computers — to run through thousands of combinations per minute.
They typically target two primary areas on a WordPress site:
- The login page (wp-login.php) — the standard entry point for every WordPress user.
- The XML-RPC file (xmlrpc.php) — a feature that allows external applications to communicate with your site. Attackers abuse it to try hundreds of passwords in a single request, making it far more dangerous than the login page alone. If you’re not using the WordPress mobile app or external publishing tools, disabling it entirely is the right call.
The hidden danger: server resource exhaustion
The most obvious threat of a brute force attack is a hacker successfully guessing your password and taking over your site. But there is a second, less obvious danger: server fatigue.
| Important: Every time a bot tries to log into your site, your server uses resources to process that request. If a botnet targets your site with 50,000 login attempts in an hour, your server can run out of memory — causing your site to slow to a crawl or crash entirely, which hurts both user experience and SEO rankings. |
How to stop brute force attacks on WordPress
WordPress’s default setup is flexible, but it isn’t built to stop persistent login spam out of the box. Protecting your site means adding a few structural security layers. Here is the approach, from most to least critical.
1. Ban the username “admin”
When a bot attacks a WordPress site, the very first username it tests is “admin”. If you’re still using it, you’ve already handed attackers half the puzzle.
- The fix: Create a new administrator account with a unique username — avoid your actual name or the site’s domain. Once active, log into the new account and delete the old “admin” user, attributing all past content to the new profile.
- Recommended tool: None needed — handle this directly via WordPress Dashboard → Users during initial site configuration.
| DEV FOOTNOTE Database lookups on non-existent users still strain resources. When an invalid user like “admin” is queried, WordPress executes an unindexed search against the wp_users table. For programmatic prevention, hook into the authenticate filter early with a low priority to drop requests attempting to pass “admin” before hitting the database. |
2. Install a digital bouncer (limit login attempts)
By default, WordPress allows unlimited password guesses. Change the rules: if a user or bot enters the wrong password three or four times, their IP address gets blocked.
- Recommended tools: Limit Login Attempts Reloaded or Loginizer. Both let you define retry limits, lockout durations, and custom IP blocklists from the dashboard.
| DEV FOOTNOTE Running login limitations at the application layer means every failed attempt still boots WordPress core, triggers the wp_login_failed hook, and writes a log entry to the database. While effective at preventing entry, severe bot attacks can still cause MySQL thread exhaustion. |
3. Hide the front door (change your login URL)
Every hacker and bot knows that the gateway to a WordPress site is found by adding /wp-admin or /wp-login.php to a domain. If they can’t find the door, they can’t try to kick it down. Moving this path forces malicious traffic to hit a lightweight 404 page instead of processing heavy login logic.
- Recommended tool: WPS Hide Login — stable, lightweight, and doesn’t alter core files or rewrite deep server rules.
| DEV FOOTNOTE Changing the login slug via a plugin relies on intercepting init or plugins_loaded filters. This only protects the frontend interface — bots targeting xmlrpc.php or sending direct POST payloads to wp-login.php bypass it entirely if the plugin doesn’t catch raw server requests. For a tighter setup, couple this with a server-level rule in your .htaccess or Nginx configuration to block direct script access. |
4. Implement two-factor authentication and a web application firewall
Two-factor authentication is the ultimate failsafe. Even if a bot guesses your password correctly, it still can’t log in without a time-sensitive code sent to your phone. A cloud-based firewall goes a step further — it filters out known malicious bots and bad IP addresses at the network level before they ever reach your server.
- Wordfence Security — the industry standard for all-in-one protection, with a robust endpoint firewall, real-time threat intelligence, and a solid built-in 2FA module.
- Solid Security (formerly iThemes Security) — a clean alternative with dependable 2FA enforcement.
- Cloudflare (DNS-level WAF) — intercepts and blocks malicious automated requests at the network edge before a single packet reaches your origin server, preserving full hosting performance.
| DEV FOOTNOTE Traditional security plugins load as essential plugins, meaning PHP still executes on the server to reject attacks. Implementing an edge-level WAF like Cloudflare handles filtering at Layer 7 before anything touches the origin. This keeps PHP workers free to serve genuine traffic during a heavy campaign. |
WordPress security checklist
| Action item | Implementation method | Priority |
|---|---|---|
| Audit admin usernames | Delete “admin” and replace with a non-generic alternative | High |
| Enforce passphrases | Minimum 16 characters with mixed case, numbers, and symbols | High |
| Restrict login attempts | Install Loginizer or Limit Login Attempts Reloaded — set max retries to 3 | High |
| Deploy 2FA | Mandate two-factor authentication via Wordfence for all Editor and Admin accounts | High |
| Mask the login entry | Use WPS Hide Login to move the default path away from /wp-admin | Medium |
| Disable XML-RPC | Turn off external communication if not using the WordPress mobile app or external publishing tools | Medium |
| Offload via edge WAF | Route site DNS through Cloudflare to drop bot traffic before it reaches the host | Medium |
Final thoughts
Securing your WordPress site against brute force attacks doesn’t require complex engineering. Discard generic usernames, restrict login attempts, hide your entry paths, and add a second authentication factor — each layer compounds the last.
Ten minutes of configuration puts you ahead of the vast majority of WordPress sites on the internet. Your server performance, your client data, and your peace of mind will be better for it.