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

CWE-639 Authorization Bypass Through User-Controlled Key