Privilege Escalation via Insufficient Authorization Check in Workspace Member Addition

Vulnerability Description

The vulnerability is a horizontal privilege escalation stemming from missing authorization validation in the member-addition endpoint. The POST /workspaces/{workspace_id}/members route gates entry via require_workspace_member() (minimum role: member), but the downstream MemberService.add() function performs only role-value validation (checking that the supplied role string exists in VALID_ROLES), not caller-permission validation (checking whether the caller has authority to assign that role). This architectural gap allows any member-level user to invoke the service with role="owner" and successfully elevate any user—including a second attacker-controlled account or a griefing target—to owner status within the workspace.

Proof-of-Concept Significance

The PoC significance is high reliability with minimal preconditions: an attacker needs only valid workspace-member credentials (the lowest privilege tier) and network access to the API endpoint. The PoC demonstrates that no additional checks (IP whitelisting, MFA, approval workflows) gate the privilege escalation. The exploit is deterministic—a single POST request succeeds—and creates a persistent foothold: once the attacker-controlled account holds owner role, it survives credential rotation or session invalidation of the original member account. This makes the vulnerability exploitable by insider threats, compromised low-privilege service accounts, or lateral-movement adversaries.

Detection Guidance

Log Indicators:

• POST requests to /workspaces/{workspace_id}/members where the caller's current role is "member" and the request body specifies "role": "owner".
• Sudden role-elevation events in audit logs where the target user's role changes from unprivileged (or first-appearance) to "owner" without corresponding approvals or admin action.
• Multiple member-addition requests from the same source IP/user ID within a short timeframe, especially targeting different workspace IDs.

Detection Signatures:

• Monitor for HTTP 201 (Created) responses to member-addition endpoints preceded by failed or low-privilege requests.
• Flag workspace role-change events where the actor lacks "admin" or "owner" role prior to the change.

Mitigation Steps

1. Patch Immediately: Apply the fix to MemberService.add() to include caller-permission validation: verify that the calling user's role permits assignment of the requested role (e.g., only owners can assign owner/admin roles).
2. Configuration Hardening: Modify the route's Depends(require_workspace_member) to include explicit min_role="admin" or implement a custom dependency that checks role hierarchy before delegating to the service layer.
3. Temporary Workaround (if patching is delayed): Restrict member-addition permissions to owner-level users only via API gateway or reverse-proxy rules; log all member-addition attempts for forensic review.
4. Validation Layer: Add server-side validation that prevents a user from assigning a role equal to or higher than their own; enforce role-hierarchy checks at both the route and service layers (defense in depth).

Risk Assessment

Likelihood of Exploitation: High. The vulnerability requires minimal prerequisites (member-level access, network reach), is trivial to exploit, and carries immediate high impact. Insider threats and supply-chain compromises (e.g., breached CI/CD credentials) are plausible attack vectors. Once owned, a workspace grants access to sensitive data and configuration, enabling further lateral movement or data exfiltration.

Threat Actor Interest: Critical infrastructure, SaaS platforms, and regulated industries using PraisonAI are likely targets. The vulnerability is particularly attractive to adversaries seeking persistent, stealthy privilege escalation without triggering unusual network signatures or requiring social engineering. The fix should be treated as security-critical and deployed with priority.