If you’re on Apache and can edit .htaccess file, I’d suggest adding rewrite rules to block user enumeration requests outright.
<IfModule mod_rewrite.c>
RewriteEngine On
# Prevent user enumeration attempts and don't even invoke PHP code
RewriteCond %{QUERY_STRING} (^|&)author=.+ [NC]
RewriteRule ^(.*) - [R=404,L,END,E=error_notes:wp-user-enumeration]
# Prevent user enumeration via REST API
RewriteCond %{REQUEST_URI} ^/?wp-json/wp/v2/users
# ... but only if user is not logged in (somewhat simplistic approach using the WP cookie)
RewriteCond %{HTTP_COOKIE} !(wordpress_logged_in_.+)
RewriteRule ^(.*)$ - [F,L,END,E=error_notes:wp-user-enumeration]
</IfModule>
This approach saves on resources because the requests are served by Apache without invoking PHP and WordPress code. Additionally, I’m using the custom environment variable error_notes in Apache log files to block repeated requests using fail2ban in server’s firewall and on Cloudflare firewall.
We can definitely block via Nginx as well. However, the goal of my post is to focus on reporting what appears to be a bug with WP Cerber, not workarounds.
I’m unable to reproduce the issue. What versions of WP Cerber and WordPress are you using? Check the Traffic Inspector log; here’s what you should see:
Thanks for following up – but, unfortunately no. Nothing odd in Nginx configs.
It appears that not having the trailing slash will return 200, BUT only if query params are present. The trailing slash issue goes away when the query params are removed.
Can you maybe point me to which file is parsing this feature in WP Cerber or the mechanism to do the checking? I would be more then happy to continue troubleshooting and evaluating.
Well, that did it! I was on 9.0 – not knowing WP Cerber didn’t receive update notifications in the Plugin area. Updated to 9.6.3 and all tests pass with 403 as expected. Thank you!
I wonder, could this be related to the issue that led to WP Cerber being removed from the wordpress.org plugin repository? Just trying to connect the dots here.
Yes, this issue was cited as the official reason. It was classified as a vulnerability by an anonymous moderator from the WordPress plugin team. Naturally, once something is labeled a “vulnerability,” they gain formal grounds to block a plugin.
At the same time, no one seems concerned that WordPress exposes users’ details via REST API by default immediately after installation. Yet, this suddenly becomes a “vulnerability” when WP Cerber is installed, and the feature meant to block REST API access doesn’t work as intended. Out of nowhere, the open REST API is now considered an “attack surface,” even though it wasn’t viewed as such before and posed no actual risk to website owners.
To be fair, plugin developers are typically given 30 days to fix reported vulnerabilities. The updated version of WP Cerber, addressing the issue, was released on the 32nd day. However, instead of taking a constructive approach, this delay was used as a convenient excuse to block WP Cerber’s return to the repository under the claim that its code doesn’t comply with official guidelines. Here is the information about that release: https://wpcerber.com/wp-cerber-security-9-1/.