# REST API user enumeration - bedrock roots **URL:** \ **Category:** General Support\ **Tags:** rest-api\ **Created:** [September 7, 2026, 2:33pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691 "2026-09-07T14:33:28Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![beapi](https://talk.wpcerber.com/letter_avatar_proxy/v4/letter/b/74df32/32.png) [@beapi](https://talk.wpcerber.com/u/beapi)\ **Post date:** [September 7, 2026, 2:33pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/1 "2026-09-07T14:33:28Z")
Hello WP Cerber Support Team, We are contacting you regarding a vulnerability identified during a recent penetration test on our environment. Our application runs on a **Roots Bedrock** architecture (where WordPress core files reside in the `/wp/` subdirectory). We have already enabled and configured the **“Stop User Enumeration”** setting in the WP Cerber back-office. While WP Cerber successfully blocks direct REST requests to the standard route (`/wp-json/wp/v2/users`), the endpoint remains accessible when requested via the query parameter rewrite format through the core path: `/wp/wp-json/?rest_route=/wp/v2/users`. We need assistance in ensuring that WP Cerber consistently blocks or restricts user enumeration across all route formats, including Bedrock subfolder query rewrites. ### **Technical Summary & Observed Behavior** - **Configured Setting:** “Stop user enumeration” is **ENABLED** in WP Cerber settings. - **Blocked Path:** `GET /wp-json/wp/v2/users` → **Blocked (403/Forbidden) as expected.** - **Bypassed Path:** `GET /wp/wp-json/?rest_route=/wp/v2/users` → **Not blocked (Returns user array).** ### **Questions & Assistance Requested** 1. Is WP Cerber’s “Stop User Enumeration” module expected to handle `?rest_route=` query parameter lookups when WordPress is installed in a subdirectory like Roots Bedrock? 2. Is there a specific configuration in WP Cerber or an action hook/filter we can use to enforce REST API rules on `?rest_route=` query requests? 3. What is the recommended way to prevent this query parameter rewrite bypass without breaking core WordPress REST functionality? Thank you for your support. Best regards, ---
**Author:** ![Garry](https://talk.wpcerber.com/user_avatar/talk.wpcerber.com/garry/32/14_2.png) [@Garry](https://talk.wpcerber.com/u/Garry)\ **Post date:** [September 15, 2026, 12:50pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/3 "2026-09-15T12:50:12Z")
Hi! What version of WP Cerber are you experiencing this issue with? ---
**Author:** ![beapi](https://talk.wpcerber.com/letter_avatar_proxy/v4/letter/b/74df32/32.png) [@beapi](https://talk.wpcerber.com/u/beapi)\ **Post date:** [September 16, 2026, 7:52am UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/4 "2026-09-16T07:52:42Z")
Hi 🙂 We are currently using version 9.6.2 Thanks ! ---
**Author:** ![Garry](https://talk.wpcerber.com/user_avatar/talk.wpcerber.com/garry/32/14_2.png) [@Garry](https://talk.wpcerber.com/u/Garry)\ **Post date:** [September 17, 2026, 2:05pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/6 "2026-09-17T14:05:04Z")
This version is outdated and not supported, please update your WP Cerber to the latest one: [https://wpcerber.com/automatic-updates-for-wp-cerber/](https://wpcerber.com/automatic-updates-for-wp-cerber/) ---
**Author:** ![beapi](https://talk.wpcerber.com/letter_avatar_proxy/v4/letter/b/74df32/32.png) [@beapi](https://talk.wpcerber.com/u/beapi)\ **Post date:** [September 30, 2026, 1:13pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/7 "2026-09-30T13:13:20Z")
I just updated the plugin to the latest version, but I’m still having the same problem. ---
**Author:** ![Garry](https://talk.wpcerber.com/user_avatar/talk.wpcerber.com/garry/32/14_2.png) [@Garry](https://talk.wpcerber.com/u/Garry)\ **Post date:** [October 2, 2026, 12:07am UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/9 "2026-10-02T00:07:24Z")
Please make sure that “Block access to users’ data via REST API” is enabled in the “Access to WordPress REST API” section. ---
**Author:** ![beapi](https://talk.wpcerber.com/letter_avatar_proxy/v4/letter/b/74df32/32.png) [@beapi](https://talk.wpcerber.com/u/beapi)\ **Post date:** [October 2, 2026, 8:11am UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/10 "2026-10-02T08:11:04Z")
![Capture d’écran 2026-10-02 à 10.10.55](https://talk.wpcerber.com/uploads/default/original/1X/61e34f72fb47c7dfb104468a17569ee14af7cc37.png) ---
**Author:** ![Garry](https://talk.wpcerber.com/user_avatar/talk.wpcerber.com/garry/32/14_2.png) [@Garry](https://talk.wpcerber.com/u/Garry)\ **Post date:** [October 4, 2026, 10:32pm UTC](https://talk.wpcerber.com/t/rest-api-user-enumeration-bedrock-roots/691/12 "2026-10-04T22:32:59Z")
Thank you for confirming the settings. With “Block access to users’ data via REST API” enabled, WP Cerber handles both URL formats the same way for the same visitor. We tested the same layout (WordPress core in `/wp/`, as in Bedrock, behind nginx) with the current version of WP Cerber, and both requests return 403 for an anonymous visitor: ```auto GET /wp-json/wp/v2/users -> 403 GET /wp/wp-json/?rest_route=/wp/v2/users -> 403 ``` This means the two requests in the penetration test were made under different conditions. The usual reasons are: 1. **The request came from an IP address in the Allowed IP Access List.** These addresses are exempt from WP Cerber’s access restrictions, including this one. Note that WP Cerber automatically adds the IP address of the administrator who activates the plugin, with the comment “My IP address” followed by a date. 2. **The request was sent from a browser logged in as an administrator** , or as a user with a role selected in “Allow access to users’ data via REST API for these roles”. These users are allowed through, and WordPress then returns the public user list, which looks exactly like what an anonymous visitor would get. 3. **The response came from a cache or from another environment** , for example a staging site with different settings. To find out which one applies, could you please run this test: 1. In **WP Cerber \> Traffic Inspector \> Settings** , set **Logging mode** to **All traffic** for the duration of the test. 2. From a computer whose IP address is **not** listed in **WP Cerber \> Access Lists** (a mobile hotspot works well), run these two commands, replacing [example.com](http://example.com) with your domain. They send no cookies, and the `nocache` parameter avoids cached responses: ```auto curl -i "https://example.com/wp-json/wp/v2/users?nocache=1" curl -i "https://example.com/wp/wp-json/?rest_route=/wp/v2/users&nocache=1" ``` 1. Let us know what each command returned: the WP Cerber page “We’re sorry, you are not allowed to proceed” (status 403), or a list of users (status 200). Please don’t post the user list itself. Afterwards, you can set the logging mode back to its previous value. If both requests return 403, the setting works as intended and we need to look at the conditions of the penetration test instead. In that case, please send us the raw HTTP request for the bypassed URL from the pentest report (keep the cookie names but remove their values), and the IP address the pentest was run from, and check whether that address is in the Allowed IP Access List.