WordPress Under Brute-Force Login Attacks
Bots are hammering your WordPress login page with password guesses — normal internet weather for every WordPress site, but worth hardening against so it stays merely weather.
Common signs of this issue
- The site is suddenly slow or briefly unavailable at random times, with no visitor traffic to explain it.
- A security plugin or your host emails about waves of failed login attempts.
- Logs show endless requests to wp-login.php or xmlrpc.php from many different addresses.
- You get locked out by your own security plugin after failed attempts you never made.
- It's been going on quietly for months — which, for unhardened sites, is the normal state of the internet.
Safe checks you can do yourself
None of these require sharing passwords with anyone.
- First, settle the only question that truly matters: could a guess ever succeed? Every admin account needs a long, unique password (a password manager's random 20+ characters), and no account should be literally named "admin" — the username half of most guessing. With that true, the attacks are noise; without it, they're a countdown.
- Turn on two-factor authentication for admin accounts (most security plugins offer it) — it makes even a correctly-guessed password useless, converting the entire attack class from threat to trivia.
- Enable login attempt limiting (same plugins) so guessing gets slow and expensive — while setting the thresholds forgivingly enough that your own typos don't lock you out (see the login guide for that failure mode).
- While in the users screen, audit the accounts: remove or demote unknown and long-departed users, and check the list matches who should exist — this doubles as a quiet compromise check.
- For the server load half: ask your host about login protection or a web application firewall (many include one free), and if you use Cloudflare, its protection can stop bots before they ever reach wp-login. Blocking or restricting xmlrpc.php (a legacy endpoint bots abuse for amplified guessing) is a standard hardening step most sites can take safely — one to ask your host or helper about.
- Confirm WordPress, plugins, and themes are up to date — brute force is the crude front door, but outdated plugins are the unlocked side window attackers actually prefer; hardening one while ignoring the other misses the realistic threat.
What this usually means
Constant brute-force traffic is background radiation for every WordPress site on the internet — bots continuously try common passwords on every login page they can find, automatically, with no interest in you specifically. Discovering it in your logs feels alarming but changes nothing about your actual risk; the password's strength was always the whole story. Strong unique password plus two-factor equals mathematically futile guessing, however long the bots persist.
The secondary, legitimate problem is load: heavy attack waves consume server resources processing all those failed logins, which can slow or briefly topple a small hosting plan. That's what rate-limiting, firewalls, and xmlrpc blocking address — not because the guessing might succeed, but so your server stops paying to entertain it.
Perspective on the real threat model: brute force is the crudest, least successful attack WordPress sites face. The compromises that actually happen come overwhelmingly through outdated plugins and stolen/reused passwords. Treat the scary log entries as a prompt to do the boring fundamentals — strong credentials, two-factor, updates — which defend against both the noise you can see and the quieter attacks you can't.
What not to do
- Don't rely on a weak or reused password and hope the attacks lose interest — they're automated and eternal; the password is the only variable you control.
- Don't disable your security plugin to 'speed the site up' during an attack wave — that removes the rate-limiting at the exact moment it's working.
- Don't blindly block whole countries as the primary fix — attacks come from compromised machines everywhere (including your own country), and you may block real visitors; use it only as a considered extra layer for strictly local businesses.
- Don't rename wp-admin via random tutorial code — done wrong it locks YOU out; if hiding the login appeals, use a maintained plugin for it, and treat it as obscurity on top of (never instead of) strong credentials.
- Don't share your admin login with anyone who contacts you about the attacks — unsolicited 'we noticed attacks on your site' outreach is a scam pattern.
- Don't panic-buy 'under attack' emergency services for ordinary brute-force noise — the defenses are standard, calm, and mostly free.
When to get help
Get help promptly in two cases: the attacks are actually knocking the site offline (a load problem needing firewall/server-level fixes beyond plugin settings), or you suspect a login may have succeeded — unknown admins, changed content, sessions you don't recognize — which upgrades this from noise to the hacked-site playbook. Otherwise, an hour of standard hardening (credentials, two-factor, rate limits, xmlrpc, firewall) is routine work that turns permanent background attacks into permanent background irrelevance.
Not sure what to do next?
Answer a few short questions and we'll point you to the safest next step — DIY, a freelancer, or a direct review. No passwords required.
Is this a business website? If this issue may be costing you leads, sales, or trust, you may want a direct review instead of trial and error.
Frequently asked questions
Does constant brute-force traffic mean I've been hacked?
No — it means you have a WordPress site on the internet; every one of them gets this automatically. Hacked is different evidence: logins that succeeded, unknown admin accounts, changed content. Attempts are weather; check for those signs, then harden and carry on.
What's the single best protection?
A long, unique password plus two-factor authentication on every admin account. That combination makes guessing mathematically futile regardless of attempt volume — everything else (rate limits, firewalls) manages load and adds margin.
What is xmlrpc.php and why do attacks target it?
A legacy WordPress remote-access endpoint that lets bots test many passwords per request — amplified guessing that also hammers your server. Most sites don't need it and can block or restrict it safely; a security plugin or your host can do it, with exceptions if you use Jetpack or remote publishing.
Why is my site slow during attack waves if the logins all fail?
Each failed attempt still costs the server real work, and thousands per hour add up — especially on shared hosting. That's the case for stopping bots before the login page: rate limiting, a firewall, Cloudflare, and xmlrpc blocking cut the load, not just the risk.
Should I hide my login page at a custom address?
It's a legitimate noise-reducer — dumb bots hit the default address and miss. Use a maintained plugin (never hand-edits), record the new address somewhere safe, and treat it as a supplement: determined attackers find login pages, so credentials and two-factor still do the real work.
My security plugin reports blocking thousands of attacks a week. Should I worry?
That report is the system working — blocked attempts are the ocean hitting a good seawall. Worry signals are different: successful logins from unknown places, new admin users, or site changes. Glance at those; let the block counter be background music.