IniLerm

Hi @anotherwebdev,

Thank you so much for this amazing 5-star review! Reading that Advanced IP Blocker has become an essential tool for every WordPress site you manage truly makes our day.

We completely understand what you mean about the learning curve—security can definitely be daunting at first, and almost locking yourself out is a rite of passage for all of us! We are constantly working on improving the interface to make all those powerful options as intuitive as possible.

Regarding your kind words about a donation: please, do not worry about that right now! Our primary goal has always been to provide enterprise-level security for everyone, regardless of their budget. Your support, your trust in using it on all your sites, and taking the time to write this wonderful review is already a massive contribution to the project.

Keep building great sites, and thank you for being a part of our community! ⚡

Best regards,The Advanced IP Blocker Team

Hi Pat K,

Thank you so much for taking the time to share this incredibly detailed and accurate heads-up with the community! You’ve hit the nail right on the head, and your understanding of how the plugin interacts with the database is 100% correct.

You are absolutely right: when a country is added to the strict GeoBlocking tool with a “Permanent” block duration, every single IP from that country that hits your site gets permanently written into the database. Under heavy traffic or bot scans, this can cause the database table to bloat over time. While Advanced IP Blocker is highly optimized, a massive database table will inevitably slow down queries, especially on hosting environments with limited resources.

Your solution to switch to the Geo-Challenge is brilliant. The Geo-Challenge acts as a lightweight shield—it intercepts and challenges the traffic at the edge without needing to write a permanent database record for every single visitor. It consumes far fewer server resources while keeping your site perfectly safe.

Taking this a step further, we actually highly advise against using “Permanent” blocks in any of the plugin’s modules (Lockdowns, Threat Score, etc.) for this exact reason. The recommended best practice is to set your block durations to 1440 minutes (24 hours).

A 24-hour block is the sweet spot: it is long enough to stop an attacker or a botnet in its tracks, but it allows the plugin to naturally “self-clean” expired IPs from the database every day. This keeps your database lean, fast, and completely immune to bloat over time.

Regarding your cleanup task, you are doing it perfectly. Filtering by “Permanent” in the block list and bulk-deleting them is the way to go to restore your database to peak performance.

Thanks again for sharing your experience. Feedback like yours is what makes this community so great, and I’m sure it will help many other users optimize their setups!

https://wordpress.org/support/topic/country-blocking-geoblocking-or-geo-challenge/

Best regards,
Advanced IP Blocker Team

• This reply was modified 1 month, 2 weeks ago by IniLerm.

Hi Pat (@blackcapdesign),

Thank you so much for reporting this issue and providing such clear details about your setup. Your information was incredibly helpful in tracking this down!

After investigating, we identified a conflict where Advanced IP Blocker was being a bit too aggressive when scanning POST requests. It was inadvertently intercepting standard captcha response fields (like the ones used by Cloudflare Turnstile or hCaptcha) from third-party plugins during the login process, leading to the “Verification failed” error.

I am pleased to inform you that we have completely resolved this bug in our latest release (version 8.11.10). We refined our Captcha Engine so that it now strictly requires an internal signature to validate a challenge, ensuring 100% compatibility with your existing Turnstile setup and other third-party captchas.

The new version (8.11.10) has just been deployed to the repository. It usually takes WordPress.org a little time to synchronize, so the update should become available in your WordPress dashboard within the next 6 hours.

Once you update, your clients will be able to log in normally without any verification errors. Please let us know if everything works smoothly for you after the update!

Best regards, Advanced IP Blocker Team

Hi Pat,

Thank you so much for the detailed report and for taking the time to investigate the issue down to the exact file and line! You hit the nail on the head, and your debugging helped us identify a conflict.

1) Why is AIB intervening? Because Cloudflare Turnstile uses a standardized POST field name (cf-turnstile-response), AIB was inadvertently intercepting this global field during the early init phase of WordPress. When it saw the Turnstile token submitted by your membership plugin, AIB mistakenly assumed it was a response to an AIB security challenge. Since you (correctly) didn’t configure the Turnstile keys in AIB, our verification instantly failed, triggering that hardcoded error screen and completely blocking the actual login process.

2) How to mitigate this? You don’t need to switch to CleanTalk! We have just patched this bug in our core. Moving forward, AIB will strictly look for a custom internal hidden field (_advaipbl_challenge_type) before attempting to validate any captcha token. This ensures AIB will only ever process its own security challenges, completely ignoring third-party login or membership captchas.

This fix will be included in our upcoming v8.11.10 release within the next 24 to 48 hours. As a temporary mitigation until the update drops, you can either temporarily disable Turnstile on that specific login form, or if you feel comfortable editing the plugin file via FTP, you can modify line 25 of includes/class-advaipbl-captcha-manager.php from this:

public function verify_submission() {
// phpcs:ignore WordPress.Security.NonceVerification.Missing
if (!isset($_POST['cf-turnstile-response']) && !isset($_POST['h-captcha-response'])) {
return;
}

To this:

public function verify_submission() {
if (!isset($_POST['_advaipbl_challenge_type'])) {
return;
}
// phpcs:ignore WordPress.Security.NonceVerification.Missing
if (!isset($_POST['cf-turnstile-response']) && !isset($_POST['h-captcha-response'])) {
return;
}

We truly appreciate your help in making Advanced IP Blocker better. Please let us know if you have any other questions!

Pro Tip 2: Managing Rules Across Multiple Sites (Agency Workflow)

Since we are discussing advanced rule configurations, we wanted to share a workflow tip that is incredibly useful for agencies and power users managing multiple WordPress installations.

Once you have crafted and tested your perfect set of Advanced Rules on one site (using the parallel AND rules as discussed above), you don’t need to recreate them manually everywhere else.

You can use the Import/Export feature located at the top of the Advanced Rules manager. With a single click, you can export all your complex conditional logic into a cleanly formatted .json file. You can then import this exact JSON configuration into any other site running Advanced IP Blocker. The engine automatically handles validation and structural deduplication, meaning you can instantly clone your bulletproof firewall setup across your entire network of client sites in seconds.

Hope this helps streamline your security deployments!

Pro Tip / Word of Caution for anyone reading this thread:

Just a quick follow-up regarding the specific example rule mentioned: IF (URI == /) AND (Hostname IS EMPTY)

We strongly advise against creating rules that block or challenge traffic solely based on an empty Hostname (rDNS). While it might seem like a good way to catch bots, many legitimate Internet Service Providers (ISPs) and mobile carriers around the world still fail to properly configure reverse DNS for their customers’ dynamic IPs. Enforcing a strict “Hostname cannot be empty” rule will inevitably lead to a high number of false positives, locking out real human visitors.

This is exactly why our global “Ghost IPs” feature is designed the way it is. It operates on a strict AND logic internally: it only flags an IP if BOTH the ASN is empty AND the Hostname is empty simultaneously. An IP missing both identifiers is almost guaranteed to be a malicious actor or a hidden proxy.

Advanced Rules give you immense power to shape your firewall, but please use broad conditions like Hostname IS EMPTY with extreme caution!

https://advaipbl.com/block-ghost-ips-rdns-asn/

• This reply was modified 2 months ago by IniLerm.

Hi @thewatchman3,

First of all, I want to deeply thank you for this absolutely outstanding and incredibly detailed bug report. The exact trace you provided, along with the reproduction steps and suggested fixes, is a masterclass in debugging. You saved us a tremendous amount of time investigating this critical edge case.

You were 100% correct in your analysis. The combination of the re-entrant block loop and the lack of X-Accel-Expires: 0 during the premature exit was causing a devastating cache poisoning scenario on aggressive Nginx/FastCGI setups like Kinsta.

I’m happy to inform you that we have just released Version 8.11.7 as an urgent security update, which fully resolves this issue. We implemented all of your suggested fixes:

1. Re-entry Guard: The access_denied_page() guard no longer bare-exits. It now safely breaks the recursion loop and strictly emits a 403 Forbidden status along with X-Accel-Expires: 0 before halting.
2. Cache Headers: X-Accel-Expires: 0 is now forcefully injected across all block rendering paths (including the XML-RPC fallback) to prevent edge caches from storing the response.
3. Transient Guard: We updated the $all_block_types matrix inside handle_error() to include the modern block types (impersonation and aib_network), ensuring their cooldown transients are respected and preventing the infinite threat-score loop.
4. Expiration Check: The existence check in block_ip_instantly() was patched to explicitly ignore stale records (expires_at), preventing fresh blocks from wrongly routing into the already-blocked branch.

The update is now live on the repository (available in a few hours). We also gave you a shoutout in the changelog!

Thank you again for your incredible contribution to the Advanced IP Blocker community. If you notice any other anomalies, please don’t hesitate to reach out.

Best regards, The Advanced IP Blocker Team

Hi @wpbluefox,

That’s a great question!

Yes, Yandex bot is already fully included in our impersonation and verification checks.

While the documentation only highlights Googlebot and Bingbot as quick examples, under the hood, the Advanced IP Blocker engine actually verifies traffic claiming to be from Yandex as well. If a visitor claims to be Yandex bot in their User-Agent, our engine automatically performs a strict Reverse/Forward DNS check to ensure the connection genuinely originates from official Yandex infrastructure (.yandex.com, .yandex.ru, or .yandex.net).

If the IP fails this verification, it is instantly blocked for impersonation.

We will make sure to update the documentation to explicitly list Yandex alongside the other major search engines so it’s clearer for everyone. Thanks for pointing this out!

Best regards, The Advanced IP Blocker Team