PT-2026-45487 · Pypi · Praisonai-Platform

Published

2026-06-01

·

Updated

2026-06-01

·

CVE-2026-47415

CVSS v3.1

8.3

High

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

Summary

Type: Insecure Direct Object Reference. The issue CRUD endpoints (GET / PATCH / DELETE /workspaces/{workspace id}/issues/{issue id}) gate access on require workspace member(workspace id) only, then resolve issue id through IssueService.get(issue id) which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace W1 can read, modify, or delete issues that belong to a different workspace W2. File: src/praisonai-platform/praisonai platform/services/issue service.py, lines 72-156; route handlers at src/praisonai-platform/praisonai platform/api/routes/issues.py, lines 82-137. Root cause: the route extracts workspace id from the URL path, uses it solely for the membership gate, then calls IssueService.get(issue id) / IssueService.update(issue id, ...) / IssueService.delete(issue id) without re-checking which workspace the issue actually belongs to. IssueService.get runs a single-key lookup; update and delete call self.get(issue id) first and then mutate the returned row, inheriting the same gap. The MemberService in this same codebase uses a composite (workspace id, user id) key, proving the author knows the safe pattern; it was simply not applied to the issue, agent, project, comment, or label services.

Affected Code

File 1: src/praisonai-platform/praisonai platform/services/issue service.py, lines 72-75 and 97-156.
class IssueService:
  ...

  async def get(self, issue id: str) -> Optional[Issue]:
    """Get issue by ID."""
    return await self. session.get(Issue, issue id)       # <-- BUG: no workspace id predicate

  async def update(
    self,
    issue id: str,
    title: Optional[str] = None,
    ...
  ) -> Optional[Issue]:
    issue = await self.get(issue id)              # <-- inherits the same gap
    if issue is None:
      return None
    ...
    return issue

  async def delete(self, issue id: str) -> bool:
    issue = await self.get(issue id)              # <-- inherits the same gap
    if issue is None:
      return False
    await self. session.delete(issue)
    await self. session.flush()
    return True
File 2: src/praisonai-platform/praisonai platform/api/routes/issues.py, lines 82-137.
@router.get("/{issue id}", response model=IssueResponse)
async def get issue(
  workspace id: str,
  issue id: str,
  user: AuthIdentity = Depends(require workspace member),     # only checks membership in workspace id
  session: AsyncSession = Depends(get db),
):
  svc = IssueService(session)
  issue = await svc.get(issue id)                 # <-- workspace id never threaded through
  if issue is None:
    raise HTTPException(status code=404, detail="Issue not found")
  return IssueResponse.model validate(issue)


@router.patch("/{issue id}", response model=IssueResponse)
async def update issue(
  workspace id: str,
  issue id: str,
  body: IssueUpdate,
  user: AuthIdentity = Depends(require workspace member),
  session: AsyncSession = Depends(get db),
):
  svc = IssueService(session)
  issue = await svc.update(                    # <-- writes to any issue in the DB
    issue id, title=body.title, description=body.description,
    status=body.status, priority=body.priority,
    assignee type=body.assignee type, assignee id=body.assignee id,
    project id=body.project id,
  )
  ...
delete issue (lines 127-137) repeats the pattern.
Why it's wrong: workspace id from the route is used solely as a membership predicate ("are you in some workspace W?"), never as a resource-ownership predicate ("is the issue you are addressing actually inside W?"). The standard FastAPI/SQLAlchemy fix is to make the resource-lookup query include the workspace constraint and treat absence as 404, so a foreign-workspace issue is indistinguishable from a non-existent one. The update issue handler additionally allows the attacker to overwrite project id, which can re-assign the foreign issue to an unrelated project the attacker also does not own — escalating the scope of the write primitive.

Exploit Chain

  1. Attacker registers a workspace W attacker (where they are a member) and harvests a target issue UUID I T from any side channel: the activity feed (activity.py:log records issue id=...), comment threads, error messages, exported issue dumps, issue mentions in agent prompts, or operator screenshots. Issue IDs are uuid4 strings but they are not secret. State: attacker holds I T.
  2. Attacker authenticates and POSTs Authorization: Bearer <attacker jwt> to GET /workspaces/W attacker/issues/I T. require workspace member(W attacker, attacker) passes (attacker is a member of W attacker). State: control flow enters get issue with workspace id=W attacker, issue id=I T.
  3. IssueService.get(I T) runs session.get(Issue, "I T"), which is SELECT * FROM issues WHERE id = 'I T' LIMIT 1 with no workspace id = 'W attacker' filter. The row is returned in full — including title, description (often confidential bug-report content, customer PII, embedded credentials, or internal roadmap data), status, priority, assignee id, created by, and project id. State: response body is the JSON-serialised foreign issue.
  4. Attacker repeats with PATCH /workspaces/W attacker/issues/I T and a body of {"description": "<reset>", "status": "closed", "project id": "<arbitrary>"}. update issue calls svc.update(I T, ...) which loads the target row and mutates the listed fields. State: the foreign workspace's issue is silently re-described, re-statused, and re-projected.
  5. Attacker calls DELETE /workspaces/W attacker/issues/I T to destroy the target issue. IssueService.delete loads the row and calls session.delete(). State: target issue is gone from the foreign workspace.
  6. Final state: any attacker with one workspace-member token can enumerate, exfiltrate, rewrite, and delete every issue in the multi-tenant deployment given the issue UUIDs (which leak through the side channels above). The act svc.log(workspace id, "issue.updated", "issue", issue.id, ...) call at line 118 records the event under W attacker rather than W target, so the foreign workspace's audit trail does not record the tampering — making detection harder.

Security Impact

Severity: sec-high. CVSS 8.1: network attack, low complexity, low privileges (any workspace member), no user interaction, scope unchanged, high confidentiality (full issue body including any embedded secrets), high integrity (arbitrary writes including project re-assignment), low availability (DELETE wipes target issues). Attacker capability: with one workspace-member token plus a harvested issue UUID, an attacker reads the target issue's title, description, status, priority, assignee id, and project id; rewrites any of those fields (silent edit, false closure, malicious re-assignment); re-projects the issue to an unrelated project to confuse triagers; or deletes the issue altogether to destroy evidence of customer reports. Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token; the target issue's UUID is known or guessable (UUIDs leak through activity feeds, comment threads, error messages, exported dumps, and operator screenshots). Differential: source-inspection-verified end-to-end. The asymmetry between IssueService.get(issue id) (no workspace check) and MemberService.get(workspace id, user id) (composite key check) in the same codebase confirms the pattern. With the suggested fix below applied, IssueService.get(workspace id, issue id) returns None for foreign-workspace issues, the route handler returns 404, and the foreign data is indistinguishable from a missing record.

Suggested Fix

Make every single-row resource lookup take the workspace predicate; treat foreign-workspace rows as 404.
--- a/src/praisonai-platform/praisonai platform/services/issue service.py
+++ b/src/praisonai-platform/praisonai platform/services/issue service.py
@@ -69,9 +69,12 @@ class IssueService:
     await self. session.flush()
     return issue

-  async def get(self, issue id: str) -> Optional[Issue]:
-    """Get issue by ID."""
-    return await self. session.get(Issue, issue id)
+  async def get(self, workspace id: str, issue id: str) -> Optional[Issue]:
+    """Get issue by ID, scoped to a workspace."""
+    stmt = select(Issue).where(
+      Issue.id == issue id, Issue.workspace id == workspace id
+    )
+    return (await self. session.execute(stmt)).scalar one or none()

   async def update(
     self,
+    workspace id: str,
     issue id: str,
     ...
   ) -> Optional[Issue]:
-    issue = await self.get(issue id)
+    issue = await self.get(workspace id, issue id)
     ...

-  async def delete(self, issue id: str) -> bool:
+  async def delete(self, workspace id: str, issue id: str) -> bool:
-    issue = await self.get(issue id)
+    issue = await self.get(workspace id, issue id)
Update the route handlers in routes/issues.py to thread workspace id through. The same pattern (single-key resource lookup gated only by workspace-member check) exists in AgentService, ProjectService, CommentService, and LabelService; each is a separate exploitable IDOR and should be filed as its own advisory so each gets a CVE.

Fix

IDOR

Weakness Enumeration

CWE-639

Related Identifiers

CVE-2026-47415
GHSA-XWQ8-FRCG-77Q8

Affected Products

Praisonai-Platform