To tighten security on your WordPress website, you want a 2-factor authentication (2FA) mechanism to provide identity approximation, and a Captcha to prevent notorious bots from rampaging the wp-admin
login page (or any other equivalent). With that said, there is Wordfence, a top player in WordPress security, which can provide a 2-factor authentication feature for your WordPress website.
Along the line, you decided to utilize Cloudflare Turnstile, a recently released but promising Captcha service due to its user-friendly and more privacy focus approach. You enabled both of them as instructed, and decided to log out of your admin account to test out the services, but then .
On first look, the services seem to work. Cloudflare Turnstile appears on the login page and the login attempt leads to a 2-factor authentication on your screen. You type in the 2FA code and expect to be redirected to the WordPress dashboard, but the redirection turned out to be unexpected.
You are redirected to the login page again, with an error message from Cloudflare Turnstile:
Please verify that you are human.
You think the 2FA code was mistyped, or somehow the Cloudflare Turnstile accidentally misrecognize the request as a bot and decide to try again, but unfortunately, the result is the same. At this point, you are stuck in a login loop and completely locked out of the WordPress admin dashboard.
As the error message is from Cloudflare Turnstile, perhaps, disabling this Captcha service can solve the issue. However, with no access to the WordPress dashboard, you decide to disable it on the Cloudflare Dashboard instead. In the Cloudflare Turnstile Analytics dashboard, you see a noticeable spike in blue values - unsolved Captcha requests. The time stamp aligns with when you start facing the problem.
The thing is, there is no trivial way to disable Cloudflare Turnstile here, so you decide to rotate the secret key. After the rotation, you still face the same loop on the WordPress login site. It might take a bit to propagate the change, or so you thought. That's correct, but after about 15 minutes, the change propagates and you see this Cloudflare Turnstile error message upon refreshing the WordPress login page.
Invalid domain. Contact the Site Administrator if this problem persists.
Now, you cannot even go to the 2FA code screen. Your username and password cannot be submitted as Cloudflare Turnstile completely blocks the login process after secret key rotation due to security reasons. Somehow, the problem is now even worse than before.
In the large picture, this can potentially be a problem with other Captcha services too. At the moment, it is certain that the Wordfence 2FA and Cloudflare Turnstile are incompatible and causing havoc. Disabling these services and reverting the WordPress site to a known and good state is the goal, but that seems to be impossible when being locked out of the admin dashboard, or is it?
WordPress backup and restoration is trivial from the admin dashboard with the help of plugins, All-in-One WP Migration for example. This path is not available at the moment. Infrastructure snapshot restoration is another choice, but what if you don't have one? How about directly accessing and modifying WordPress content at the file system level? If your WordPress site is fully managed by a third party, you might have limited control of the web server. However, if an option is available from your WordPress hosting provider, or you are self-hosting, you can SSH directly to the server and modify your WordPress installation via an admin dashboard.
Following the previous article: Host a free WordPress site with Google Cloud and Cloudflare, let's say your WordPress site is hosted on Google Cloud using WordPress Certified by Bitnami and Automattic on a Compute Engine, then there is an out-of-the-box and secure way to SSH to the web server via Google Cloud Compute Engine Dashboard (marked yellow in the picture below).
The secure SSH session is fully managed by Google Cloud, so you don't have to worry about any form of configuration. After a bit, the terminal of your virtual machine (Compute Engine).
Your terminal may resemble or vice versa depending on the virtual machine configuration. For an out-of-the-box setup from Bitnami, it should be the same.
The goal is to find out where WordPress plugins (Wordfence and Cloudflare Turnstile) reside on your web server and disable them from there. With that said, run the following commands:
# Move to where the plugin folder locates
cd ../bitnami/stack/wordpress/wp-content
# Rename an existing, "broken" folder to disable the plugins
sudo mv plugins plugins-old
At this point, your plugins are all disabled, but no worries, they can be restored later. Don't close the SSH window, but let's put that aside for now.
Then, go back to your WordPress admin login page (wp-admin
or any other equivalents). As both Wordfence 2FA and Cloudflare Turnstile are disabled, you can log in to the WordPress admin dashboard without any problem. Once you are in the dashboard, your browser stores a login session and it survives page refresh, so do not log out of this step.
Now, return to the Compute Engine SSH window, and run the following command.
sudo mv plugins-old plugins
By renaming the plugins-old
folder back to the original one, now your WordPress site detects the existence of plugins and applies them accordingly, including the problematic login loop bug. A refresh of an admin dashboard can reflect the changes. That said, as your login session is still there, you can simply go ahead and disable Wordfence 2FA and Cloudflare Turnstile in the WordPress admin dashboard. The problem is solved, and the login loop is now gone!
Wordfence and Cloudflare Turnstile are great services to up your WordPress security game. That said, with Wordfence 2FA specifically, there seem to be problems regarding its interaction with Captcha service in general, or at least, in a specific set of conditions.
Whether you can SSH to the web server is an obstacle, as, you are using hosting on a fully managed provider. If you do have access, using SSH and directly modifying files on the web server, the issue can be resolved with relative ease. Hopefully, this tutorial help you recover the website in a matter of minutes.
Interested in web development, IT content, and more? My other articles might be helpful to you!
Also, let's connect!