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.
Thanks for following up and for taking the time to dig into this.
That AJAX call is made via jQuery, and the parameters are passed as an object. In this case, jQuery handles building the query string and encoding the values. So this isn’t a situation where a raw URL is manually stitched together and sent as-is. We’ve checked this part of the code path on our side and confirmed that encoding is applied as expected.
At the same time, your observation about the firewall behavior makes sense. Even when the value is encoded, a pattern like:
https%3A%2F%2F...
inside a query string can still trigger some firewall rules. Certain WAFs treat a URL inside a parameter as a potential SSRF or injection pattern, even in encoded form. That can lead to a 403 depending on how strict the rules are.
So what you’re seeing with BBQ is understandable from a security perspective, but it doesn’t mean the request itself is malformed.
How to double-check what’s actually sent
If you want to be absolutely sure what your server receives, the easiest way is to look at the raw request before BBQ gets a chance to process it. The most reliable place for that is your web server access logs, since they show the request exactly as it arrived.
You can also take a look in your browser’s DevTools, in the Network tab. You’ll see the request as it was sent over the wire, including the encoded parameter values. That should give you a clear picture of whether the referrer_page_url is already encoded at that point.
My recommendation
What’s happening here is that BBQ reacts to how the request looks, not because it is actually broken. That’s why allowing this specific AJAX call in BBQ typically resolves the issue.
Thanks for your quick reply. You are right, the request is encoded correctly. I was mislead by the Dev Tools which were displaying the URL decoded. But when checking the raw data, it looks good. Sorry for my unjustified claim regarding malformed request then.
I did some further checks and found that BBQ Firewall is blocking the request because of the &request= parameter. The corresponding regex pattern in the blocklist is: (globals|request)(=|[)
Seems this is aimed at GLOBALS and $_REQUEST global variables, but lacks the underscore?
Anyway, the issue is solved by disabling this security rule in BBQ Firewall, using Jeff Starrs BBQ Whitelist plugin, adding the following statement:
But this is only a temporary solution for me. Both plugins should be able to work together out of the box. Either the rule in BBQ is too strict and should be adapted, or there is a valid reason for this rule and Cerber should use another parameter name.
I’ll address this in the BBQ support forum. Interested in Jeffs viewpoint about this.