Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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/studiocmsapi/handlers/rest-api/v1/secure.ts, lines 1605-1647 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:…
Recommended action: Upgrade to 0.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details The REST API handler in packages/studiocms/frontend/pages/studiocmsapi/handlers/rest-api/v1/secure.ts:1365-1378: The Dashboard API handler in handlers/dashboard/create.ts uses the correct approach: 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 PoC Impact - 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…
Recommended action: Upgrade to 0.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The updateUserNotifications endpoint accepts a user ID from the request payload and uses it to update that user's notification preferences. It checks that the caller is logged in but never verifies that the caller owns the target account (id !== userData.user.id). Any authenticated visitor can modify notification preferences for any user, including disabling admin notifications to suppress detection of malicious activity. Details The vulnerable handler is in packages/studiocms/frontend/pages/studiocmsapi/handlers/dashboard/users.ts:257-311: For comparison, the updateUserProfile handler in dashboard/profile.ts correctly uses userData.user.id instead of a user-supplied ID, preventing IDOR. PoC Impact - Any authenticated visitor can disable notification preferences for admin/owner accounts, suppressing alerts about new user creation, account changes, and user deletions - Enables attack chaining — suppress admin notifications first, then perform other malicious actions with…
Recommended action: Upgrade to 0.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The POST /studiocmsapi/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 /studiocmsapi/dashboard/reset-password endpoint, this allows a complete account takeover of the highest-privileged account in the system. Details Vulnerable Code File: packages/studiocms/frontend/pages/studiocmsapi/dashboard/create-reset-link.ts Version: studiocms@0.3.0 Analysis Unlike the API token endpoints (which only require isEditor), this handler correctly gates access at the isAdmin level [1]. However, two critical authorization checks are still missing: 1. No caller identity validation [2][3]: The userId from the JSON payload is never compared against the authenticated caller's session identity.…
Recommended action: Upgrade to 0.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The DELETE /studiocmsapi/dashboard/api-tokens endpoint allows any authenticated user with editor privileges or above to revoke API tokens belonging to any other user, including admin and owner accounts. The handler accepts tokenID and userID directly from the request payload without verifying token ownership, caller identity, or role hierarchy. This enables targeted denial of service against critical integrations and automations. Details Vulnerable Code The following is the server-side handler for the DELETE /studiocmsapi/dashboard/api-tokens endpoint (revokeApiToken): File: packages/studiocms/frontend/pages/studiocmsapi/dashboard/api-tokens.ts (lines 58–99) Version: studiocms@0.3.0 Analysis The handler shares the same class of authorization flaws found in the token generation endpoint, applied to a destructive operation: 1. Insufficient permission gate [1][2][3]: The handler retrieves the session from ctx.locals.StudioCMS.security and only checks isEditor. Token revocation…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The /studiocmsapi/dashboard/api-tokens endpoint allows any authenticated user (at least Editor) to generate API tokens for any other user, including owner and admin accounts. The endpoint fails to validate whether the requesting user is authorized to create tokens on behalf of the target user ID, resulting in a full privilege escalation. Details The API token generation endpoint accepts a user parameter in the request body that specifies which user the token should be created for. The server-side logic authenticates the session (via authsession cookie) but does not verify that the authenticated user matches the target user ID nor checks if the caller has sufficient privileges to perform this action on behalf of another user. This is a classic BOLA vulnerability: the authorization check is limited to "is the user logged in?" instead of "is this user authorized to perform this action on this specific resource?" Vulnerable Code The following is the server-side handler for the…
Recommended action: Upgrade to 0.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
StudioCMS contains a Broken Object Level Authorization (BOLA) vulnerability in the Content Management feature that allows users with the "Visitor" role to access draft content created by Editor/Admin/Owner users. Details The Issue: The endpoint /dashboard/content-management/edit?edit={UUID} validates user authentication but does NOT validate: 1. User role (should require Editor/Admin/Owner) 2. Content ownership (should verify the draft belongs to the user) This allows users with "Visitor" role (lowest privilege) to access draft content created by Editor/Admin/Owner users by directly accessing the edit URL with the content UUID. PoC - User A: Editor role (example username: dummy04) - User B: Visitor role (example username: dummy01) Reproduction Steps: Step 1 - Create draft as Editor: 1. Login as User A (Editor role) 2. Navigate to: http://localhost:4321/dashboard/content-management 3. Create new content (it will stay as draft) 4. After saving, note the UUID in the URL: Copy…
Recommended action: Upgrade to 0.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.