CVE-2026-47407
CriticalCVSS 9.4Exploitation Probability (EPSS)
Low risk15th percentile - higher than 15% of all known CVEs
Summary
PraisonAI Platform before version 0.1.4 has a vulnerability due to missing verification of resource ownership within workspaces in API endpoints. A user who is a member of one workspace can access resources of another workspace by manipulating the URL path. Additionally, the role hierarchy is not enforced in member management, allowing a basic member to escalate privileges to admin or owner.
Risk Assessment
The organization is at risk of unauthorized cross-tenant data access, potentially leading to leakage of sensitive information. Moreover, regular users can escalate their privileges, taking over or deleting workspaces.
Recommendation
Immediately update PraisonAI Platform to version 0.1.4 or later. If an update is not possible, restrict API access via firewall or network authentication and implement additional server-side validation.
Other vulnerabilities in PraisonAI Platform
See all- CVE-2026-61441Medium
A vulnerability in PraisonAI Platform before version 0.1.9 allows unauthorized deletion of issue dependencies. The authorization mechanism only checks permissions for the endpoint selected by the caller, enabling a workspace member to delete a dependency created by an owner by targeting a related member-owned issue endpoint.
- CVE-2026-47416Critical
PraisonAI Platform versions prior to 0.1.4 have a privilege escalation vulnerability in the PATCH /workspaces/{workspace_id}/members/{user_id} endpoint. There is no caller permission check, allowing a user with the 'member' role to change any member's role, including their own, to 'owner'.
- CVE-2026-47413Critical
PraisonAI Platform versions prior to 0.1.4 have a privilege escalation and cross-tenant member injection vulnerability. The POST /workspaces/{workspace_id}/members endpoint lacks caller permission checks, allowing a user with the lowest role to add any user as an owner of the workspace.
- CVE-2026-47410Critical
PraisonAI Platform versions prior to 0.1.4 use a hardcoded default JWT secret 'dev-secret-change-me' when PLATFORM_JWT_SECRET is unset. The safety check is bypassed because PLATFORM_ENV defaults to 'dev'. An attacker can read the secret from a public source file, forge a JWT with arbitrary claims, and authenticate as any user, including admins.
- CVE-2026-47419High
IDOR vulnerability in PraisonAI Platform before 0.1.4. A user who is a member of any workspace can read, modify, or delete agents from another workspace due to missing workspace constraint. Fixed in version 0.1.4.
- CVE-2026-47418High
Vulnerability in PraisonAI Platform before version 0.1.4. An IDOR (Insecure Direct Object Reference) flaw in project CRUD endpoints allows a member of any workspace to read, modify, delete, or read stats of projects belonging to another workspace.
- CVE-2026-47417High
IDOR vulnerability in PraisonAI Platform (versions before 0.1.4) in comment endpoints allows a member of any workspace to read and post comments to issues in other workspaces without verifying issue ownership.
- CVE-2026-47415High
An IDOR vulnerability in PraisonAI Platform allows a member of one workspace to read, modify, or delete issues belonging to another workspace. The issue exists in versions prior to 0.1.4.
- CVE-2026-47414High
IDOR vulnerability in PraisonAI Platform (versions before 0.1.4) allows an authenticated workspace member to manipulate labels and issues belonging to other workspaces. No verification that the label/issue belongs to the workspace.
- CVE-2026-47412High
Vulnerability in PraisonAI Platform before version 0.1.4. Missing authorization on the DELETE /workspaces/{workspace_id} endpoint allows any workspace member to delete the entire workspace along with all associated data (projects, issues, comments, agents, labels, member records).
Original NVD description (English source)
PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Prior to version 0.1.4, the Platform server exposes resources under `/api/v1/workspaces/{workspace_id}/...` and protects them with a `require_workspace_member(workspace_id)` FastAPI dependency. The dependency only checks that the caller is a member of the workspace_id in the URL prefix. The route handlers then look up the inner resource (`agent_id`, `issue_id`, `project_id`, `label_id`, `comment_id`, `dependency_id`) by primary key alone. The resource's own `workspace_id` is never compared to the URL's `workspace_id`. A user can therefore put their own workspace in the URL prefix and any other workspace's resource ID in the path. The auth check passes, since they really are a member of the prefix workspace. The service then returns the cross-tenant resource for read, update, or delete. There is a second bug in the member-management routes (`add_member`, `update_member_role`, `remove_member`, `update_workspace`, `delete_workspace`). Each one inherits the default `min_role="member"` from `require_workspace_member`. Any basic member can therefore promote themselves to admin or owner, demote or remove other members, and delete the workspace. The role hierarchy exists in the schema but is not enforced. Registration is open at `/api/v1/auth/register` with no email verification. The default server bind is `0.0.0.0:8000` (`python -m praisonai_platform`). One curl from any unauthenticated network position is enough to bootstrap into the system. PraisonAI Platform version 0.1.4 patches the issue.