GHSA-h37g-4h4p-9x97: PraisonAI Platform: Missing role checks let any workspace member become owner and control workspace membership
SummaryPraisonAI Platform has a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to `owner`.The issue is caused by privileged workspace-management routes using the shared dependency `require_workspace_member(...)` without requiring `admin` or `owner`. The dependency defaults to `min_role="member"`, so routes that should be administrative are accessible to ordinary workspace members.As a result, a normal workspace member can:promote their own account from `member` to `owner`;add arbitrary users as `owner` or `admin`;change other members' roles;remove legitimate owners or members;take over workspace membership completely;perform destructive workspace operations after escalation.This is a broken access control / vertical privilege escalation vulnerability.DetailsThe vulnerable authorization dependency is defined in:The dependency defaults to the lowest workspace role:Because `min_role` defaults to `"member"`, any route using:without explicitly passing a stronger role only requires ordinary workspace membership.Privileged workspace-management routes in:use this dependency unchanged on administrative actions, including:These routes allow workspace modification, deletion, member addition, role changes, and member removal. They should require `admin` or `owner`, but they currently require only `member`.The membership service does not provide a second authorization layer. In:the mutation methods perform the requested change after the route-level check passes:Therefore, the weak route dependency is the effective authorization boundary.A low-privilege user can also learn their own `user.id` from the normal authentication response. The login/register response includes the authenticated user object:This allows an invited low-privilege member to target their own membership record and self-promote.Affected componentPoCThe following PoC is self-contained and exercises the real PraisonAI Platform FastAPI application path. It does not mock the vulnerable RBAC logic.The PoC:Creates the real FastAPI app with `praisonai_platform.api.app.create_app()`.Registers three users through the real `/api/v1/auth/register` route.Creates a workspace as the original owner.Adds the second user as a normal `member`.Logs in as that low-privilege member.Uses the low-privilege member token to self-promote to `owner`.Uses the same token to add a third account as `owner`.Uses the same token to remove the original owner.Confirms the workspace membership has been taken over.Full PoC codeObserved outputExpected secure behaviorThe following request should be rejected when made by a plain `member`:Expected response:Actual vulnerable behaviorThe request succeeds:The same account can then add attacker-controlled owners and remove the original owner.ImpactA low-privilege workspace member can fully take over a workspace.Impact includes:self-promoting from `member` to `owner` or `admin`;granting `owner` or `admin` to attacker-controlled accounts;changing other members' roles;removing legitimate owners or members;modifying workspace metadata and settings;deleting the workspace;taking over workspace-scoped issues, projects, labels, agents, and other resources after role escalation.The attacker only needs an authenticated low-privilege membership in the target workspace. No race condition, special deployment, or administrator action is required.
CVSS v3.1: 8.8