During a large brute force attack, I'd like to shut off the ability to log into WordPress entirely. The only account on the site is mine, so there's no reason for visitors to login and it wouldn't hurt their experience on the site.

When I need to login, I can remove the code. Alternatively, I can limit logins to just my IP address.

I'm trying to achieve this by catching a login attempt as early as possible with the following code

if (isset($_POST['pwd']) || isset($_GET['pwd'])) {
    header($_SERVER["SERVER_PROTOCOL"]." 404 Not Found");
    echo 'logins to the site are disabled';

This is crude but it should work. However, there are still some login attempts getting through and I don't know where they could be coming from.

How else does WordPress accept logins, if it's not with the 'pwd' field?

Is there an existing convention for shutting down logins?

Edit: in addition to stopping wp-login.php, I deleted xmlrpc.php which was being used as another entry into brute forcing logins. My current setup doesn't need it but yours might. Be sure you don't need it before you disable it.

  • May this help you: wordpress.stackexchange.com/questions/62889/…
    – jas
    Nov 14, 2015 at 16:42
  • I would think a strong password would be sufficient unless the amount of traffic is bringing down your site from large number of PHP processes + DB checks Then you could try HTTP authentication to avoid the bots touching your wp-login.php or xmlrpc.php files (no php + db processes).
    – birgire
    Nov 14, 2015 at 16:48
  • @jas - I tried deleting the wp-login.php file altogether. I'm still getting "login failed" alerts. They're able to login through different methods, other than the wp-login.php page. Nov 14, 2015 at 20:42
  • @birgire - I have strong passwords but this is a decent size attack. I'm hoping this will be something I can implement in case of a larger attack, as well. Are wp-login.php and xmlrpc.php the only places someone can authenticate into the site? Nov 14, 2015 at 20:44
  • 1
    @cameck I finally stopped getting failed login attempts when I deleted xmlrpc.php Looks like they were using that as a more programmatic way of logging in. Nov 20, 2015 at 5:18

3 Answers 3


Failing to authenticate should do the trick for all the kinds of possible authentication - login form, xmlrpc, ajax, whatever

Edit: actually realized there is a way to save sending the user related query to the DB

function wpse208677_authenticate($user,$username,$pass) {
  return null;
  // if you want to whitelist your ip check for it and return $user

add_filter('authenticate','wpse208677_authenticate', 10,3)
  • That's helpful but I'm looking for a way to short circuit the login from the start. I have sucuri and another plugin in place that alert me on brute force attacks. I'm concerned that this would still trigger the actions on those plugins. Nov 14, 2015 at 20:40
  • @MichaelKhalili, you can not realistically do that as login attempts can come from all kinds of sources. If you are interested to block only wp-login.php or xmlrpc.php you should do it on the webserve config level (htaccess in apach can do the trick as well) and not let php run at all. The only comparable (performance wise) PHP code will need a modification of wp-config.php which is a file you should avoid touching as much as possible. Any other php based solution will not be better performance wise then the answer. Nov 20, 2015 at 5:44
  • I have figured this out, since I posted the question and updated my post. I can put the code which looks for $_POST['pwd'] in a must use plugin (mu-plugins) and disable the xmlrpc.php That seems to be doing the trick. I got most of the attacks stopped with $_POST['pwd'] and the rest stopped after I disabled xmlrpc.php Nov 20, 2015 at 16:21
  • 1
    The problem with deleting files is that they will be back when you upgrade. better to block in htaccess if you don't use xmlrpc Nov 20, 2015 at 17:20
  • 2
    Regarding disabling XML-RPC safely, I found out that you can disable it using a filter add_filter('xmlrpc_enabled', '__return_false'); There are also several plugins that'll do this for you. I used this one wordpress.org/plugins/disable-xml-rpc Jan 20, 2016 at 1:25

The top answer here is horribly bad PHP code, completely broken. Here is a good version. My reputation points are too low to comment on the original answer.

This code can be placed at the very bottom of wp-config.php in a pinch.

function wpse208677_authenticate($user,$username,$pass) {
  return null;
  // if you want to whitelist your ip check for it and return $user
add_filter('authenticate','wpse208677_authenticate', 1,3)

Another option is to prevent access to the login/register pages. This even works behind a hidden login url for WordPress. This code can be placed at the very top of wp-config.php (after the opening <?php.

if ( in_array( $_SERVER['PHP_SELF'], array( '/wp-login.php', '/wp-register.php' ) ) ){
    die('Site in maintenance mode.');
  • 2
    I'm sorry but that's a very bad idea to put the code in the wp-config.php file. Also, I don't see how your code is different than the other answer?
    – Johansson
    Mar 19, 2018 at 8:39
  • 2
    The previous answer by Mark K answer has been updated by you Jack yesterday, fixing the typo that I had fixed. It is bad idea to put code in wp-config, this was in an emergency scenario for someone who knows what they are doing. The earlier we step in, the less resources WP needs to load to block logins.
    – Branndon
    Mar 20, 2018 at 14:17

you can fix this issues using

change "wp-admin" directory and protect this directory using .htaccess password

  • 1
    Anyone considering this should remember that public ajax requests are still made to the wp-admin directory. If your site uses ajax, you should unblock the path to admin-ajax.php Nov 14, 2015 at 21:14
  • 1
    And as WP uses AJAX in core, this is shouldn't be done anywhere.
    – kaiser
    Nov 14, 2015 at 21:45
  • I agree that is not the solution to "disable" user registration/login, which is the question qhere. But @kaiser, why do you say this shouldn't be done? I do in two websites I personally manage where there is no users registration enable. I also use .htaccess password protection for wp-login.php file. If it is properfly configured, Ajax requests and other stuff from wp-admin (JS, CSS, images) are not a problem at all and it may reduce drastically the success possibilities of brute force attacks.
    – cybmeta
    Nov 25, 2015 at 6:01
  • @cybmeta you renamed wp-admin?
    – kaiser
    Nov 25, 2015 at 11:25
  • No, I didn't. That is another option but it is less secure, the admin URL of the site can be easily discovered, no matter what name you have given. Anyway, that doesn't explain why blocking access to that location shouldn't be done at all. Also, I don't see how changing the name is better than blocking the access to some location. Note that the context is that no one except you are going to access there, why blocking the access to anyone else is bad?. Currently, in the case only you is allowed to access to wp-admin, I would block wp-admin with .htaccess even if the name is changed.
    – cybmeta
    Nov 25, 2015 at 12:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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