How To Resolve WordPress Invisible Recaptcha Admin Login Issues

Do you have invisible recaptcha installed on WordPress and having admin login issues? Our team recently ran across the same issue and after tons of research and testing, we found the cause and a solution. It turned out to not be any of the usual causes.

WordPress Invisible Recaptcha Usage

As one of our WordPress security practices for our client websites, we always install invisible recaptcha for login, registration, and inquiry form protection. Also known as “Recaptcha v2 Invisible”, this is a newer version of recaptcha which only shows a recaptcha logo at the bottom of the site or page and the “I’m not a robot” check only shows in certain circumstances; mainly when the form is filled out too fast.

Our preferred free plugin for this is simply called Invisible Recaptcha and it can be found in the WordPress free plugin library. This one is by far our favorite as it covers all of the following:

• WordPress Admin login, password reset, lost password, and comments posting protection options.
• Woocommerce register and login protection options.
• UltraCommunity protection options.
• BuddyPress protection options.
• Protection options for the most popular form plugins including: Gravity Forms (our favorite) and Contact 7 Forms; with additional options to globally enable for all Gravity forms and exclude certain Gravity forms.

WordPress Admin Login Issues Appeared

Recently we discovered that all of our client WordPress websites that had the Invisible Recaptcha plugin installed were no longer allowing admins to login to their websites. Admins would enter their logins and submit, the page would refresh and it was right back to the login screen with no error messages. My team quickly disabled this plugin across all of our client websites and began our research into this issue.

We looked into the normal set of usual suspects and data including:

• Confirmed that the RECAPTCHA keys we were using were valid and that the logo was showing.
• Error logs showed nothing pertaining to this event.
• Tried using several different plugins, all had the same results.
• Various comparisons on software versions being used at site and server levels to look for a pattern. No patterns found.
• Searching support forums yielded no results on this specific issue.
• Any topic we did find was related strictly to issues with wrong version of recaptcha keys being used.

My team was at a loss for finding the cause of this issue. While we do have other security plugins in place on our client websites that handle the higher level security protection, the fact was until we found the cause our clients could be getting a sudden influx of spam or failed admin login attempts that are normally blocked by Recaptcha.

Finding The Cause By Accident: ModSecurity

Some days later we finally discovered the cause of this issue, completely by accident. We had a client who reported that they accidentally got themselves blocked on one of our hosting servers. That same morning we had reinstalled Invisible Recaptcha onto a website to continue testing, which was still failing. While looking at the server security and firewall to unblock this client, we ran across the cause while reviewing the server security logs. Our servers are setup using WHM / CPANEL and one of the server security software tools we use called ModSecurity had been blocking all attempts to login to WordPress websites when the site was using Invisible Recaptcha.

Apparently there was a recent update to ModSecurity rules around the same time this issue started. These rules were giving a false positive every time an admin tried to login, so it was blocking admins from logging into their WordPress sites that had Invisible Recaptcha installed.

The Solution

If you are running into this issue and are being hosted on WHM / CPANEL servers, here is how you can determine if ModSecurity is causing this issue for you and how to resolve it. If you are on a shared hosting account and do not have access to the server WHM, then complete up to STEP 2 then skip down to the BONUS TIP section for a ready-to-use support email template.

STEP 1: Reinstall / Reactivate INVISIBLE RECAPTCHA

Then try to login as an admin via the yoursite.com/wp-admin/ login URL. This will ensure the issue is triggered.

STEP 2: Save The Date And Time Of Your Test

The main purpose of this optional step is if you don’t have access to WHM, so you can provide your hosting support team with the date and time of when you tried to login to your WordPress admin tools and it failed. This will help them track it down faster.

*NOTE: If you are on a shared hosting account. skip down to the BONUS TIP section at the bottom.

STEP 3: Access ModSecurity Hit List

Login to WHM, then in the left hand menu click on SECURITY CENTER, and then ModSecurity Tools. You will come to a page titled ‘HIT LIST’ which shows a table view of the most recent events that triggered ModSecurity rules. The columns that are most valuable here are:

• HOST column: tells you which domain triggered the rule.
• DATE column: tells you date and time of the triggered event.
• RULE ID column: this column will show you the rules which were triggered.

In our case rule #5000214 was the main cause, and rule #5000130 sometimes created similar issues too. So next let’s confirm which rules are causing this issue for you.

STEP 4: Locate The Triggered Rules

A “triggered event” refers to an instance where a security rule was “triggered”. The easiest way to find which rules were triggered is using the search tool as follows.

1. Enter 5000214 and click the ENTER button on your keyboard. Do you see an entry with your domain in the HOST column and this rule # in the RULE ID column? If not then try to search for 5000130.

2. Click on the ‘MORE’ link for at least one of the matching events where your domain is in the HOST column. You will see something similar to this

When we clicked on these events, we seen the following messages:

5000214:
Request:
POST /wp-login.php
Action Description:
Access denied with code 402 (phase 2).
Justification:
Operator EQ matched 0 at ARGS.

5000130: wp-login request blocked, no referer
Request:
POST /wp-login.php
Action Description:
Access denied with code 401 (phase 2).
Justification:
Operator EQ matched 0 at REQUEST_HEADERS.

Notice that wp-login is mentioned? That’s what we want to see, since its the page that WordPress uses to authenticate the login attempt. So now we have proof it is ModSecurity Rules that are triggering this issue. If we look further into the server logs, we find the following information which further confirms this.

[Tue Jul 02 16:31:30.309257 2019] [:error] [pid 4272:tid 47730616796928] [client xxx.xxx.xxx.xxx:37264] [client xxx.xxx.xxx.xxx] ModSecurity: Access denied with code 402 (phase 2). Operator EQ matched 0 at ARGS. [file “/etc/apache2/conf.d/modsec2/lw_virtual_patches.conf”] [line “41”] [id “5000214”] [msg “wordpress login missing action and or wp-submit arguments.”] [severity “WARNING”] [tag “critical_wordpress_protection”] [tag “lw_custom”] [hostname “wptest.tpphost.com”] [uri “/wp-login.php”] [unique_id “XRu-IoV1VwERRYs3VKSNgAAAAAE”], referer: https://www.yoursite.com/wp-login.php?redirect_to=https%3A%2F%2Fwww.yoursite.com%2Fwp-admin%2F&reauth=1

STEP 6: Whitelist / Ignore these rules!

For this next step you will need to comment out one or more of the rules that are causing this issue. Depending upon your version of WHM you may be able to edit the rule list directly, or you may have to go into your server and manually modify the rules. Ultimately the file you are looking for on a WHM server is likely in this location:

/etc/apache2/conf.d/modsec2/whitelist.conf

Which is the whitelist rules file for ModSecurity. The /modsec2/ portion of this URL may be different based upon your server version. Now let’s whitelist that rule by copying the following and adding it to your whitelist.conf file:

# Whitelisted due to WORDPRESS INVISIBLE RECAPTCHA trigger
<LocationMatch "/wp-login.php">
SecRuleRemoveById 5000214
</LocationMatch>

Save your changes, then restart APACHE to ensure the changes take effect (i.e. in WHM left column click RESTART SERVICES, then ‘HTTP Server (Apache)’ link, then click YES).

The great part about whitelisting it like this, is that it will ONLY whitelist WordPress login events that are triggered by this.

STEP 7: Try, Try Again

Now go back to your website and try to login as an admin again. If everything was done correctly, you should be good to go!

BONUS TIP: Support Email Template

If you are on a shared hosting account and do not have WHM SERVER access to perform these steps, then we have you covered! We are including an email template that you can copy and provide to your hosting support team that should help, which covers most of the vital information needed and lets them know this is NOT a website coding issue (coding issues are normally not covered with most hosting providers). Click COPY on the template below, update it with your website information, and submit it to your hosting support team.

WEBSITE ADMIN: 
www.yoursite.com/wp-admin/
username: yourusername
password: yourpassword

WEBSITE PLATFORM: 
WordPress

ISSUE:
I am using WORDPRESS with INVISIBLE RECAPTCHA plugin installed and I recently began having issues with being unable to login to my admin tools. This is not a website coding issue, but rather I believe is being caused by a false positive from one of the server WHM ModSecurity Rules and I need your assistance to resolve this please. 

When I attempt to login to my website admin tools, the page just refreshes without completing login and doesn't display any error messages. I have included admin logins so you can duplicate this issue.

I would ask that you please confirm this issue within the WHM > Security Center > ModSecurity Tools page, which will likely come back with a hit to rule ID 5000214. If so please whitelist this rule ASAP. I have been advised that this would be done within the /etc/apache2/conf.d/modsec2/whitelist.conf or similar location, as follows:

# Whitelisted due to WORDPRESS INVISIBLE RECAPTCHA trigger
<LocationMatch "/wp-login.php">
SecRuleRemoveById 5000214
</LocationMatch>

Thank you for your time.

In Summary

We hope that our on experiences with this uncommon set of WordPress admin login issues has helped some of you from pulling your hair out. If you find any other ModSecurity rules that are causing similar issues, or you have a slightly different setup and found another solution, please let us know via our comments section below and we will ensure to update this article.