What a brute-force attack on WordPress looks like

Every public WordPress site gets automated login attempts, usually within days of going live. They come in three flavours:

  • Brute force: guessing common passwords for common usernames such as “admin”.
  • Credential stuffing: trying email and password pairs leaked from other sites’ breaches. This works whenever someone reused a password.
  • Distributed attempts: the same attack spread over thousands of IPs, a few tries each, to slip under simple per-IP limits.

Apart from the risk of a successful login, the attempts themselves cost CPU and database time, which is why a site under attack can slow to a crawl.

WordPress brute force protection in five layers

1. Two-factor authentication

Two-factor authentication (2FA) asks for a second proof, usually a six-digit code from an authenticator app, after the password. A guessed, reused or phished password is no longer enough, which defeats brute force and credential stuffing at the same time. Turn it on for every administrator, editor and shop manager first; those accounts can change code and content. Silent Threads includes 2FA on every plan.

2. Long, unique passwords

Credential stuffing only works when passwords are reused. Require long passwords and encourage a password manager. A strong password policy, which Silent Threads enforces on every plan, refuses short and common passwords when they are set.

3. Rate limiting and lockouts

Limit how many failed logins an IP (and a username) can make in a period, then slow down or block further attempts. That turns millions of guesses a day into a handful. Silent Threads’s brute-force protection and rate limiting run on every plan. Pro adds Bot Login Detection, Login reCAPTCHA and Progressive WAF Response, which escalates the firewall’s response under sustained attack.

4. Deal with xmlrpc.php

XML-RPC is an older remote API. Its system.multicall method lets one request try many username and password combinations, which bypasses per-request login limits. If nothing you use needs XML-RPC (some mobile apps and older integrations do), block xmlrpc.php at the server or with your firewall. If you need it, make sure your login protection counts the attempts made through it.

5. Make usernames harder to guess

Don’t use “admin” or your site name as a username. WordPress can reveal author usernames through author archives (/?author=1) and the REST API users endpoint, so treat usernames as public and rely on the password plus 2FA. Blocking login attempts for the usernames attackers try most often cuts noise further; Silent Threads’s suspicious-username blocking is on every plan.

Does changing the login URL help?

Moving wp-login.php to a custom address removes most automated noise from your logs, because bots aim at the default path. It doesn’t make weak passwords safe, and the new address can leak. Treat it as noise reduction on top of the layers above, not as protection by itself. Custom Login URL is a Pro feature in Silent Threads.

Protecting sessions after login

Attackers who get a session cookie don’t need the password at all. For high-value sites, look at controls after login: approval of logins from new devices, session fingerprinting so a stolen cookie doesn’t work from another browser, monitoring of active sessions, and asking for re-authentication before sensitive actions. Silent Threads’s Agency plan includes New-Device Login Approval, Session Fingerprinting, Active Session Monitoring and Step-Up Verification.

Registration and comment abuse

If your site allows sign-ups, the same bots create fake accounts. Turn registration off if you don’t need it. If you do, add bot checks to the form and consider approving new users manually. Pro includes Registration Abuse Prevention and a New-User Approval Queue.

If an attacker already got in

Brute-force protection stops future guesses; it doesn’t remove someone who already has a working login. If you see a successful login you don’t recognise, or a new administrator account, act on it straight away:

  1. Change the password of the affected account and every administrator account, from a computer you trust.
  2. Replace the authentication keys and salts in wp-config.php, which signs everyone out, the attacker included.
  3. Delete accounts you don’t recognise and check what they changed: new plugins, edited theme files, new scheduled tasks.
  4. Scan the site for malware, because a stolen admin login is often used to plant a backdoor within minutes.

Our guide on how to tell if a WordPress site is hacked lists the checks to run next.

How to tell whether it’s working

  • Failed login attempts should be blocked within a few tries per IP, not answered thousands of times.
  • Your own administrators should never be locked out. Check that your login protection treats your known IPs and logged-in admins carefully.
  • You should hear about it when it matters: a successful login from somewhere new, or a new administrator account. Silent Threads emails you instantly when a new administrator is added, on every plan.

Login protection is one part of a layered defence. See WordPress firewall vs. host firewall for the request-filtering layer, and the WordPress security checklist for everything else. The login security features list exactly what each plan includes.

How we checked this guide

This article explains common attack methods and well-established defences, citing WordPress and OWASP documentation. It doesn’t quote attack statistics. Silent Threads features are named with the plan that includes them.