| Package | Affected versions | Patched versions |
|---|---|---|
| praisonai-platform | < 0.1.4 | 0.1.4 |
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.
File 1: src/praisonai-platform/praisonai_platform/api/routes/issues.py, lines 143-171.
@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, # <-- BUG: no validation that issue_id is in workspace_id
author_id=user.id,
content=body.content,
author_type="member" if user.is_user else "agent",
parent_id=body.parent_id,
)
return CommentResponse.model_validate(comment)
@router.get("/{issue_id}/comments", response_model=List[CommentResponse])
async def list_comments(
workspace_id: str,
issue_id: str,
user: AuthIdentity = Depends(require_workspace_member),
session: AsyncSession = Depends(get_db),
):
svc = CommentService(session)
comments = await svc.list_for_issue(issue_id) # <-- BUG: returns comments on any issue
return [CommentResponse.model_validate(c) for c in comments]
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeFile 2: src/praisonai-platform/praisonai_platform/services/comment_service.py, lines 19-53.
class CommentService:
...
async def create(
self,
issue_id: str,
author_id: str,
content: str,
author_type: str = "member",
comment_type: str = "comment",
parent_id: Optional[str] = None,
) -> Comment:
comment = Comment(
issue_id=issue_id, # <-- accepts any issue_id; no workspace verify
author_type=author_type,
author_id=author_id,
...
)
self._session.add(comment)
await self._session.flush()
return comment
async def list_for_issue(self, issue_id: str) -> list[Comment]:
stmt = (
select(Comment)
.where(Comment.issue_id == issue_id) # <-- no JOIN against issues for workspace constraint
.order_by(Comment.created_at)
)
result = await self._session.execute(stmt)
return list(result.scalars().all())
Why it's wrong: the service trusts the caller-supplied issue_id as authoritative, but the route layer never verified that this issue belongs to the workspace the membership check covers. The standard FastAPI/SQLAlchemy fix is to first resolve the issue scoped to workspace_id (Issue.id = :issue_id AND Issue.workspace_id = :workspace_id) and only then proceed to comment operations. The MemberService.get(workspace_id, user_id) and LabelService.list_for_workspace(workspace_id) calls in the same codebase show the safe predicate; the comment service forgot to apply it.
W_attacker (member) and harvests a target issue UUID I_T from any side channel: agent prompts that mention issues, the activity feed (act_svc.log records issue_id), webhook payloads, exported issue dumps, or simply by being a low-privilege observer of the attacker's own workspace whose internals reference foreign issue IDs (cross-workspace links, search across activity events). State: attacker holds I_T.GET /workspaces/W_attacker/issues/I_T/comments. require_workspace_member(W_attacker, attacker) passes (attacker is a member of W_attacker). State: control flow enters list_comments with workspace_id=W_attacker, issue_id=I_T.CommentService.list_for_issue(I_T) runs SELECT * FROM comments WHERE issue_id = 'I_T' with no workspace constraint. Every comment on the foreign issue is returned: content (often the most sensitive part of an issue tracker — bug-report repro steps with secrets, customer PII, internal triage notes), author_id, author_type, parent_id, created_at. State: response body is the full comment thread of the foreign issue.POST /workspaces/W_attacker/issues/I_T/comments and a body of {"content": "<malicious>"}. 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.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).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.
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 signature.
--- a/src/praisonai-platform/praisonai_platform/api/routes/issues.py
+++ b/src/praisonai-platform/praisonai_platform/api/routes/issues.py
@@ -141,6 +141,11 @@ async def delete_issue(...):
# ── Comments ─────────────────────────────────────────────────────────────────
+async def _require_issue_in_workspace(session, workspace_id: str, issue_id: str):
+ issue = await IssueService(session).get(workspace_id, issue_id) # workspace-scoped get (see companion advisory)
+ if issue is None:
+ raise HTTPException(status_code=404, detail="Issue not found")
+
@router.post("/{issue_id}/comments", response_model=CommentResponse, status_code=status.HTTP_201_CREATED)
async def add_comment(
workspace_id: str,
@@ -149,6 +154,7 @@ async def add_comment(
user: AuthIdentity = Depends(require_workspace_member),
session: AsyncSession = Depends(get_db),
):
+ await _require_issue_in_workspace(session, workspace_id, issue_id)
svc = CommentService(session)
comment = await svc.create(
issue_id=issue_id,
@@ -167,5 +173,6 @@ async def list_comments(
user: AuthIdentity = Depends(require_workspace_member),
session: AsyncSession = Depends(get_db),
):
+ await _require_issue_in_workspace(session, workspace_id, issue_id)
svc = CommentService(session)
comments = await svc.list_for_issue(issue_id)
Companion advisories file the same workspace-scoping gap for AgentService, IssueService, ProjectService, and LabelService. Each is a separate exploitable IDOR.