The listing is scoped correctly. The get, update, and delete methods are not. Since update() and delete() in both services call self.get() internally, the workspace bypass cascades through all write operations too.
Route that discards workspace_id, issues.py line 82:
@router.get("/{issue_id}", response_model=IssueResponse)
async def get_issue(
workspace_id: str, # Extracted from URL
issue_id: str,
user: AuthIdentity = Depends(require_workspace_member), # Membership verified
session: AsyncSession = Depends(get_db),
):
svc = IssueService(session)
issue = await svc.get(issue_id) # workspace_id never passed to service
All affected operations:
| Service | Method | Line | Workspace scoped? |
|---------|--------|------|-------------------|
| IssueService | get() | 72 | No, uses session.get(Issue, issue_id) |
| IssueService | update() | 97 | No, calls self.get(issue_id) |
| IssueService | delete() | 150 | No, calls self.get(issue_id) |
| IssueService | list_for_workspace() | 76 | Yes, filters by workspace_id |
| ProjectService | get() | 47 | No, uses session.get(Project, project_id) |
| ProjectService | update() | 62 | No, calls self.get(project_id) |
| ProjectService | delete() | 88 | No, calls self.get(project_id) |
| ProjectService | get_stats() | 97 | No, only filters by project_id |
| ProjectService | list_for_workspace() | 51 | Yes, filters by workspace_id |
Part 2: Workspace Takeover via Missing Role Enforcement
This works correctly, but no route ever calls require_workspace_member with min_role="owner" or min_role="admin". Every member management route uses the default "member":
Self-promotion, workspaces.py line 115:
@router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse)
async def update_member_role(
workspace_id: str,
user_id: str,
body: MemberUpdate,
user: AuthIdentity = Depends(require_workspace_member), # min_role="member"
session: AsyncSession = Depends(get_db),
):
member_svc = MemberService(session)
member = await member_svc.update_role(workspace_id, user_id, body.role)
# No check: is user modifying their own role? (self-promotion)
# No check: is body.role > caller's current role? (escalation)
# No check: is target a higher role than caller? (modifying superiors)
Owner removal, workspaces.py line 130:
@router.delete("/{workspace_id}/members/{user_id}", status_code=204)
async def remove_member(
workspace_id: str,
user_id: str,
user: AuthIdentity = Depends(require_workspace_member), # min_role="member"
...
):
member_svc = MemberService(session)
removed = await member_svc.remove(workspace_id, user_id)
# No check: is target a higher role than caller?
# No check: is this the last owner?
Three checks are missing from update_member_role: self-modification, upward escalation, and modifying superiors. Two checks are missing from remove_member: role hierarchy and last-owner protection.
PoC
Prerequisites:
A running PraisonAI Platform instance with default configuration
{
"id": "<ISSUE_ID>",
"workspace_id": "<VICTIM_WS>",
"title": "M&A Target List",
"description": "Acquiring CompanyX for $2B. Board approved. Do not disclose.",
"status": "backlog"
}
The response contains the victim's workspace_id, which is different from the workspace in the request URL. The request was scoped to $ATK_WS but returned data from $VICTIM_WS.
The CEO is locked out. The attacker is now the sole owner of "Executive Board" and all its data.
Impact
Complete multi-tenant data breach: Any authenticated user can read every issue and project across all workspaces by substituting resource UUIDs. The URL structure (/workspaces/{workspace_id}/...) implies tenant isolation but provides none.
Cross-workspace data tampering: An attacker can modify issue titles, descriptions, statuses, assignments, and project fields across workspace boundaries.
Cross-workspace data deletion: An attacker can delete issues and projects belonging to other workspaces.
Workspace takeover from member role: Any member can self-promote to owner and remove all other owners, gaining sole control of the workspace and everything in it.
No recovery mechanism: After takeover, the original owner cannot access or recover their workspace. There is no super-admin role, no audit-based rollback, and no last-owner protection.
Chain amplifies impact: The IDOR does not require membership in the target workspace, only membership in any workspace. The privilege escalation turns that foothold into full ownership. Together, a user with a single member-level invite to any workspace can read all data platform-wide and take ownership of any workspace they are invited to.
Suggested Fix
1. Scope all service get/update/delete methods to workspace_id
# issue_service.py, replace get() at line 72:
async def get(self, issue_id: str, workspace_id: str) -> Optional[Issue]:
"""Get issue by ID, scoped to workspace."""
issue = await self._session.get(Issue, issue_id)
if issue is None or issue.workspace_id != workspace_id:
return None
return issue
# Apply the same pattern to update(), delete(), and all ProjectService methods
2. Pass workspace_id from routes to services
# issues.py, fix get_issue at line 82:
issue = await svc.get(issue_id, workspace_id) # Now workspace-scoped
3. Require owner role for member management and add escalation guards
# workspaces.py, fix update_member_role:
user: AuthIdentity = Depends(
lambda **kw: require_workspace_member(**kw, min_role="owner")
)
# Add self-modification and last-owner guards:
if user_id == user.id:
raise HTTPException(403, "Cannot change your own role")
# Fix remove_member:
target = await member_svc.get(workspace_id, user_id)
if target and target.role == "owner":
owners = [m for m in await member_svc.list_members(workspace_id) if m.role == "owner"]
if len(owners) <= 1:
raise HTTPException(403, "Cannot remove the last owner")
Miggo AI