CVE-2026-32103: 
JavaScript vulnerability analysis and mitigation

CVE-2026-32103 is an Insecure Direct Object Reference (IDOR) vulnerability in StudioCMS, an Astro-native headless content management system, that enables an authenticated admin to perform a complete account takeover of the highest-privileged (owner) account via a flawed password reset mechanism. The vulnerability affects all StudioCMS versions up to and including 0.4.2 (npm package studiocms), and was disclosed on March 11, 2026. It carries a CVSS v3.1 base score of 7.2 (High) per Feedly/NVD, or 6.8 (Moderate) per the GitHub Advisory (GitHub Advisory, StudioCMS Advisory).

The root cause is a missing role hierarchy check and absent caller identity validation in the POST /studiocms_api/dashboard/create-reset-link endpoint (CWE-639: Authorization Bypass Through User-Controlled Key; CWE-640: Weak Password Recovery Mechanism). The handler in packages/studiocms/frontend/pages/studiocms_api/dashboard/create-reset-link.ts correctly verifies that the caller holds admin privileges, but then accepts an arbitrary userId from the JSON request body without comparing it to the caller's own session identity or checking whether the target user outranks the caller. The generated password reset token (a signed JWT) is returned directly in the HTTP response body, which can then be submitted to POST /studiocms_api/dashboard/reset-password to set an arbitrary new password for the targeted account — including the owner account (StudioCMS Advisory).

Successful exploitation allows any authenticated admin-level user to fully take over the owner account — the highest-privileged account in a StudioCMS instance — by resetting its password without the owner's knowledge or consent. This grants the attacker complete control over all content, user management, and system configuration within the CMS. While the vulnerability requires existing admin credentials (limiting the initial attack surface), the integrity impact is critical since it enables privilege escalation beyond the attacker's assigned role, and there is no confidentiality or availability impact beyond the account takeover itself (StudioCMS Advisory, GitHub Advisory).

A detailed proof-of-concept (PoC) exploit is publicly available in the GitHub security advisory, providing step-by-step HTTP requests that demonstrate the full attack chain from token generation to password reset (StudioCMS Advisory). The EPSS score is approximately 0.019–0.024%, indicating a low current probability of exploitation in the wild, and there is no evidence of active in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not listed in the CISA KEV catalog. Exploitation requires authenticated admin-level access, which limits opportunistic exploitation but makes it a significant insider threat or post-compromise escalation vector.

1. Obtain Admin Credentials: The attacker must already possess valid admin-level credentials for the target StudioCMS instance (e.g., through credential theft, phishing, or a compromised admin account).
2. Authenticate and Verify Session: Send a POST request to /studiocms_api/dashboard/verify-session with the admin session cookie to confirm the attacker's permissionLevel is admin and retrieve the admin's user UUID.
3. Identify the Owner's UUID: Enumerate users via available admin dashboard API endpoints or prior reconnaissance to obtain the owner account's UUID (e.g., 2450bf33-0135-4142-80be-9854f9a5e9f1).
4. Generate a Password Reset Token for the Owner: Send a POST request to /studiocms_api/dashboard/create-reset-link with the admin session cookie and the owner's UUID in the JSON body: {"userId": "<owner-uuid>"}. The server returns a signed JWT reset token, a reset record id, and the target userId in the response body.
5. Reset the Owner's Password: Submit a POST request to /studiocms_api/dashboard/reset-password using the id, userId, and token from the previous response, along with a new attacker-chosen password: {"id": "<id>", "userid": "<owner-uuid>", "token": "<jwt>", "password": "pwned1234@@", "confirm_password": "pwned1234@@"}. The server responds with {"message": "User password updated successfully"}.
6. Log In as Owner: Use the newly set password to authenticate as the owner account, gaining full control of the StudioCMS instance including all content, user management, and system configuration (StudioCMS Advisory).

• Network: Unexpected POST requests to /studiocms_api/dashboard/create-reset-link where the userId in the request body does not match the authenticated caller's own user ID; POST requests to /studiocms_api/dashboard/reset-password shortly after, originating from an admin session.
• Logs: Application logs showing a password reset token generated for the owner account by a non-owner admin user; successful password change events for the owner account not initiated by the owner themselves.
• Authentication Events: Owner account login from an IP address or user-agent not previously associated with the owner; admin account activity generating reset tokens for accounts other than their own.
• API Activity: Unusual sequencing of API calls: verify-session → create-reset-link (targeting owner UUID) → reset-password within a short time window from the same admin session (StudioCMS Advisory).

The vulnerability is fixed in StudioCMS version 0.4.3 (npm package studiocms). All users running version 0.4.2 or earlier should upgrade immediately. The fix enforces role hierarchy checks in the create-reset-link endpoint to prevent admins from generating reset tokens for higher-privileged accounts, and validates that reset token generation requests are scoped appropriately. No configuration-based workaround is available; upgrading to 0.4.3 is the only remediation (GitHub Advisory, StudioCMS Advisory).