I have a WP install that's been getting hammered the last couple days by brute force login attempts.

The site has the Limit Login Attempts plug-in installed. And when I started getting frequent notifications about lockouts, I decided since I only access the wp-login.php file and the wp-admin from one place, to block all IPs but my own via .htaccess. I've tested the .htaccess block by removing my IP from the exception list, and it does indeed block access to wp-login.php. So it appears to work from that aspect.

However, even with IPs blocked, Limit Login Attempts keeps reporting (frequent) lockouts from IPs. I thought this was curious, since with the .htaccess block in place, it seems as though it should be impossible to get to the wp-login.php script to begin with, let alone get so far as having an attempted login get processed by the plug-in.

So I tried another experiment: While already logged into WP, I changed the name of wp-login.php to wp-login.xyz thus disabling the script from running entirely. Even with the login script completely disabled, I still got notices that login attempts are being made and IPs are being locked out.

Then I thought perhaps someone's got an auth cookie. So I changed the salts. Still the attempts come.

I've looked at the codex for help on the Authentication API, but most of the sources there are incomplete, and in any case I'm not finding how it might be possible to attempt a login other than via wp-login.php.

So my question is: What, if any, other means of attempting a login are possible without the wp-login.php script? And how can any such alternate login routes be disabled?

EDIT: .htaccess code (first lines of file): This is in the WP root directory (same location as wp-login.php.

<FilesMatch wp-login.php>
order deny,allow
Deny from all

# Allow from this IP address
allow from xx.xxx.xxx.xx  #My IP

ErrorDocument 401 "Sorry. No logins here!"
ErrorDocument 403 "Sorry. No logins here!"
  • That is odd. If indeed the .htaccess filter by IP is working, no visitors outside of the allowed IPs should be able to access the file. What did you write in .htaccess and where is the file located? – jdm2112 Jul 23 '14 at 20:40
  • .htaccess lines for filter added in edit above. Thanks. When I comment out my ip, it blocks me.... but apparently not everyone. – Caspar Jul 23 '14 at 20:48
  • SO by 'first lines' you mean these rules are above the WP rewrite rules? WP rules interfering was one thinkg I suspected. I'm sure you found it already but there is a good WP codex article on security: codex.wordpress.org/Hardening_WordPress – jdm2112 Jul 23 '14 at 20:52
  • Yes, these are above the WP rewrite rules. And I've been over the codex security article. I'm beginning to think the server is compromised. (It's a shared server, and I don't have access to the logs.) It's especially curious that I get login attempts even when the wp-login file isn't even executable. How can that happen? – Caspar Jul 23 '14 at 21:07

The answer is most likely XML-RPC which is used to communicate with the mobile wordpress apps and is always on in newer versions. If you don't use mobile apps to admin your WP you can use my plugin - http://wordpress.org/plugins/control-xml-rpc-publishing/ to disable it.

| improve this answer | |
  • Thanks, and yes, it did turn out to be XML-RPC. I've gone directly to cutting off access to it via .htaccess in this case where the abuse has been so intense. For routine disabling on other sites (where I'll want a convenient way to enable/disable from the Dashboard), I'll sure keep your plug-in handy. – Caspar Jul 24 '14 at 13:53

As @MarkKaplun suggested, the problem was indeed XML-RPC. I contacted the hosting company and asked for a readout of the logs. xmlrpc.php had been hit over 3500 times in less than 24 hours (and this is a small site where nobody would have any reason to hit anything that many times!).


Here's what I suspect was happening. From Antti Vilpponen's blog on mitigating xmlrpc attacks:

From the tests I’ve carried out, I’ve seen that WordPress is also supporting URLs with credentials. So, an attacker can use a URL like http://admin:admin@ to reconfigure the internal router.

So it's hitting xmlrpc.php with the credentialed request that has the same effect as using wp-login.php and triggers WP to go into its authentication routine -- which in turn was triggering the Limit Login Attempts plugin and generating the lockouts.


Rather than use a plug-in (this was before @MarkKaplan answered), I opted to simply cut off all access to xmlrpc.php at the server, again using .htaccess in the WP root as follows:

<Files xmlrpc.php>
    Order allow,deny
    Deny from all

Worked like a charm. My login has been silent.


The filename in the Apache directive was misspelled as xlmrpc.php. Tried to correct it but stackexchange character edit limit didn't let me until I wrote this useless paragraph. It is now correct.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.