CVE-2026-61440

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-xxgv-vgvj-qvxh. This link is maintained to preserve external references.

Original Description

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

Platform members can rewrite shared labels and owner issue labels without owner/admin authorization

Summary

praisonai-platform lets an ordinary workspace member rename and recolor shared labels and add/remove labels on an owner-created issue even though direct label deletion is restricted to workspace admin/owner authority in current releases.

Technical Details

The affected boundary is the difference between ordinary workspace membership and authority to mutate shared workspace triage taxonomy or owner-created issue workflow state. src/praisonai-platform/praisonai_platform/api/routes/labels.py defines PATCH /workspaces/{workspace_id}/labels/{label_id} with user: AuthIdentity = Depends(require_workspace_member). The route verifies the label belongs to the URL workspace, then calls LabelService.update(label_id, body.name, body.color), which writes the shared label name/color.

The paired label delete route shows a stricter intended boundary. DELETE /workspaces/{workspace_id}/labels/{label_id} also verifies the label belongs to the URL workspace, but then calls require_delete_permission(workspace_id, user, session) before deleting. require_delete_permission() allows workspace admins/owners, or a supplied resource_owner_id; because labels have no per-label owner passed to the helper, direct label deletion is effectively admin/owner-only. The local controls confirm that a normal member receives 403 for direct label deletion in current head, 0.1.6, and 0.1.8.

The issue-label link routes have the same under-authorized write boundary. POST /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} and DELETE /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} require only workspace membership after confirming the issue and label belong to the URL workspace. They then call LabelService.add_to_issue(issue_id, label_id) or LabelService.remove_from_issue(issue_id, label_id) without checking whether the caller owns the issue or has workspace admin/owner authority.

As a result, a member who cannot delete a label can still rename/recolor that shared label, remove it from an owner-created issue, and add it back. The non-member controls return 403, so this is not the older cross-workspace IDOR; it is a same-workspace owner/admin authorization gap that remains after workspace scoping checks.

PoV

the PoV starts the PraisonAI Platform FastAPI app in process with an in-memory SQLite database. It creates an owner, a member, and an outsider; the owner creates a workspace, adds the member as a plain member, creates an owner issue, creates a label, and attaches the label to that issue. The member then attempts the direct label delete control and the three label write actions.

Essential excerpt:

member_delete_label = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/labels/{member_delete_control_label_id}",
    headers=member_headers,
)

member_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Member-controlled triage", "color": "#000000"},
    headers=member_headers,
)

member_remove_from_owner_issue = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

member_add_back_to_owner_issue = await client.post(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

outsider_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Outsider attempt"},
    headers=outsider_headers,
)

The full PoV script is included in the appendix below.

PoC

Current head tested:

846568c7a5d8ce9e71e56e4c213f027c04909753
2026-06-17 20:13:04 +0100
chore: clean up redundant 'persist-credentials' entries in GitHub workflows

Run against a local checkout of current head:

uv run --with fastapi --with…

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-xxgv-vgvj-qvxh. This link is maintained to preserve external references.

Original Description

PraisonAI Platform before 0.1.9 fails to properly authorize label and issue-label mutations, allowing workspace members to rename and recolor shared labels and add or remove labels on owner-created issues. Attackers with workspace member privileges can exploit PATCH and POST/DELETE endpoints to alter shared label taxonomy and manipulate issue-label associations without owner or admin authorization.

Platform members can rewrite shared labels and owner issue labels without owner/admin authorization

Summary

praisonai-platform lets an ordinary workspace member rename and recolor shared labels and add/remove labels on an owner-created issue even though direct label deletion is restricted to workspace admin/owner authority in current releases.

Technical Details

The affected boundary is the difference between ordinary workspace membership and authority to mutate shared workspace triage taxonomy or owner-created issue workflow state. src/praisonai-platform/praisonai_platform/api/routes/labels.py defines PATCH /workspaces/{workspace_id}/labels/{label_id} with user: AuthIdentity = Depends(require_workspace_member). The route verifies the label belongs to the URL workspace, then calls LabelService.update(label_id, body.name, body.color), which writes the shared label name/color.

The paired label delete route shows a stricter intended boundary. DELETE /workspaces/{workspace_id}/labels/{label_id} also verifies the label belongs to the URL workspace, but then calls require_delete_permission(workspace_id, user, session) before deleting. require_delete_permission() allows workspace admins/owners, or a supplied resource_owner_id; because labels have no per-label owner passed to the helper, direct label deletion is effectively admin/owner-only. The local controls confirm that a normal member receives 403 for direct label deletion in current head, 0.1.6, and 0.1.8.

The issue-label link routes have the same under-authorized write boundary. POST /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} and DELETE /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} require only workspace membership after confirming the issue and label belong to the URL workspace. They then call LabelService.add_to_issue(issue_id, label_id) or LabelService.remove_from_issue(issue_id, label_id) without checking whether the caller owns the issue or has workspace admin/owner authority.

As a result, a member who cannot delete a label can still rename/recolor that shared label, remove it from an owner-created issue, and add it back. The non-member controls return 403, so this is not the older cross-workspace IDOR; it is a same-workspace owner/admin authorization gap that remains after workspace scoping checks.

PoV

the PoV starts the PraisonAI Platform FastAPI app in process with an in-memory SQLite database. It creates an owner, a member, and an outsider; the owner creates a workspace, adds the member as a plain member, creates an owner issue, creates a label, and attaches the label to that issue. The member then attempts the direct label delete control and the three label write actions.

Essential excerpt:

member_delete_label = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/labels/{member_delete_control_label_id}",
    headers=member_headers,
)

member_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Member-controlled triage", "color": "#000000"},
    headers=member_headers,
)

member_remove_from_owner_issue = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

member_add_back_to_owner_issue = await client.post(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

outsider_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Outsider attempt"},
    headers=outsider_headers,
)

The full PoV script is included in the appendix below.

PoC

Current head tested:

846568c7a5d8ce9e71e56e4c213f027c04909753
2026-06-17 20:13:04 +0100
chore: clean up redundant 'persist-credentials' entries in GitHub workflows

Run against a local checkout of current head:

uv run --with fastapi --with…

Platform members can rewrite shared labels and owner issue labels without owner/admin authorization

Summary

praisonai-platform lets an ordinary workspace member rename and recolor shared labels and add/remove labels on an owner-created issue even though direct label deletion is restricted to workspace admin/owner authority in current releases.

Technical Details

The affected boundary is the difference between ordinary workspace membership and authority to mutate shared workspace triage taxonomy or owner-created issue workflow state. src/praisonai-platform/praisonai_platform/api/routes/labels.py defines PATCH /workspaces/{workspace_id}/labels/{label_id} with user: AuthIdentity = Depends(require_workspace_member). The route verifies the label belongs to the URL workspace, then calls LabelService.update(label_id, body.name, body.color), which writes the shared label name/color.

The paired label delete route shows a stricter intended boundary. DELETE /workspaces/{workspace_id}/labels/{label_id} also verifies the label belongs to the URL workspace, but then calls require_delete_permission(workspace_id, user, session) before deleting. require_delete_permission() allows workspace admins/owners, or a supplied resource_owner_id; because labels have no per-label owner passed to the helper, direct label deletion is effectively admin/owner-only. The local controls confirm that a normal member receives 403 for direct label deletion in current head, 0.1.6, and 0.1.8.

The issue-label link routes have the same under-authorized write boundary. POST /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} and DELETE /workspaces/{workspace_id}/issues/{issue_id}/labels/{label_id} require only workspace membership after confirming the issue and label belong to the URL workspace. They then call LabelService.add_to_issue(issue_id, label_id) or LabelService.remove_from_issue(issue_id, label_id) without checking whether the caller owns the issue or has workspace admin/owner authority.

As a result, a member who cannot delete a label can still rename/recolor that shared label, remove it from an owner-created issue, and add it back. The non-member controls return 403, so this is not the older cross-workspace IDOR; it is a same-workspace owner/admin authorization gap that remains after workspace scoping checks.

PoV

the PoV starts the PraisonAI Platform FastAPI app in process with an in-memory SQLite database. It creates an owner, a member, and an outsider; the owner creates a workspace, adds the member as a plain member, creates an owner issue, creates a label, and attaches the label to that issue. The member then attempts the direct label delete control and the three label write actions.

Essential excerpt:

member_delete_label = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/labels/{member_delete_control_label_id}",
    headers=member_headers,
)

member_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Member-controlled triage", "color": "#000000"},
    headers=member_headers,
)

member_remove_from_owner_issue = await client.delete(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

member_add_back_to_owner_issue = await client.post(
    f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/labels/{label_id}",
    headers=member_headers,
)

outsider_patch_label = await client.patch(
    f"/api/v1/workspaces/{workspace_id}/labels/{label_id}",
    json={"name": "Outsider attempt"},
    headers=outsider_headers,
)

The full PoV script is included in the appendix below.

PoC

Current head tested:

846568c7a5d8ce9e71e56e4c213f027c04909753
2026-06-17 20:13:04 +0100
chore: clean up redundant 'persist-credentials' entries in GitHub workflows

Run against a local checkout of current head:

uv run --with fastapi --with…