CVE-2026-30944: 
JavaScript vulnerability analysis and mitigation

CVE-2026-30944 is a privilege escalation vulnerability in StudioCMS, an Astro-native headless content management system, caused by insecure API token generation in the /studiocms_api/dashboard/api-tokens endpoint. Any authenticated user with at least Editor-level access can generate API tokens on behalf of any other user — including owner and admin accounts — due to missing object-level authorization checks. All versions up to and including 0.3.0 are affected; the vulnerability was disclosed and patched on March 10, 2026. It carries a CVSS v3.1 base score of 8.8 (High) (Github Advisory, StudioCMS Advisory).

The root cause is a Broken Object Level Authorization (BOLA) flaw classified under CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-863 (Incorrect Authorization). The vulnerable server-side handler for POST /studiocms_api/dashboard/api-tokens authenticates the session and verifies the caller has isEditor permission, but then accepts a user field from the JSON request body and passes it directly to sdk.REST_API.tokens.new(jsonData.user, jsonData.description) without verifying that the caller's session identity matches the target user ID or that the caller has sufficient privileges to generate tokens for higher-privileged accounts. This allows any Editor (or above) to specify an arbitrary target UUID — including owner or admin UUIDs — and receive a valid JWT token bound to that account. The fix in version 0.4.0 removes the user field from the request payload entirely and instead derives the target user ID from the authenticated session (userData.user.id) (StudioCMS Advisory, Patch Commit).

Successful exploitation allows a low-privileged authenticated user (Editor level or above) to fully escalate privileges to owner or admin level by obtaining a valid API token for any account in the system. The generated token grants unrestricted access to all REST API endpoints with the impersonated user's permissions, enabling account takeover, enumeration of all users, unauthorized content modification, and access to potentially sensitive configuration data. The attack requires only network access and a valid Editor-level account, with no user interaction needed, making it highly accessible to insider threats or attackers who have compromised any non-visitor account (StudioCMS Advisory, Github Advisory).

A public proof-of-concept Python exploit script (cve_2026_30944_poc.py) is available on GitHub, demonstrating end-to-end privilege escalation with both manual and automated exploitation modes; the README confirms successful exploitation with full API access achieved (PoC Repository). The official security advisory itself contains step-by-step exploitation instructions with concrete HTTP requests and curl commands (StudioCMS Advisory). The EPSS score is approximately 0.037–0.058%, indicating a low but non-negligible probability of exploitation in the wild within 30 days. There is no current evidence of active in-the-wild exploitation, no known threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog (Github Advisory).

1. Reconnaissance: Identify a StudioCMS instance running version 0.3.0 or earlier. Enumerate user UUIDs by accessing publicly available endpoints or through any authenticated session (e.g., the /studiocms_api/rest/v1/users endpoint if accessible).
2. Obtain Editor-level credentials: Log in with any account that has at least Editor privileges. Retrieve the auth_session cookie from the authenticated browser session.
3. Identify target user UUID: Determine the UUID of a high-privileged account (owner or admin) to impersonate. This may be obtained from user listing endpoints or application responses.
4. Send malicious token generation request: As the Editor, send a crafted POST request to /studiocms_api/dashboard/api-tokens with the target owner's UUID in the user field:

POST /studiocms_api/dashboard/api-tokens HTTP/1.1
Host: <target>
Cookie: auth_session=<editor_session_token>
Content-Type: application/json

{"user": "2450bf33-0135-4142-80be-9854f9a5e9f1", "description": "pwn"}

5. Receive owner-level JWT: The server returns a valid JWT token bound to the owner account without validating the caller's authorization to act on behalf of that user.
6. Access API as owner: Use the obtained token to call any REST API endpoint with full owner privileges:

curl -H "Authorization: Bearer <token>" http://<target>/studiocms_api/rest/v1/users

7. Achieve objectives: With owner-level access, enumerate all users, modify content, alter configuration, or perform further account takeover actions (StudioCMS Advisory, PoC Repository).

• Network: Unexpected POST requests to /studiocms_api/dashboard/api-tokens from Editor-level accounts, especially with user field UUIDs that do not match the authenticated session's own user ID; API calls to /studiocms_api/rest/v1/users or other privileged endpoints using tokens not associated with the expected account.
• Logs: Application access logs showing token generation requests where the user parameter in the request body differs from the session owner's UUID; multiple token generation events from a single low-privileged account in a short time window; API access logs showing owner/admin-level operations performed by accounts that should not have those privileges.
• File System / Application State: Unexpected API tokens appearing in the database associated with owner or admin accounts but created at unusual times or from unexpected IP addresses; tokens with descriptions such as pwn, test, or other anomalous strings.
• Behavioral: Sudden access to user management, content modification, or configuration endpoints by accounts that previously only performed editor-level actions; API token revocation or creation activity inconsistent with normal user behavior (StudioCMS Advisory).

Upgrade StudioCMS to version 0.4.0 or later immediately, as this release removes the attacker-controlled user field from the token generation payload and enforces that tokens are always created for the authenticated session's own user ID (StudioCMS Release, Patch Commit). No configuration-based workaround is available for versions prior to 0.4.0 other than restricting access to the /studiocms_api/dashboard/api-tokens endpoint at the network or reverse proxy level. After patching, audit all existing API tokens in the database for suspicious entries — particularly tokens associated with owner or admin accounts created at unexpected times — and revoke any that cannot be verified as legitimate (Github Advisory).

The vulnerability was reported by security researcher FilipeGaudard, who also published the public PoC exploit, and was remediated by StudioCMS maintainer Adammatthiesen (StudioCMS Advisory). Coverage appeared on The Hacker Wire shortly after disclosure, and the CVE was noted across vulnerability tracking platforms including VulnDB and Bluesky CVE feeds (Feedly).