Support » Plugin: iThemes Security (formerly Better WP Security) » after iTheme security updates I am Locked out of my site

  • I set the settings to rename the login path from “wp-admin” to something else and updated the database prefix and now I am locked out of my site. I get a 404 message when I try to go to either the wp-admin or the new path. help!

Viewing 15 replies - 1 through 15 (of 16 total)
  • MATT M



    You can temporarily disable iThemes Security features by adding the code below to your wp-config.php file above the “That’s all, stop editing! Happy blogging.” comment. Note you’ll need to remove it to re-enable the features of Security Pro.

    define(‘ITSEC_DISABLE_MODULES’, true);



    thanks that worked. I went to the “security check” screen and it is giving me an error: Invalid IP returned: <server IP address>?

    Without providing the actual server IP address, it would help to add a server IP address to this topic that resembles the actual IP format.

    thanks, here is the iP example. Invalid IP returned: 123.456.78.9

    Ok, that looks like a regular IPv4 address (no CIDR notation).

    Usually it’s not just an IP address that gets returned as you can see in the article below:

    What Does It Mean When An Invalid IP Is Returned Error In The Security Check?

    So in your case I don’t think this has anything to do with your webhost blocking loopback requests …

    What PHP version is the site using ?

    Thank you, the PHP version is 7.4.10. also, on the same server I have another WordPress site that has ithemes security installated and it is working fine.

    thanks for your help

    Hmm, ok weird.

    Would be interesting to see what loopback IP has been detected on the other WordPress env.

    Add the line below to the wp-config.php file of the other env:

    define('ITSEC_DEBUG', true);

    This will add an extra Debug menu option within the Admin Dashboard (frontend site remains unchanged).

    Navigate to the Security/Debug menu option. In the Settings section of the Debug page select ‘global’ and then click on the Load button. Scroll down to the bottom and lookup the server_ips value.

    Is this the same IP address that is reported to be invalid in the other WordPress env?

    Do make sure to undo the change to the wp-config.php file once you are done;-)

    thanks, on the other site the “server_ips” is the same IP address.
    – the only 2 things that do not “appear” to work is the secure login (I changed it to something else from the default wp-login) and the error with the ipaddress if this helps. Also, I’m on an iis server if that is an issue. thanks for your help!

    Ok, I see.

    You can repeat the previous steps of enabling the Debug page and checking the server_ips value(s) on the env showing the Invalid IP returned: <server IP address> error.

    There is a good chance the “invalid” IP is actually stored in the server_ips despite the loopback IP identification step failing.

    The previous step, Identify server IPs to determine loopback requests, does not validate IPs and seems to run fine. It stores any IPs found in the same location (server_ips).

    Basically you can safely ignore the fact that loopback IP identification is failing.

    If you like we can dig a little deeper and write a simple PHP script that performs exactly the same IP validation. This will help figure out where exactly it’s failing to validate the (loopback) IP.

    • This reply was modified 1 month, 1 week ago by nlpro.

    Oh, I forgot to mention that the first 2 bytes (3 digit numbers) in the IP address should be between 0 and 255 (0 and 255 included). So 123.234. is valid, 456.567. is not valid. Kind of assuming that your non validating IP complies with this. But you never know …

    Also ruled out the possibility of spaces or other characters at the start/end of the IP. Turns out the PHP trim() function is being used to trim garbage chars from the start/end of the IP.

    Just out of curiosity I wrote a simple validation script that copies the plugin IP validation method and did some tests. Does exactly what I expect it to do. So the validation method is ok.

    great, thanks here is the debug from the site that shows the “invalid” IP error. but the main issue is that I have to disable the ithemes security to login. I added my IP address range to the white list, but when I go to the login page I still get redirected to the 404 page

    “lockout_message”: “error”,
    “user_lockout_message”: “You have been locked out due to too many invalid login attempts.”,
    “community_lockout_message”: “Your IP address has been flagged as a threat by the iThemes Security network.”,
    “blacklist”: true,
    “blacklist_count”: 3,
    “blacklist_period”: 7,
    “lockout_period”: 15,
    “lockout_white_list”: [

    “log_rotation”: 60,
    “file_log_rotation”: 180,
    “log_type”: “database”,
    “log_location”: “F:\\Website/wp-content/uploads/ithemes-security/logs”,
    “log_info”: “-GQARSy3MxTmxpWP3LHK2WNhZqbydwO”,
    “allow_tracking”: true,
    “write_files”: true,
    “nginx_file”: “F:\\Website/nginx.conf”,
    “infinitewp_compatibility”: false,
    “did_upgrade”: false,
    “lock_file”: false,
    “proxy”: “automatic”,
    “proxy_header”: “HTTP_X_FORWARDED_FOR”,
    “hide_admin_bar”: true,
    “show_error_codes”: false,
    “show_security_check”: false,
    “build”: 4121,
    “initial_build”: 4119,
    “activation_timestamp”: 1600563612,
    “cron_status”: 1,
    “use_cron”: true,
    “cron_test_time”: 1603341455,
    “enable_grade_report”: false,
    “server_ips”: [
    “<is the same IP address for the server so this looks OK>?”
    “feature_flags”: [],
    “manage_group”: [
    “licensed_hostname_prompt”: false

    I guess you are referring to the Hide Backend and Change Database Table Prefix features(modules). In general it’s best to enable one module at the time. Do some tests and then if all is fine move on to the next module.

    Have you tried disabling the Hide Backend module (and removing the ITSEC_DISABLE_MODULES define from the wp-config.php file, if not already). If the 404 issue persists then it’s probably related to the Change Database Table Prefix module.

    Back to the IP validation issue.
    Please try the PHP script below for a simple IP validation test:

    $ip = 'your_server_ip';
    if ( filter_var( $ip, FILTER_VALIDATE_IP, FILTER_FLAG_IPV4 ) ) {
        echo 'Valid IPv4';
    } else {
        echo 'Invalid IPv4';

    Replace your_server_ip with the IP failing validation. Name the file ip_test.php. Put it in the root of the WordPress site and then try the URL below:

    Where should be replaced with your site domain name 😉

    Thanks, I ran the script on the server and it came back “Valid IPv4”. I disabled the Hide Backend, logged out, commented out the ITSEC_DISABLE_MODULES and tried to go to the default WordPress login /wp-login.php and I am still getting the 404 error. Thanks for your help. I am a little concerned since I already updated the database prefix in the database via the “Change Database Table Prefix” in iThemes it may cause more issues so I am concerned about disabling this?

    I found something interesting. when i uncommented the ITSEC_DISABLE_MODULES and typed in the custom hide backend URL it took me to the login page even though I disabled the “Hide Backend” option..

    I changed the custom login to something else like “securelogin”, logged out then tried to get to the login page with /securelogin, but it gave me a 404. then I tried the prior /securenewlogin that was originally there and it worked it let me get to the login page…wierd… prior I was using another module that hid the backend, but I un-installed it?

Viewing 15 replies - 1 through 15 (of 16 total)
  • You must be logged in to reply to this topic.