CVE-2026-32104: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32104 is an Insecure Direct Object Reference (IDOR) vulnerability in StudioCMS, a server-side-rendered, Astro-native headless CMS, that allows any authenticated user to modify notification preferences for any other user account. The flaw exists in versions up to and including 0.4.2 of the studiocms npm package, and was disclosed on March 11, 2026 by reporter Adammatthiesen. It carries a CVSS v3.1 base score of 5.4 (Medium) (GitHub Advisory, StudioCMS Advisory).

The root cause is an authorization bypass through a user-controlled key (CWE-639) in the updateUserNotifications endpoint (packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/users.ts, lines 257–311). The handler verifies that the caller is authenticated (visitor-level or above) but uses the id field from the attacker-controlled request payload — rather than the session-derived userData.user.id — to identify and update the target account. By contrast, the updateUserProfile handler in dashboard/profile.ts correctly binds the operation to the authenticated user's own ID, demonstrating the fix pattern. An attacker needs only a valid session cookie (any visitor-level account) and knowledge of a target user's ID to exploit this remotely over the network with low complexity (StudioCMS Advisory).

Any authenticated user — including those with the lowest visitor-level role — can silently disable or alter notification preferences for any account, including administrator and owner accounts. The most significant risk is attack chaining: an attacker can first suppress admin notifications (e.g., alerts for new user creation, account changes, or deletions) to reduce detection risk before conducting further malicious actions. There is no direct confidentiality impact, but integrity and availability of notification-dependent security monitoring are degraded (StudioCMS Advisory, GitHub Advisory).

A proof-of-concept exploit consisting of concrete curl commands is publicly available in the GitHub Security Advisory, demonstrating how to disable admin notifications using only a visitor-level session cookie (StudioCMS Advisory). There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.036%, indicating a low near-term exploitation probability (GitHub Advisory).

1. Reconnaissance: Identify a StudioCMS instance running version 0.4.2 or earlier. Enumerate user IDs for target accounts (e.g., admin) through any available API or UI that exposes user identifiers.
2. Obtain a session: Register or log in as any visitor-level user on the target StudioCMS instance to obtain a valid studiocms-session cookie.
3. Craft the malicious request: Prepare a POST request to /studiocms_api/dashboard/update-user-notifications with the target admin's user ID and desired notification settings in the JSON payload.
4. Send the request: Execute the request using a tool such as curl:

curl -X POST 'http://<target>/studiocms_api/dashboard/update-user-notifications' \
  -H 'Cookie: studiocms-session=<attacker_session_token>' \
  -H 'Content-Type: application/json' \
  -d '{"id": "<admin_user_id>", "notifications": ""}'

5. Confirm success: A 200 OK response with {"message":"User notifications updated successfully"} confirms the admin's notifications have been disabled, reducing detection risk for subsequent malicious activity (StudioCMS Advisory).

• Network: Unexpected POST requests to /studiocms_api/dashboard/update-user-notifications originating from low-privileged user sessions, especially targeting user IDs other than the authenticated user's own ID.
• Logs: Application logs showing 200 OK responses to update-user-notifications API calls where the id in the payload does not match the session owner's user ID; repeated calls from the same session targeting multiple user IDs.
• Application Behavior: Admin accounts unexpectedly ceasing to receive notifications for user creation, account changes, or deletions without any self-initiated configuration change (StudioCMS Advisory).

Upgrade StudioCMS to version 0.4.3 or later, which adds an ownership check to the updateUserNotifications endpoint ensuring users can only modify their own notification preferences (or admins can modify any). The recommended code fix is to add the following check after the login verification in users.ts:

if (id !== userData.user?.id && !userData.userPermissionLevel.isAdmin) {
  return yield* new DashboardAPIError({ error: 'Unauthorized: cannot modify another user\'s notification preferences' });
}

No configuration-based workaround is available; upgrading to 0.4.3 is the only remediation (StudioCMS Advisory, GitHub Advisory).