Skip to content
WordPress Security August 29, 2026 9 min read

How to Protect Your WordPress Site from Brute Force Attacks

How to Protect Your WordPress Site from Brute Force Attacks

Learning how to protect your WordPress site from brute force attacks comes down to three moves: make guessing a password useless, cap how many guesses an attacker gets, and block the bad traffic before it ever reaches PHP. Most sites get hit not because they are famous, but because automated bots scan the entire internet for wp-login.php and try thousands of common credential pairs per hour. The good news is that a properly hardened login page turns those attacks into background noise.

This guide covers the layers that actually matter, in the order I would apply them on a client site, plus something most articles skip: how to confirm your defenses are working and what to do if you were already breached.

What a Brute Force Attack Against WordPress Looks Like

A brute force attack is simply repeated guessing. A bot hammers your login endpoint with username and password combinations until one works, often using leaked credential lists rather than random strings, which is technically credential stuffing.

On WordPress, attackers usually target four entry points:

  • /wp-login.php, the standard login form, hit by POST requests in rapid succession.
  • /xmlrpc.php, which historically allowed hundreds of credential tests inside a single request via the system.multicall method.
  • The REST API, used to enumerate usernames at /wp-json/wp/v2/users before guessing begins.
  • FTP, SFTP and cPanel logins, which sit outside WordPress entirely but hand over the same site.

The OWASP definition of a brute force attack is worth reading if you want the underlying mechanics. The practical takeaway is that these attacks are cheap, automated and constant, so your defense has to be automated too.

Signs Your Site Is Under Attack Right Now

Before you install anything, check whether an attack is already in progress. A brute force campaign is noisy and leaves fingerprints in places most site owners never look.

  • CPU or PHP worker spikes with no matching traffic in Google Analytics, since bots rarely fire your analytics script.
  • Hundreds of POST requests to wp-login.php from a handful of IPs in your raw access logs, often within a few minutes.
  • A flood of “lost password” or failed login notification emails, especially overnight.
  • Slow admin pages or 503 errors during otherwise quiet hours.

Most managed hosts expose raw access logs in the control panel. Search for “wp-login.php” and “xmlrpc.php”, then count requests per IP; anything above roughly 20 login attempts per minute from one address is an attack, not a forgetful user.

Layer 1: Fix the Credentials Themselves

Every other control buys you time. Strong, unique passwords are what actually make guessing pointless, because a 16 character random password is not in any leaked list.

  1. Delete or rename the “admin” username. Create a new administrator with an unusual name, then reassign content and remove the old account.
  2. Use a password manager and generate 16+ character passwords for every administrator and editor account.
  3. Audit your user list quarterly. Old freelancers, agency accounts and abandoned subscriber logins are the ones nobody rotates. Our guide to managing WordPress users, roles and permissions walks through least privilege setup.
  4. Stop forcing arbitrary rotations. The NIST Digital Identity Guidelines (SP 800-63B) recommend screening passwords against breach lists instead of mandating 90 day changes, which tend to produce weaker variations.

Layer 2: Two-Factor Authentication

Two factor authentication is the single highest value control on this list, because a correct password alone stops being enough. Even if a bot guesses the right combination, the second factor blocks the session.

Use a TOTP app (Google Authenticator, Authy, 1Password) rather than SMS, which is vulnerable to SIM swapping. Plugins such as WP 2FA, Wordfence Login Security or Solid Security add factor authentication in about ten minutes, and you can enforce it for administrators and editors only if your subscriber base would revolt.

For automated integrations, issue application passwords instead of sharing real logins. They are built into WordPress core, scoped per application and revocable without changing anyone’s credentials.

Layer 3: Limit Login Attempts

WordPress core allows unlimited login attempts by default, which is exactly what makes brute force attacks viable. Capping attempts turns a 10,000 guess run into 5 guesses and a lockout.

Plugin route: Limit Login Attempts Reloaded, Wordfence and Solid Security all offer lockouts after a set number of failures. Sensible settings for most business sites are 5 failed attempts, a 20 minute lockout, and a 24 hour lockout after 3 lockouts.

If you want to limit login attempts without a plugin, you have solid server side options:

  • Fail2ban on a VPS, watching your access log and dropping offending IPs at the firewall.
  • Cloudflare rate limiting rules on /wp-login.php, for example 5 POST requests per minute per IP, then challenge.
  • .htaccess or nginx allow lists restricting wp-login.php and wp-admin to your office and home IP addresses, which is the strongest option if your IPs are stable.
  • HTTP basic authentication in front of wp-login.php, adding a second credential prompt that bots almost never handle.

Blocking at the edge or web server is preferable because the request never spins up PHP, so an attack costs you no server resources and does not slow down real visitors.

Layer 4: Close the Side Doors

Hardening only wp-login.php while leaving other endpoints open is a common mistake. Attackers pivot instantly.

  • Disable xmlrpc.php if you do not use the WordPress mobile app, Jetpack or remote publishing. Block it at the server level rather than with PHP filters.
  • Block user enumeration by denying ?author=1 style requests and restricting the REST users endpoint to authenticated requests.
  • Force HTTPS site-wide. A login form posting over HTTP hands credentials to anyone on the same network, so complete the HTTP to HTTPS migration including mixed content fixes.
  • Rename the login URL as a noise reducer. It stops dumb bots but is obscurity, not security, so never treat it as a replacement for 2FA and rate limiting.
  • Review PHP settings and disable file editing by adding define(‘DISALLOW_FILE_EDIT’, true); to wp-config.php so a stolen admin session cannot inject code through the theme editor.

Layer 5: Host, WAF and Recovery

Your host is your first line of defense whether you realize it or not. Ask a prospective provider whether they run a managed web application firewall, block xmlrpc by default, offer daily off-site backups and provide raw log access; if the sales team cannot answer, that is your answer.

A WAF from Cloudflare, Sucuri or your host filters known bad IP ranges and abusive patterns before they hit WordPress. Pair it with a real backup routine, because recovery speed matters more than any single control. Compare options in our roundup of the best WordPress backup plugins, free and paid, and keep at least one copy stored off the server.

Version control adds another safety net. Keeping your theme and custom plugins in Git means you can diff every file after an incident and see exactly what changed, which is far faster than eyeballing a file manager.

Test It, Then Watch It

Plenty of site owners install a security plugin, never verify the settings, and assume they are covered. Spend fifteen minutes confirming the controls actually fire.

  1. Open a private browser window and enter a wrong password five times. You should be locked out with a clear message.
  2. Log out and confirm the second factor prompt appears for an administrator account.
  3. Visit yoursite.com/xmlrpc.php and expect a 403 or 404 rather than the XML-RPC server message.
  4. Request /?author=1 and confirm it does not redirect to a username slug.
  5. Set up email or Slack alerts for lockouts, new administrator accounts and core file changes.
  6. Check your logs monthly and note whether attack volume is rising, which usually precedes more targeted attempts.

Also test that you have not blocked yourself. Overly aggressive rules routinely lock out clients on mobile networks, so document a recovery path (FTP access, a spare admin IP allowance) before you tighten anything.

For the full pass across file permissions, plugin hygiene and update policy, work through our ultimate WordPress security checklist after you finish the login layer.

Frequently Asked Questions

Why are people leaving WordPress?

WordPress still powers roughly 43% of all websites, so departures are a minority trend driven mainly by maintenance fatigue, plugin bloat and the appeal of hosted builders. Site owners who leave usually cite update management and security upkeep rather than the platform itself. Managed hosting plus a tight plugin list solves most of those complaints without a rebuild, though a proper migration guide helps if you are moving in either direction.

Why is my WordPress site getting hacked?

In the vast majority of cases it is one of three causes: an outdated plugin or theme with a known vulnerability, a weak or reused administrator password, or a compromised hosting account. Attacks are almost never personal; automated scanners test millions of sites daily for the same handful of flaws. Update weekly, remove anything you do not use, and enforce 2FA to close most of the gap.

What is the best security for WordPress?

The strongest setup is layered: two factor authentication on all admin accounts, login attempt limits at the server or CDN level, a web application firewall, automatic core updates and daily off-site backups. No single plugin replaces that stack. If you want one starting point, enable 2FA today, because it defeats brute force attacks even when the password is correct.

How do you know if your WordPress site has been hacked?

Common signals include unfamiliar administrator accounts, spam pages indexed in Google (search site:yourdomain.com), redirects to unknown domains, modified core files and browser or Search Console warnings. Run a malware scan with Wordfence or Sucuri, compare core file checksums, and check the users table first. If you find an intrusion, take the site offline, restore a clean backup, then rotate every password including database and hosting credentials.

Want your WordPress site locked down properly?

If you would rather have someone audit the login layer, firewall rules and backup plan for you, SEO Quirk handles WordPress hardening alongside search performance work, and you can read more about working with a local agency before you commit. Building from zero instead? Start with our guide on how to start a WordPress blog from scratch and get the security settings right on day one.

Leave a Reply

Your email address will not be published. Required fields are marked *