Studiocms
Monthly
The REST API `createUser` endpoint uses string-based rank checks that only block creating `owner` accounts, while the Dashboard API uses `indexOf`-based rank comparison that prevents creating users at or above your own rank. This inconsistency allows an admin to create additional admin accounts via the REST API, enabling privilege proliferation and persistence. The REST API handler in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts:1365-1378`: ```typescript // REST API - only blocks creating 'owner' if (newUserRank === 'owner' && rank !== 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } if (rank === 'admin' && newUserRank === 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } // Missing: no check preventing admin from creating admin // newUserRank='admin' passes all checks ``` The Dashboard API handler in `_handlers/dashboard/create.ts` uses the correct approach: ```typescript // Dashboard API - blocks creating users at or above own rank const callerPerm = availablePermissionRanks.indexOf(userData.permissionLevel); const targetPerm = availablePermissionRanks.indexOf(rank); if (targetPerm >= callerPerm) { return yield* new DashboardAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ``` With `availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']`: - Admin (index 3) creating admin (index 3): `3 >= 3` = blocked in Dashboard - In REST API: no such check - allowed ```bash curl -X POST 'http://localhost:4321/studiocms_api/rest/v1/secure/users' \ -H 'Authorization: Bearer <admin-api-token>' \ -H 'Content-Type: application/json' \ -d '{ "username": "rogue_admin", "email": "[email protected]", "displayname": "Rogue Admin", "rank": "admin", "password": "StrongP@ssw0rd123" }' ``` - A compromised or rogue admin can create additional admin accounts as persistence mechanisms that survive password resets or token revocations - Inconsistent security model between Dashboard API and REST API creates confusion about intended authorization boundaries - Note: requires admin access (PR:H), which limits practical severity Replace string-based checks with `indexOf` comparison in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`: ```typescript // Before: if (newUserRank === 'owner' && rank !== 'owner') { ... } if (rank === 'admin' && newUserRank === 'owner') { ... } // After: const availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']; const callerPerm = availablePermissionRanks.indexOf(rank); const targetPerm = availablePermissionRanks.indexOf(newUserRank); if (targetPerm >= callerPerm) { return yield* new RestAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ```
A security vulnerability in StudioCMS (CVSS 5.4). Remediation should follow standard vulnerability management procedures.
Medium severity vulnerability in StudioCMS. The POST /studiocms_api/dashboard/create-reset-link endpoint allows any authenticated user with admin privileges to generate a password reset token for any other user, including the owner account. The handler verifies that the caller is an admin but does not enforce role hierarchy, nor does it validate that the target userId matches the caller's identity. Combined with the POST /studiocms_api/d...
High severity vulnerability in StudioCMS. The S3 storage manager's `isAuthorized()` function is declared `async` (returns `Promise<boolean>`) but is called without `await` in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, `!isAuthorized(type)` always evaluates to `false`, completely bypassing the authorization check. Any authenticated user with the lowest `visitor` role can upload, delete, rename...
StudioCMS prior to version 0.4.0 allows authenticated editors and above to revoke API tokens belonging to any user, including administrators and owners, due to insufficient authorization checks on the DELETE /studiocms_api/dashboard/api-tokens endpoint. An attacker with editor privileges can exploit this to disable critical integrations and automations by revoking tokens of higher-privileged accounts. No patch is currently available for affected versions.
Privilege escalation in StudioCMS versions prior to 0.4.0 enables authenticated Editor-level users to generate API tokens for arbitrary accounts, including administrative and owner roles, due to missing authorization validation on the /studiocms_api/dashboard/api-tokens endpoint. An attacker with basic editor privileges can exploit this to gain full administrative access without requiring the target account's credentials. No patch is currently available for affected installations.
headless content management system. versions up to 0.2.0 is affected by authorization bypass through user-controlled key (CVSS 6.5).
The REST API `createUser` endpoint uses string-based rank checks that only block creating `owner` accounts, while the Dashboard API uses `indexOf`-based rank comparison that prevents creating users at or above your own rank. This inconsistency allows an admin to create additional admin accounts via the REST API, enabling privilege proliferation and persistence. The REST API handler in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts:1365-1378`: ```typescript // REST API - only blocks creating 'owner' if (newUserRank === 'owner' && rank !== 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } if (rank === 'admin' && newUserRank === 'owner') { return yield* new RestAPIError({ error: 'Unauthorized to create user with owner rank', }); } // Missing: no check preventing admin from creating admin // newUserRank='admin' passes all checks ``` The Dashboard API handler in `_handlers/dashboard/create.ts` uses the correct approach: ```typescript // Dashboard API - blocks creating users at or above own rank const callerPerm = availablePermissionRanks.indexOf(userData.permissionLevel); const targetPerm = availablePermissionRanks.indexOf(rank); if (targetPerm >= callerPerm) { return yield* new DashboardAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ``` With `availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']`: - Admin (index 3) creating admin (index 3): `3 >= 3` = blocked in Dashboard - In REST API: no such check - allowed ```bash curl -X POST 'http://localhost:4321/studiocms_api/rest/v1/secure/users' \ -H 'Authorization: Bearer <admin-api-token>' \ -H 'Content-Type: application/json' \ -d '{ "username": "rogue_admin", "email": "[email protected]", "displayname": "Rogue Admin", "rank": "admin", "password": "StrongP@ssw0rd123" }' ``` - A compromised or rogue admin can create additional admin accounts as persistence mechanisms that survive password resets or token revocations - Inconsistent security model between Dashboard API and REST API creates confusion about intended authorization boundaries - Note: requires admin access (PR:H), which limits practical severity Replace string-based checks with `indexOf` comparison in `packages/studiocms/frontend/pages/studiocms_api/_handlers/rest-api/v1/secure.ts`: ```typescript // Before: if (newUserRank === 'owner' && rank !== 'owner') { ... } if (rank === 'admin' && newUserRank === 'owner') { ... } // After: const availablePermissionRanks = ['unknown', 'visitor', 'editor', 'admin', 'owner']; const callerPerm = availablePermissionRanks.indexOf(rank); const targetPerm = availablePermissionRanks.indexOf(newUserRank); if (targetPerm >= callerPerm) { return yield* new RestAPIError({ error: 'Unauthorized: insufficient permissions to assign target rank', }); } ```
A security vulnerability in StudioCMS (CVSS 5.4). Remediation should follow standard vulnerability management procedures.
Medium severity vulnerability in StudioCMS. The POST /studiocms_api/dashboard/create-reset-link endpoint allows any authenticated user with admin privileges to generate a password reset token for any other user, including the owner account. The handler verifies that the caller is an admin but does not enforce role hierarchy, nor does it validate that the target userId matches the caller's identity. Combined with the POST /studiocms_api/d...
High severity vulnerability in StudioCMS. The S3 storage manager's `isAuthorized()` function is declared `async` (returns `Promise<boolean>`) but is called without `await` in both the POST and PUT handlers. Since a Promise object is always truthy in JavaScript, `!isAuthorized(type)` always evaluates to `false`, completely bypassing the authorization check. Any authenticated user with the lowest `visitor` role can upload, delete, rename...
StudioCMS prior to version 0.4.0 allows authenticated editors and above to revoke API tokens belonging to any user, including administrators and owners, due to insufficient authorization checks on the DELETE /studiocms_api/dashboard/api-tokens endpoint. An attacker with editor privileges can exploit this to disable critical integrations and automations by revoking tokens of higher-privileged accounts. No patch is currently available for affected versions.
Privilege escalation in StudioCMS versions prior to 0.4.0 enables authenticated Editor-level users to generate API tokens for arbitrary accounts, including administrative and owner roles, due to missing authorization validation on the /studiocms_api/dashboard/api-tokens endpoint. An attacker with basic editor privileges can exploit this to gain full administrative access without requiring the target account's credentials. No patch is currently available for affected installations.
headless content management system. versions up to 0.2.0 is affected by authorization bypass through user-controlled key (CVSS 6.5).