StudioCMS is a server-side-rendered, Astro native, headless content management system. Prior to 0.4.4, 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. Version 0.4.4 fixes the issue.

Affected: npm: studiocms

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