User enumeration bug with query params

There’s a bug when enabling to “stop user enumeration” from the Hardening tab.

Endpoints with a query param are getting through.

Example that gets through without 403:
/wp-json/wp/v2/users?hello

This works as expected:
/wp-json/wp/v2/users

Query params should also produce 403 to the endpoint.

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.

1 Like

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.

Yes, I see which category you’ve posted in but since the developer of WP Cerber seems to be busy, I thought providing a workaround might help someone.

I also posted a bug report four days ago but apart from whole five views – three of those might be mine – there’s no response from developer(s).

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:

image

Please try without the trailing slash after “users”, like so: /wp-json/wp/v2/users?hello

With the trailing slash after users/ it returns 403, as expected. Without the trailing, it returns 200 and displays sensitive user data.

Thank you for looking into this!

The same. Possibly, your WordPress is installed in a subfolder?

image

Interesting. I’m not seeing the same as you. And, no – not in a subfolder.

Maybe it’s an Nginx rule that is causing the issue. I will do more testing and report back.

Have you managed to discover something?

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.

So, to recap:

/wp-json/wp/v2/users (403)
/wp-json/wp/v2/users/ (403)
/wp-json/wp/v2/users/?hello=123 (403)
/wp-json/wp/v2/users?hello=123 (200)
/wp-json/wp/v2/users?hello (200)

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.

Thanks again!

What version of WP Cerber are you running your experiments on?

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!

That version was actual when dinosaurs roamed the Earth :grinning:

1 Like

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/.

For anyone interested in understanding the true essence of how plugin authors are treated by the plugin repository team, I recommend checking out this: https://www.peepso.com/peepso-is-leaving-the-wordpress-org-repository/