Summary
The issue create and update endpoints in praisonai-platform accept a project_id in the request body and persist it without validating that the project belongs to the URL workspace. A user who is a member of workspace W_B (and has no access to workspace W_A) can create issues that reference a project owned by W_A. Because ProjectService.get_stats() aggregates issues by project_id with no workspace constraint, those foreign issues are then counted in the victim's own legitimate view of their project statistics. This is a cross-tenant integrity violation reachable by an outsider.
This is distinct from the path-parameter IDOR family fixed in 0.1.4 (CVE-2026-47415, CVE-2026-47418, CVE-2026-47419). Those fixes scoped object references supplied in the URL path. This report concerns an object reference supplied in the request body at write time, which the 0.1.4 fixes did not cover.
Version 0.1.4 fixed a set of path-parameter IDORs by threading workspace_id into the service-layer lookups (get / update / delete) and by adding the helpers ensure_resource_in_workspace() and require_issue_in_workspace() in api/deps.py. Those helpers are applied to object references that arrive in the URL path. They are not applied to object references that arrive in the request body on create or update.
Details
api/routes/issues.py, create_issue passes the body's project_id straight through with no workspace validation:
@router.post("/", response_model=IssueResponse, status_code=201)
async def create_issue(workspace_id: str, body: IssueCreate,
user=Depends(require_workspace_member), session=Depends(get_db)):
svc = IssueService(session)
issue = await svc.create(
workspace_id=workspace_id,
title=body.title,
creator_id=user.id,
project_id=body.project_id, # attacker-controlled, not validated against workspace_id
...
)