WordPress Brute Force Attacks: Stop Login Attempts Without a CAPTCHA

WordPress brute force attacks are automated, constant and mostly stupid. Bots find a WordPress site, try the username admin with a list of leaked passwords, and move on. Your job is not to stop them trying; you cannot. It is to make every attempt fail without slowing down your own login or showing visitors a puzzle. That takes four layers: credentials that cannot be guessed, a second factor, attempt limits, and bot detection that recognises the scanner before it starts.

What the bots actually do

Three patterns cover almost all of it:

Dictionary attacks on wp-login.php. A list of usernames (admin, administrator, your domain name, author names scraped from your posts) against a list of common and leaked passwords. Thousands of attempts per day on a site nobody has heard of is normal.

Amplified guessing through xmlrpc.php. The XML-RPC endpoint supports a multicall method that lets one HTTP request carry hundreds of login attempts. It is far more efficient than hitting the login form, which is why bots love it.

Credential stuffing. Email and password pairs from other breaches, tried on your site in case someone reused them. These succeed more often than dictionary attacks because people reuse passwords.

The third one is the real risk. The first two are noise unless a password is weak.

Layer 1: credentials the bots cannot guess

Everything else is secondary to this.

• No admin username. Create a new administrator with a non-obvious name, log in as it, delete the old one and attribute its content to the new account.
• Long unique passwords. Twenty characters from a password manager. Never reused from another site; that is what credential stuffing relies on.
• Author slugs that differ from usernames. WordPress exposes usernames through author archive URLs and the REST API. Changing the display name does not change the login name; set the author slug (user_nicename) to something else, or hide author archives.
• Fewer accounts with power. Every administrator and editor is a target. Downgrade roles that do not need publishing rights.

Layer 2: a second factor

Two-factor authentication means a stolen or guessed password is not enough. WordPress does not ship it in core, but small dedicated plugins add app-based codes or passkeys. Require it for administrators and anyone with publish rights. Once it is on, brute force attacks are defeated in principle, and the remaining layers are about load and noise.

Layer 3: limit attempts

Even with 2FA, you do not want ten thousand login requests a day hitting PHP. Attempt limiting locks an IP out after a handful of failures for a short window. Keep the lockout short, fifteen minutes to an hour, so a mistyped password does not lock you out all afternoon, and keep an exemption for your own address.

Disable XML-RPC unless something needs it. The WordPress mobile app, Jetpack and a few remote publishing tools use it; most sites do not. One filter in a small plugin or a server rule removes the amplified guessing path entirely.

Layer 4: recognise the scanner before it tries

Attempt limiting reacts after failures. Bot detection acts before. A scanner identifies itself by behaviour: it requests wp-login.php without ever visiting a page, it has no browser profile, it comes from a datacenter, it probes a dozen known plugin paths in a second.

DevDome Bot Protection detects scanners and unwanted bots on those signals, with a Record Bots mode that logs what it would block before you turn on blocking. That is the safe order: record for a week, read the log, confirm no real user appears, then switch to blocking. Protection modes run locally without an account, events are kept for 90 days, and there are no CAPTCHAs or challenge pages. We make it, so weigh that; whatever you use, insist on a record-first mode.

Protect the other doors

wp-login.php is the front door, not the only one. The REST API exposes usernames through the users endpoint unless restricted, which is how bots learn your editors’ login names; limit it to logged-in users if your site does not need it public. The author archive at ?author=1 reveals the first user’s slug; change the slug or disable author archives. The password reset form can be abused to flood an inbox; rate-limit it like the login. And if you run WooCommerce or a membership plugin, their login forms post to the same authentication and need the same attempt limits and bot detection as the main form. A brute force setup that covers wp-login.php and nothing else leaves the side doors open.

What not to do

CAPTCHAs on the login form. Bots solve them through paid services; your editors suffer them daily. The cost lands on the wrong side.

Challenge pages for all visitors. Showing every reader an interstitial to stop login bots is using a sledgehammer on the wrong nail. Readers leave.

Renaming the login URL as your only defence. It hides the door from the laziest bots and nobody else.

Blocking whole countries from the public site because of login noise. Block the login page by country if your team all lives in one place; leave the site open.

See it working

An activity log that records logins and failed logins with IP addresses shows you the before and after: the noise drops when limits and bot detection go on, and the successes are only your own team. If a success appears from an IP you do not know, you have a compromised password, and the log tells you which account to reset.

Set it up once, on a quiet afternoon, and the daily brute force weather becomes something you never think about again.