Description

PraisonAI is a multi-agent teams system. Versions prior to 0.1.4 of the PraisonAI Platform API have two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires `min_role="member"`, which lets any workspace member promote themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to. Both issues come from the same gap: the route layer pulls `workspace_id` from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The `require_workspace_member()` dependency does its job correctly. The problem is that the service layer doesn't use the information it provides. Version 0.1.4 of the PraisonAI Platform API patch the issue.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-08-07T22:16:59.013Z",
  "pubdate": "2026-08-07T22:16:59.013Z",
  "executiveSummary": "A critical authorization bypass and workspace isolation failure vulnerability exists in the PraisonAI Platform API prior to version 0.1.4. The flaw stems from insufficient access controls at the service layer, where global primary-key lookups for issues and projects are performed without validating workspace ownership. Additionally, member management endpoints insufficiently enforce role requirements, allowing any workspace member with 'min_role=member' to perform administrative actions such as promoting themselves to owner and evicting legitimate owners.\nThis vulnerability impacts all PraisonAI Platform API versions prior to 0.1.4. An authenticated attacker with low privileges can exploit these authorization failures to achieve unauthorized cross-workspace data access, modification, and deletion by manipulating UUID parameters in API requests. Furthermore, attackers can execute full workspace takeovers across any workspace they currently belong to.\nThe risk implications are severe, as confidentiality, integrity, and availability are completely compromised for affected workspaces. Exploitation requires authenticated access to the API and valid workspace membership, but bypasses all intended tenant isolation boundaries and role-based access control hierarchies.",
  "technicalDetails": "The vulnerability is rooted in a disconnect between the route layer and the service layer within the PraisonAI Platform API. While the route layer correctly utilizes the `require_workspace_member()` dependency to verify workspace membership and extract the `workspace_id` from the URL, the underlying service layer completely ignores this workspace scope during resource lookups.\nSpecifically, the service layer executes global primary-key lookups for issues and projects without cross-referencing the targeted `workspace_id`. Consequently, an authenticated attacker can read, modify, and delete resources belonging to any arbitrary workspace simply by swapping the resource or workspace UUIDs within their HTTP API requests.\nA secondary authorization failure resides in the member management endpoints, which handle adding, updating roles, and removing users. These endpoints enforce an insufficient privilege check of `min_role='member'`. This design flaw permits any standard workspace member to exploit administrative functions, allowing them to promote their own account to an owner role and subsequently remove the original workspace owner.\nThe attack flow proceeds as follows: 1. The attacker authenticates to the PraisonAI Platform API with low-privilege credentials within a legitimate workspace. 2. The attacker crafts an API request targeting issues or projects, replacing the legitimate UUID with the UUID of a target resource in another isolated workspace. 3. Because the service layer omits workspace validation, the application processes the request and returns or mutates cross-workspace data. 4. To execute a workspace takeover, the attacker interacts with member management endpoints, leveraging the `min_role='member'` check to assign themselves ownership privileges and evict existing administrators.\nAffected components include the PraisonAI Platform API service layer for issues, projects, and member management. Affected versions include all releases prior to version 0.1.4. The attack vector is network-based via HTTP API requests, requiring low-privilege authentication and valid workspace membership."
}