CVE-2026-47399 in PraisonAI
Summary
by MITRE • 07/21/2026
PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Prior to version 0.1.4, the workspace-scoped REST routes contain a systemic object-level authorization flaw that allows an authenticated user from one workspace to access, modify, and delete objects belonging to another workspace by supplying the victim object's global UUID. The affected pattern appears in workspace-scoped routes such as agents, projects, issues, and comments. The route layer verifies that the caller is a member of the `workspace_id` provided in the URL, but the service layer later resolves the target object by global object ID only. It does not verify that the resolved object actually belongs to the workspace in the URL. As a result, a valid member of `workspace_attacker` can call a route under `/api/v1/workspaces/{workspace_attacker}/...` while supplying an object UUID from `workspace_victim`. The server authorizes the request based on membership in `workspace_attacker`, then fetches or mutates the victim object by global UUID. This breaks the platform's workspace isolation boundary. PraisonAI Platform version 0.1.4 patches the issue.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/21/2026
This vulnerability represents a critical authorization flaw that fundamentally undermines the security boundaries of the PraisonAI platform's multi-agent teams system. The issue manifests as a systemic object-level authorization weakness affecting workspace-scoped REST endpoints across multiple resource types including agents, projects, issues, and comments. The vulnerability exists due to a fundamental disconnect between the route layer and service layer authorization checks, creating a scenario where proper authentication validation occurs at the route level but fails to enforce proper object ownership verification at the service layer.
The technical implementation of this flaw stems from how the platform handles workspace isolation. When an authenticated user makes a request to a workspace-scoped endpoint such as /api/v1/workspaces/{workspace_id}/agents, the route layer correctly validates that the caller is a member of the specified workspace_id in the URL path. However, subsequent service layer operations rely solely on global UUID resolution without cross-verifying that the target object actually belongs to the workspace specified in the URL. This creates an authorization bypass where malicious actors can exploit the system by supplying valid global UUIDs from other workspaces while operating within their own legitimate workspace membership.
The operational impact of this vulnerability is severe and directly compromises the platform's core security model. An authenticated member of one workspace can gain unauthorized access to sensitive data, modify critical objects, or delete resources belonging to other workspaces simply by knowing the global UUID of target objects. This breach of workspace isolation effectively nullifies the multi-tenant security boundaries that should protect separate organizational units or user groups within the platform. The vulnerability affects not just read operations but also write and delete capabilities, providing attackers with complete control over foreign workspace resources.
This flaw aligns with CWE-639: Authorization Bypass Through User-Controlled Key, which specifically addresses situations where application authorization logic fails to properly validate that a user has appropriate access rights to an object they are attempting to manipulate. The vulnerability also maps to ATT&CK technique T1078.004: Valid Accounts: Cloud Accounts, as it exploits legitimate authentication mechanisms while bypassing authorization controls. The issue demonstrates poor defense-in-depth principles where multiple layers of security validation fail to work in concert, allowing a single point of failure to compromise the entire system's integrity.
The fix implemented in version 0.1.4 addresses this by strengthening the service layer validation to ensure that all object operations verify both workspace membership and object ownership before processing any requests. This requires that when resolving objects by global UUID, the system must confirm that the target object belongs to the workspace specified in the URL path rather than relying solely on route-level authentication. Organizations using PraisonAI should immediately upgrade to version 0.1.4 or later to mitigate this risk and ensure proper isolation between workspaces. The vulnerability highlights the critical importance of implementing consistent authorization checks across all application layers and demonstrates how seemingly minor architectural gaps can create significant security risks in multi-tenant platforms.
The remediation approach taken by PraisonAI addresses the root cause by ensuring that object-level access control decisions are made consistently throughout the application stack. This prevents attackers from exploiting the mismatch between route-level authentication and service-level object resolution, thereby restoring the intended workspace isolation boundaries that are fundamental to any secure multi-tenant system. The fix ensures that all API operations validate both the caller's workspace membership and the target object's workspace ownership before executing any data manipulation operations.