PT-2026-45065 · Pypi · Praisonai-Platform

Published

2026-05-29

·

Updated

2026-05-29

·

CVE-2026-47414

CVSS v3.1

7.6

High

VectorAV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:L

Summary

Type: Insecure Direct Object Reference. Five label endpoints — PATCH /workspaces/{workspace id}/labels/{label id}, DELETE .../labels/{label id}, POST .../issues/{issue id}/labels/{label id}, DELETE .../issues/{issue id}/labels/{label id}, GET .../issues/{issue id}/labels — gate access on require workspace member(workspace id) only and pass URL-supplied label id and issue id straight through to LabelService without verifying either belongs to the workspace. File: src/praisonai-platform/praisonai platform/services/label service.py, lines 35-100; route handlers at src/praisonai-platform/praisonai platform/api/routes/labels.py, lines 42-106. Root cause: identical pattern to the agent / issue / project / comment IDORs in this codebase: the route's workspace id is used as a membership predicate but never threaded through to the service layer. LabelService.get(label id) runs session.get(IssueLabel, label id) with no workspace filter; update/delete inherit the gap; add to issue(issue id, label id) and remove from issue(issue id, label id) write/delete association rows without verifying either ID belongs to the membership-checked workspace; list for issue(issue id) reads them.

Affected Code

File 1: src/praisonai-platform/praisonai platform/services/label service.py, lines 35-100.
class LabelService:
  ...

  async def get(self, label id: str) -> Optional[IssueLabel]:
    return await self. session.get(IssueLabel, label id)     # <-- BUG: no workspace id predicate

  async def update(
    self,
    label id: str,
    ...
  ) -> Optional[IssueLabel]:
    label = await self.get(label id)               # <-- inherits the gap
    ...

  async def delete(self, label id: str) -> bool:
    label = await self.get(label id)               # <-- inherits the gap
    ...

  async def add to issue(self, issue id: str, label id: str) -> None:
    # writes a row in issue label association table; no workspace check on either id

  async def remove from issue(self, issue id: str, label id: str) -> None:
    # deletes from association table; no workspace check on either id

  async def list for issue(self, issue id: str) -> list[IssueLabel]:
    # reads from association table; no workspace check on issue id
File 2: src/praisonai-platform/praisonai platform/api/routes/labels.py, lines 42-106.
@router.patch("/labels/{label id}", response model=LabelResponse)
async def update label(workspace id: str, label id: str, body: LabelUpdate, ...):
  svc = LabelService(session)
  label = await svc.update(label id, body.name, body.color)    # <-- writes any label in the DB
  ...

@router.delete("/labels/{label id}", ...)
async def delete label(workspace id: str, label id: str, ...):
  deleted = await svc.delete(label id)               # <-- deletes any label in the DB
  ...

@router.post("/issues/{issue id}/labels/{label id}", ...)
async def add label to issue(workspace id: str, issue id: str, label id: str, ...):
  await svc.add to issue(issue id, label id)            # <-- attaches any label to any issue cross-workspace

@router.delete("/issues/{issue id}/labels/{label id}", ...)
async def remove label from issue(workspace id: str, issue id: str, label id: str, ...):
  await svc.remove from issue(issue id, label id)         # <-- detaches any label from any issue cross-workspace

@router.get("/issues/{issue id}/labels", ...)
async def list issue labels(workspace id: str, issue id: str, ...):
  labels = await svc.list for issue(issue id)           # <-- reads label assignments for any issue
Why it's wrong: the workspace id URL segment is treated as a UI hint; the actual label id and issue id lookups query the database without a workspace constraint. The MemberService in this same codebase uses a composite key correctly; the label service does not. The add to issue and remove from issue paths are particularly nasty because they touch two unverified IDs at once: an attacker can attach a foreign workspace's label to a foreign workspace's issue (or detach the legitimate labels), corrupting both sides of an association the attacker has no business touching.

Exploit Chain

  1. Attacker registers a workspace W attacker (member) and harvests a foreign-workspace label id L T and a foreign-workspace issue id I T. Both leak via list labels responses (which include label IDs — but only for W attacker; for the target the IDs come from issue records that include label associations, activity feeds, exported dumps, error messages). State: attacker holds L T and I T.
  2. Attacker authenticates and sends PATCH /workspaces/W attacker/labels/L T with {"name": "<deleted>", "color": "#000000"}. require workspace member(W attacker, attacker) passes. LabelService.update(L T, ...) loads the foreign label and renames it. State: every issue across the foreign workspace that bears this label now displays the attacker-chosen name and colour.
  3. Attacker sends DELETE /workspaces/W attacker/labels/L T. LabelService.delete(L T) deletes the foreign label, dropping every issue-label association row that referenced it (cascade or orphan, depending on schema). State: foreign workspace's labels are gone or corrupted.
  4. Attacker sends POST /workspaces/W attacker/issues/I T/labels/L T2 to attach foreign label L T2 to foreign issue I T. LabelService.add to issue(I T, L T2) writes the association row regardless of either ID's workspace. State: the foreign issue now carries an arbitrary attacker-chosen label, which surfaces in every filter/search/board view in the foreign workspace's UI.
  5. Attacker sends DELETE /workspaces/W attacker/issues/I T/labels/L legit to strip the legitimate label off the foreign issue. State: triagers can no longer find the issue via label filters.
  6. Attacker sends GET /workspaces/W attacker/issues/I T/labels to read the current label set on any foreign issue. State: the attacker fingerprints the foreign workspace's triage taxonomy.
  7. Final state: with one workspace-member token plus harvested foreign IDs, the attacker rewrites and deletes other workspaces' labels, attaches/detaches arbitrary labels on other workspaces' issues, and reads triage state across the deployment.

Security Impact

Severity: sec-moderate. CVSS 6.3: network attack, low complexity, low privileges, no user interaction, scope unchanged. The integrity damage is high (rename/delete of foreign labels is permanent and silent; cross-workspace label-attachment corrupts UI filters), confidentiality is low (label names are not the most sensitive field but do leak triage taxonomy), availability low (foreign workspaces may lose triage visibility into their own issues until the labels are restored). Attacker capability: rename and delete any label in the multi-tenant deployment; attach any label to any issue; detach any label from any issue; list label assignments for any issue. Combined with the companion IssueService IDOR (separate advisory), the attacker can also modify the underlying issue, making the cross-workspace tampering very difficult to detect. Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token; target IDs are known or guessable. Differential: source-inspection-verified end-to-end. The asymmetry between LabelService.list for workspace(workspace id) (correctly workspace-scoped) and LabelService.get(label id) / add to issue(issue id, label id) (no workspace check) confirms the gap. With the suggested fix below, label and issue IDs that do not belong to the membership-checked workspace return 404, and the attacker cannot touch them.

Suggested Fix

Make every single-row label lookup take the workspace predicate; verify both issue id and label id belong to workspace id for the association routes.
--- a/src/praisonai-platform/praisonai platform/services/label service.py
+++ b/src/praisonai-platform/praisonai platform/services/label service.py
@@ -33,7 +33,12 @@ class LabelService:
     return label

-  async def get(self, label id: str) -> Optional[IssueLabel]:
-    return await self. session.get(IssueLabel, label id)
+  async def get(self, workspace id: str, label id: str) -> Optional[IssueLabel]:
+    stmt = select(IssueLabel).where(
+      IssueLabel.id == label id,
+      IssueLabel.workspace id == workspace id,
+    )
+    return (await self. session.execute(stmt)).scalar one or none()

-  async def add to issue(self, issue id: str, label id: str) -> None:
+  async def add to issue(self, workspace id: str, issue id: str, label id: str) -> None:
+    # Verify both ids belong to workspace id before writing the association row.
Then update the route handlers in routes/labels.py to thread workspace id through every call. The same single-key-lookup pattern is filed separately for AgentService, IssueService, ProjectService, and CommentService — each is its own exploitable IDOR.

Fix

IDOR

Weakness Enumeration

CWE-639

Related Identifiers

CVE-2026-47414
GHSA-5JX9-W35F-VP65

Affected Products

Praisonai-Platform