CVE-2026-30944

The fix changes only the ordering of `availablePermissionRanks`, and the repository uses `availablePermissionRanks.indexOf(...)` to compare authorization levels when creating, updating, and revoking API tokens and user roles. In the bug-introducing commit, this array was first added in descending privilege order (`['owner','admin','editor','visitor','unknown']`), which makes numeric comparisons like `targetPerms >= userPerms` backwards and allows lower-privileged users to satisfy checks intended to block higher-privilege operations. Because the vulnerable rank ordering originated in this commit and was later corrected to ascending order, this commit introduced the vulnerability.

• •Fix commit changes `availablePermissionRanks` from `['owner','admin','editor','visitor','unknown']` to `['unknown','visitor','editor','admin','owner']` in `packages/@withstudiocms/auth-kit/src/types.ts`.
• •At the fixed revision, `packages/studiocms/frontend/pages/studiocms_api/_handlers/dashboard/apiTokens.ts` compares permissions via `const targetPerms = availablePermissionRanks.indexOf(tokenData.rank); const userPerms = availablePermissionRanks.indexOf(userData.permissionLevel); if (targetPerms >= userPerms) ...`, so array order defines authorization semantics.
• •The suspected BIC `341b59e3c775f619e9630c9044772ef0f16d1970` is the commit that introduced `packages/@withstudiocms/auth-kit/src/types.ts` with the incorrect descending order of `availablePermissionRanks`.

The BIC (341b59e3) created the `availablePermissionRanks` array in `packages/@withstudiocms/auth-kit/src/types.ts` with the order `['owner', 'admin', 'editor', 'visitor', 'unknown']`, placing the highest privilege ('owner') at index 0 and the lowest ('unknown') at index 4. Later code used `availablePermissionRanks.indexOf()` for permission comparisons assuming higher index = higher privilege, which inverted the permission hierarchy. This allowed lower-privileged users (e.g., 'unknown' at index 4) to pass permission checks that should have required higher privileges (e.g., 'owner' at index 0), enabling privilege escalation. The fix correctly reverses the array to `['unknown', 'visitor', 'editor', 'admin', 'owner']`. The BIC is the root cause because it introduced the incorrectly-ordered constant that was exported and consumed by permission-checking code.

• •The BIC introduced `availablePermissionRanks = ['owner', 'admin', 'editor', 'visitor', 'unknown']` with owner at index 0 and unknown at index 4
• •The fix reverses the order to `['unknown', 'visitor', 'editor', 'admin', 'owner']` so higher index = higher privilege
• •Permission checks use `availablePermissionRanks.indexOf()` with comparisons like `if (targetPerm >= callerPerm)` and `if (userPerms <= targetCurrentLevel)`, which assume higher index means higher privilege
• •With the old order, an 'unknown' user (index 4) would appear to have higher permissions than an 'owner' (index 0), enabling privilege escalation
• •The array was exported from auth-kit and consumed by multiple API handlers for authorization decisions

Fallback verdict: Agent exhausted max turns without submitting a verdict.