The IP Whois box just shows an endless loading animation on all of my sites. This is related to the BBQ Firewall plugin which blocks the following request with a 403 response:
GET https://(hostname)/wp-admin/admin-ajax.php?ip=(ipv4)&ajax_route=ip_extra_info&action=cerber_ajax&ajax_nonce=ff251709be&request=0&referrer_page_url=https://(hostname)/wp-admin/admin.php?page=cerber-security&tab=activity&filter_ip=(ipv4)
A similar case was discussed in the BBQ Firewall support area, where Jeff pointed out that an unexpected “:” (colon) causes the issue. My guess is that the referrer_page_url parameter should be properly escaped.
The request that Cerber sends to admin-ajax.php is a completely normal WordPress AJAX request.
The referrer_page_url parameter contains a standard URL like https://example.com/wp-admin/admin.php?..., so seeing : and // in that value is 100% valid from an HTTP point of view.
In this case, it’s actually BBQ Firewall that is being too aggressive and blocks a legitimate admin-ajax request based on the presence of a colon in the query string. That’s why you get a 403.
You can fix this by whitelisting Cerber’s AJAX call in BBQ (for example, allowing requests to admin-ajax.php with action=cerber_ajax, or relaxing that rule for logged-in admins in /wp-admin/).
Cerber could URL-encode the referrer_page_url as an extra hardening layer, but the root cause here is the firewall rule, not Cerber. If your firewall blocks valid AJAX requests just because there is https:// in a parameter, it will conflict with a lot of plugins, not only this one.
If you run two firewalls inside WordPress, they will block each other.
Cerber already includes a full firewall, so BBQ is redundant and causing false positives.
Running two firewalls inside WordPress is like putting two guard dogs in the same tiny room
they start biting each other instead of the intruders.
I have to dig this thread out as the issue still occurs and it’s annoying. It is not a solution to disable BBQ as it takes away a lot of malicious traffic on htaccess layer before it even hits Wordpress.
Your request URL is not valid. It is malformed per RFC 3986. Per RFC 3986 Section 2.4, characters that have special meaning in a URI component (like ?, &, =) must be percent-encoded when they appear as data within another component. The referrer_page_url value contains an unescaped ? and & characters that are reserved delimiters in the query string.
BBQ Firewall is justified in blocking this. When it sees raw & delimiters, it parses tab= and filter_ip= as separate top-level parameters — and the resulting query string looks suspicious (it effectively contains a full URL with query parameters injected inline, which is a common pattern in open-redirect and SSRF attacks).
As you already pointed out, the simple solution is to encode the URI component referrer_page_url properly on your end.