Introduction
The PraisonAI Platform is vulnerable to a cross-workspace object access issue. This flaw 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.
Cause of the Vulnerability
The root cause of this issue is that workspace membership authorization and object ownership validation are not bound together. 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.
Affected Routes
The affected pattern appears in workspace-scoped routes such as agents, projects, issues, and comments. For example, the agent routes are scoped under a workspace path, but object access is performed using only the raw `agent_id`.
Impact
Any authenticated workspace member who knows or obtains object UUIDs from another workspace may be able to:
- read other workspaces' agents;
- read agent instructions and metadata;
- modify victim agents;
- delete victim agents;
- potentially read, modify, or delete projects and issues that follow the same object lookup pattern;
- enumerate comments for issues by raw `issue_id`;
- corrupt activity data, project state, and issue state across workspace boundaries.
Suggested Remediation
Recommended fixes:
1. Require every object fetch, update, and delete method to take both `workspace_id` and `object_id`.
2. Enforce object ownership in the service layer.
3. Avoid service methods that resolve workspace-owned objects by global UUID alone.
4. Apply the same object-level ownership checks to agents, projects, issues, comments, dependencies, and any other workspace-owned resources.
5. For comment and dependency helpers that pivot from raw `issue_id`, validate that the parent issue belongs to the authorized workspace before returning or modifying child records.
6. Add regression tests for negative cross-workspace access cases.
7. Return `404 Not Found` or `403 Forbidden` consistently when an object does not belong to the authorized workspace.