IniLerm

Hello wweber,

Thank you for reaching out and providing such a detailed observation! You are absolutely right to keep an eye on your server logs.

To answer your question directly: Yes, this is an automated vulnerability probe/scan, but your site is safe.

Here is a breakdown of exactly what is happening, why you are seeing those specific HTTP codes, and why it doesn’t show up in the plugin logs:

1. What is the bot looking for?

Bots constantly scan millions of domains looking for forgotten or incomplete WordPress installations. If they find an unprotected install.php that hasn’t been configured yet, they will attempt to complete the setup process to hijack the database and take over the website.

2. Why the 301 followed by a 200 OK?

The 301 Moved Permanently response you saw wasn’t a special header addition—it was almost certainly an HTTP to HTTPS (or non-www to www) redirect enforced by your server.

1. The bot blindly hits http://yoursite.com/wp-admin/install.php?step=1.
2. Your server replies with a 301 to redirect it to the secure https:// version.
3. The bot follows the redirect and gets a 200 OK.

A 200 OK status on an already installed WordPress site simply serves a harmless page that says: “You appear to have already installed WordPress. To reinstall please clear your old database tables first.” No sensitive data is leaked, and no harm is done.

3. Why Cloudflare IPv6 if you don’t use it?

Attackers frequently use Cloudflare’s free VPN service (WARP) or abuse Cloudflare Workers to proxy their traffic. This masks their true IP address and makes the traffic appear as if it’s coming from a legitimate Cloudflare IPv6 address.

4. Why isn’t this in the Advanced IP Blocker logs?

Advanced IP Blocker is designed to keep your database lean and fast. It logs blocked requests (such as SQL injections, brute-force attempts on wp-login.php, blocked countries, or known malicious payloads). A standard GET request to a legitimate core WordPress file (install.php) doesn’t inherently contain a malicious payload, so the WAF allows WordPress to handle it normally. Since no security rule was triggered to block it, it isn’t logged by the plugin.

How to proceed?

You don’t need to do anything, as WordPress inherently protects already-installed sites from this. However, if you want to keep your access logs clean and block these probes proactively, you can do so easily with Advanced IP Blocker:

1. Go to Advanced IP Blocker > Advanced Rules.
2. Create a new rule.
3. Set the Condition: URI -> contains -> install.php
4. Set Action: Block (Permanent or whatever duration you prefer).

Once saved, the plugin will intercept these probes and immediately drop the connection, and you will start seeing them in your Security Logs!

Let me know if you have any other questions. We’re always happy to help!

Hello @cousineddie,

Thank you for reaching out!

There is absolutely no need to worry about this error. Your WP-Cron Status Checker plugin is just letting you know that the Cloudflare Sync task took longer than 5 minutes to complete, so your server automatically paused it.

Why does this happen? When the advaipbl_cloudflare_sync_event runs, it communicates with the Cloudflare API to push your locally blocked IPs into your Cloudflare Firewall. If you have hundreds or thousands of blocked IPs, sending them one by one over the internet can take longer than the strict 5-minute timeout window enforced by most hosting providers.

How to get around it: The short answer is: You don’t need to do anything.

Our plugin is designed to be fully resilient to these timeouts. We use a “Delta Sync” architecture. This means that if the sync times out halfway through, the plugin won’t start from scratch next time. On the next hourly cron run, it will automatically detect which IPs are still missing and resume exactly where it left off. Over a few cycles, it will fully catch up without any intervention from you.

Note: Just keep in mind that Cloudflare has limits on how many IP Access Rules you can create depending on your plan (e.g., Free plans have a much lower cap than Pro/Biz plans), so if your local blocklist is extremely large, Cloudflare might eventually reject new rules once you hit their account limits.

You can safely ignore that warning email. The plugin will continue to sync your IPs incrementally in the background.

Best regards,

Thank you so much for the 5-star rating! ⭐⭐⭐⭐⭐

Hello @olegchuvakin,

Thank you for reaching out and using Advanced IP Blocker!

This notice appears because we recently upgraded our backend to a new API architecture (v3), which allows the plugin to handle a much larger threat feed (100,000+ IPs instead of the old 50,000 limit).

Even though your current API key shows as “valid and active”, it seems your site is still holding onto an older V2 key from before the upgrade, which is triggering the limitation warning.

To permanently dismiss this notice and upgrade your protection to the v3 feed, please follow these steps:

1. Update the plugin: First, make sure you are running the latest version of the plugin (8.10.15 or higher).
2. Delete the old key: Go to Security -> Threat Intelligence -> AIB Community Defense Network. Click the “pencil” (edit) icon next to your current API key, delete the key completely so the field is empty, and save the settings.
3. Generate a new key: Once the field is empty, a button to generate a new API key will appear. Click it to register a fresh, v3-compatible key.
4. Verify: Click “Verify Connection” one last time.

Once the new key is generated and saved, the 50,000 IPs limitation message will disappear for good, and your site will sync with the expanded threat feed.

PRO TIP: Right after renewing your API Key, you might see a status saying “Waiting for the first download”. Don’t worry, this is completely normal! The initial sync depends on the scheduled WordPress Cron job, which executes automatically (up to a maximum of every 6 hours). Your feed will update on its own shortly.

Let me know if this solves the issue for you!

Best regards,

• This reply was modified 3 months, 1 week ago by IniLerm.

Quick follow-up @cousineddie!

I went ahead and dug into the Soro app’s internal source code to give you the most secure and precise solution possible.

I found that Soro doesn’t use the standard WordPress posting routes; they register their own custom REST API namespace (/soro/v1/).

Because of this, you don’t need to whitelist the entire WordPress API in our firewall (which is great for your overall security). You only need to whitelist their specific route.

So, in the “WAF Excluded URIs” box (Security -> Settings -> Web Application Firewall), simply add this exact line:

/soro/v1/

This acts as a surgical VIP pass. The firewall will stand down only when the Soro app is trying to connect, while keeping the rest of your site fully shielded against automated attacks.

Let me know if the publishing works smoothly now!

Hi Gregg,

Just to add a final official note here for any other ClassicPress users who might stumble upon this thread in the future:

We are thrilled to officially confirm that Advanced IP Blocker is fully compatible with ClassicPress v2 (and higher).

Because our plugin’s architecture was built from the ground up focusing on extreme performance and security, we do not rely on React, Gutenberg blocks, or Full Site Editing (FSE). Our WAF and admin dashboards use clean, vanilla JavaScript and standard PHP, which perfectly aligns with the ClassicPress philosophy of keeping things lightweight and bloat-free.

However, for anyone installing this on ClassicPress, please keep these two strict requirements in mind:

1. ClassicPress v2+ Only: Our codebase utilizes native polyfills and functions introduced in later core versions (specifically 5.9+). Since ClassicPress v2 is based on the WP 6.2 core, it handles these flawlessly. ClassicPress v1 (based on WP 4.9) is not supported.
2. PHP 8.1+ is Strictly Required: We utilize modern, highly secure cryptographic libraries (especially for our Two-Factor Authentication module) that strictly require PHP 8.1 or higher. If your server is running PHP 7.4 (which is still somewhat common in the CP community), the plugin will refuse to activate.

Good news: Starting from version 8.10.14, we have officially adjusted our core version headers (Requires at least: 5.9) so that the ClassicPress v2 native installer will no longer block the installation out of the box. You won’t have to manually edit the plugin headers anymore!

Thanks again for testing it across your 100+ LiteSpeed installations and for trusting us to secure your clients.

Best regards, The Advanced IP Blocker Team

Hi @greggwatson,

Thank you so much for the kind words! We are thrilled to hear that Advanced IP Blocker is your favorite security plugin and your go-to choice for client installations.

Regarding ClassicPress: Structurally, our plugin is actually highly compatible with the ClassicPress philosophy. We do not rely on React, Gutenberg blocks, or Full Site Editing (FSE). Our WAF and admin panels are built efficiently with pure PHP, jQuery, and vanilla JS.

If the plugin is failing to install or activate on your clients’ ClassicPress sites, it is almost certainly due to two strict server requirements we currently enforce in our core files:

1. PHP 8.1+ Requirement: Advanced IP Blocker strictly requires PHP 8.1 or higher (primarily for our 2FA cryptographic libraries). Since the ClassicPress community is often conservative with server environments to ensure stability, many sites still run on PHP 7.4. If the server is on PHP 7.4, the plugin will refuse to activate.
2. Core Version Check: Our plugin header specifies Requires at least: 6.7. Because ClassicPress v2 is based on the WP 6.2 core (and v1 on WP 4.9), the native plugin installer might block the installation thinking the core version is outdated.

How to make it work right now: If you ensure that the ClassicPress server is running PHP 8.1+, you can install the plugin manually (via ZIP upload or FTP) and it should run smoothly without any Gutenberg-related conflicts.

We love the performance and security-focused mindset of the ClassicPress community. We will definitely look into officially testing and supporting ClassicPress in a future update, potentially by adjusting our version headers to prevent installation blocks on CP v2.

Please let me know if ensuring PHP 8.1 resolves the issue for your clients!