CVE-2026-32638

Description

## Summary The REST API `getUsers` endpoint in StudioCMS uses the attacker-controlled `rank` query parameter to decide whether owner accounts should be filtered from the result set. As a result, an admin token can request `rank=owner` and receive owner account records, including IDs, usernames, display names, and email addresses, even though the adjacent `getUser` endpoint correctly blocks admins from viewing owner users. This is an authorization inconsistency inside the same user-management surface. ## Details ### Vulnerable Code Path File: `D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`, lines 1605-1647 ```ts .handle( 'getUsers', Effect.fn( function* ({ urlParams: { name, rank, username } }) { if (!restAPIEnabled) { return yield* new RestAPIError({ error: 'Endpoint not found' }); } const [sdk, user] = yield* Effect.all([SDKCore, CurrentRestAPIUser]); if (user.rank !== 'owner' && user.rank !== 'admin') { return yield* new RestAPIError({ error: 'Unauthorized' }); } const allUsers = yield* sdk.GET.users.all(); let data = allUsers.map(...); if (rank !== 'owner') { data = data.filter((user) => user.rank !== 'owner'); } if (rank) { data = data.filter((user) => user.rank === rank); } return data; }, ``` The `rank` variable in `if (rank !== 'owner')` is the request query parameter, not the caller's privilege level. An admin can therefore pass `rank=owner`, skip the owner-filtering branch, and then have the second `if (rank)` branch return only owner accounts. ### Adjacent Endpoint Shows Intended Security Boundary File: `D:/bugcrowd/studiocms/repo/packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`, lines 1650-1710 ```ts const existingUserRankIndex = availablePermissionRanks.indexOf(existingUserRank); const loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank); if (loggedInUserRankIndex <= existingUserRankIndex) { return yield* new RestAPIError({ error: 'Unauthorized to view user with higher rank', }); } ``` `getUser` correctly blocks an admin from viewing an owner record. `getUsers` bypasses that boundary for bulk enumeration. ### Sensitive Fields Returned The `getUsers` response includes: - `id` - `email` - `name` - `username` - `rank` - timestamps and profile URL/avatar fields when present This is enough to enumerate all owner accounts and target them for phishing, social engineering, or follow-on attacks against out-of-band workflows. ## PoC ### HTTP PoC Use any admin-level REST API token: ```bash curl -X GET 'http://localhost:4321/studiocms_api/rest/v1/secure/users?rank=owner' \ -H 'Authorization: Bearer <admin-api-token>' ``` Expected behavior: - owner records should be excluded for admin callers, consistent with `getUser` Actual behavior: - the response contains owner user objects, including email addresses and user IDs ### Local Validation of the Exact Handler Logic I validated the filtering logic locally with the same conditions used by `getUsers` and `getUser`. Observed output: ```json { "admin_getUsers_rank_owner": [ { "email": "[email protected]", "id": "owner-1", "name": "Site Owner", "rank": "owner", "username": "owner1" } ], "admin_getUser_owner": "Unauthorized to view user with higher rank" } ``` This demonstrates the authorization mismatch clearly: - bulk listing with `rank=owner` exposes owner records - direct access to a single owner record is denied ## Impact - **Owner Account Enumeration:** Admin tokens can recover owner user IDs, usernames, display names, and email addresses. - **Authorization Boundary Bypass:** The REST collection endpoint bypasses the stricter per-record rank check already implemented by `getUser`. - **Chaining Value:** Exposed owner contact data can support phishing, account-targeting, and admin-to-owner pivot attempts in deployments that treat owner identities as higher-trust principals. ## Recommended Fix Apply rank filtering based on the caller's role, not on the request query parameter, and reuse the same privilege rule as `getUser`. Example fix: ```ts const loggedInUserRankIndex = availablePermissionRanks.indexOf(user.rank); data = data.filter((candidate) => { const candidateRankIndex = availablePermissionRanks.indexOf(candidate.rank); return loggedInUserRankIndex > candidateRankIndex; }); if (rank) { data = data.filter((candidate) => candidate.rank === rank); } ``` At minimum, replace: ```ts if (rank !== 'owner') { data = data.filter((user) => user.rank !== 'owner'); } ``` with a check tied to `user.rank` rather than the query parameter.

Priority Score