GHSA-cp4f-5m9r-5jc2 praisonai-platform: Comment endpoints accept any issue_id without workspace ownership check, cross-workspace comment read and post IDOR

• PyPI praisonai-platform: < 0.1.4 → fixed in 0.1.4

Summary Type: Insecure Direct Object Reference. The comment endpoints (`POST /workspaces/{workspace_id}/issues/{issue_id}/comments` and `GET .../comments`) gate access on `require_workspace_member(workspace_id)` only, then call `CommentService.create(issue_id=issue_id, ...)` and `CommentService.list_for_issue(issue_id)` without verifying that `issue_id` belongs to `workspace_id`. A user who is a member of any workspace `W1` can read every comment on, and post new comments to, any issue in any other workspace `W2`. File: `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 143-171; `src/praisonai-platform/praisonai_platform/services/comment_service.py`, lines 19-53. Root cause: the route extracts `workspace_id` from the URL path and uses it solely for the membership gate, then passes the URL-supplied `issue_id` straight into `CommentService` without confirming that this issue exists in `workspace_id`. `CommentService.list_for_issue(issue_id)` runs `SELECT * FROM comments WHERE issue_id = :issue_id` with no workspace join. `CommentService.create(issue_id=issue_id, ...)` blindly writes a row with that `issue_id`. Both flows trust the URL-supplied issue ID as authoritative even though the membership check guarantees nothing about it. Affected Code File 1: `src/praisonai-platform/praisonai_platform/api/routes/issues.py`, lines 143-171. ```python @router.post("/{issue_id}/comments", response_model=CommentResponse, status_code=status.HTTP_201_CREATED) async def add_comment( workspace_id: str, issue_id: str, body: CommentCreate, user: AuthIdentity = Depends(require_workspace_member), # only checks attacker is in workspace_id session: AsyncSession = Depends(get_db), ): svc = CommentService(session) comment = await svc.create( issue_id=issue_id, # Comment: comment = Comment( issue_id=issue_id, # list[Comment]: stmt = ( select(Comment) .where(Comment.issue_id == issue_id) # "}`. `CommentService.create(issue_id=I_T, author_id=attacker, ...)` writes a row with the foreign issue's id and the attacker's `author_id`. State: a new comment authored by the attacker appears in the foreign workspace's issue thread, indistinguishable to the foreign workspace's UI from a legitimate cross-workspace mention. Used at scale this becomes a comment-spam / phishing primitive (links in the comment body) targeting another tenant's users. 5. Final state: any attacker with one workspace-member token can exfiltrate every comment in the multi-tenant deployment given the issue UUIDs, and inject arbitrary comments under their own author identity into any foreign issue. The cross-workspace attribution gap is the worst part: the comment is recorded with the attacker's `author_id`, but the foreign workspace has no member with that id and the foreign workspace's audit logs show no event (the `act_svc.log` call in `add_comment` is omitted). Security Impact Severity: sec-high. CVSS 7.6: network attack, low complexity, low privileges, no user interaction, scope unchanged, high confidentiality (full comment threads), high integrity (cross-workspace comment injection under attacker's own id), no availability claim. Attacker capability: read every comment on every issue in the multi-tenant deployment given the issue UUIDs; post arbitrary comments under the attacker's identity into any foreign issue, allowing comment-spam, phishing-link injection into another tenant's UI, or social-engineering attribution attacks (the foreign workspace's UI renders a comment whose author belongs to no member of that workspace). Preconditions: `praisonai-platform` is deployed multi-tenant; the attacker has any membership token; the target issue's UUID is known or guessable. Differential: source-inspection-verified end-to-end. The asymmetry between `CommentService.list_for_issue(issue_id)` (no workspace predicate) and `LabelService.list_for_workspace(workspace_id)` (correctly workspace-scoped) confirms the gap. With the suggested fix below, every comment route first resolves the issue scoped to `workspace_id`, returns 404 if the issue is foreign, and only then proceeds. Suggested Fix Resolve the issue scoped to `workspace_id` at the route layer before dispatching to `CommentService`. This both fixes the read and the write paths and avoids changing the `CommentService` sign…