--- title: How to Stop WordPress Login Attacks description: Bots hammer wp-login.php on nearly every WordPress site. Here is what actually keeps them out, in the order we would do it on your account. date: 2026-10-12 updated: 2026-10-13 tags: [security monday, wordpress, logins] url: "https://drivenhost.com/blog/stop-wordpress-login-attacks" author: DrivenHost --- Every WordPress site we host gets login attempts nobody asked for. On a quiet site that might be a few dozen a day. On a site with a bit of age and a few backlinks it can be thousands a week, from hundreds of addresses, nearly all of them trying the username `admin` with passwords lifted from old data breaches. That traffic is just weather on the internet now. The sites that actually get taken over are the small number where one of those guesses lands. Today's Security Monday is about making sure yours is not one of them. ## What this looks like from the server side Two different things get lumped together as "brute force". One is a bot working through a password list against your login form. The other, more common and more successful, is credential stuffing: someone takes an email and password pair that leaked from an unrelated site years ago and tries it on your admin login, because people reuse passwords. From our side both show up as a long run of POST requests to `/wp-login.php`, and sometimes to `/xmlrpc.php`, which can accept many login attempts in a single request and is therefore a quieter way to guess. The first symptom an owner usually notices is not a break-in. It is a site that has gone sluggish, or a CPU warning, because PHP is being asked to build the login page a few thousand times an hour. If your site got slow for no obvious reason, the access log is worth a look before the plugin list. ## Unique passwords beat clever passwords Length and uniqueness do more here than punctuation tricks. A long passphrase you have never used anywhere else survives credential stuffing completely, because the attacker has nothing to stuff. `Summer2024!` meets most complexity rules and is in every wordlist on earth. What we would do today, in order. Get a password manager so every account can have its own long random password, because nobody memorises forty of those. Change the username if yours is still `admin`, since that one guess removes half the attacker's work. And keep your [hosting account](/hosting) password different from your WordPress admin password, so one compromise does not hand over both. We covered the groundwork for this in [WordPress security basics](/blog/wp-security-basics) if you want the longer version. ## Two-factor on the accounts that can do damage Two-factor authentication is the single change that makes a leaked password a non-event. You do not need it on every subscriber account. Put it on anything with Administrator or Editor rights, and on your cPanel login, where it is built in under Security. For WordPress itself, the [Two Factor](https://wordpress.org/plugins/two-factor/) plugin in the official directory does the job without adding a dashboard full of upsells. Authenticator app codes are the sensible default. Email codes are better than nothing, but they are only as strong as the mailbox they arrive in, so if you go that route the mailbox needs its own unique password too. ## Make the login page less reachable If attackers cannot reach the form, the password question becomes academic. A few options, roughly in order of how much they inconvenience you: Rate limiting is the baseline. A plugin that locks out an IP after a handful of failed attempts turns a password list of ten thousand into a password list of five. We run server-level protections too, so a lot of this traffic never reaches your PHP at all, but a site-level limit is still worth having. Password protecting the login directory is stronger. cPanel's Directory Privacy adds an HTTP authentication prompt in front of `/wp-login.php`, which almost no bot will get past. It annoys clients and contributors, so it suits sites with one or two logins. Turning off XML-RPC helps if you do not use it. Check first: the WordPress mobile app and some older integrations depend on it. If nothing you run needs it, blocking `/xmlrpc.php` closes a door that gets rattled constantly. cPanel's IP Blocker is there if you want to block a specific persistent source, though with bots rotating addresses it is a short-term fix rather than a strategy. ## Close the accounts you forgot you opened Login hardening does nothing for the developer account from a 2019 redesign that still has Administrator rights and a password nobody remembers setting. It comes up regularly on sites we are asked to clean up. Open Users, read the list properly, and delete or demote anything you cannot account for. [Who still has access to your site?](/blog/who-still-has-site-access) walks through the rest of the audit, including FTP and database users. None of this takes an afternoon. A password manager, two-factor on your admin accounts, a login limit, and a tidy user list will take most sites out of the category that gets compromised by guesswork. If you are not sure what is already in place on your account, or your logs look busier than they should, [open a ticket with us](/support) and we will take a look at what is actually hitting your site. ## Sources - [Brute Force Attacks](https://developer.wordpress.org/advanced-administration/security/brute-force/), WordPress Advanced Administration - [Hardening WordPress](https://developer.wordpress.org/advanced-administration/security/hardening/), WordPress Advanced Administration - [Two Step Authentication](https://developer.wordpress.org/advanced-administration/security/mfa/), WordPress Advanced Administration