CVE-2026-47413

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.

Summary

Type: Privilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101; services/member_service.py, lines 26-38. Root cause: MemberService.add validates only that role is in VALID_ROLES = {"owner", "admin", "member"} — the value, not the caller's right to assign it. The route's Depends(require_workspace_member) resolves to the default min_role="member". So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that would otherwise gate them.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101.

@router.post("/{workspace_id}/members", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"
    session: AsyncSession = Depends(get_db),
):
    member_svc = MemberService(session)
    member = await member_svc.add(workspace_id, body.user_id, body.role)  # <-- writes any (user, role)
    return MemberResponse.model_validate(member)

File 2: src/praisonai-platform/praisonai_platform/services/member_service.py, lines 26-38.

async def add(
    self,
    workspace_id: str,
    user_id: str,
    role: str = "member",
) -> Member:
    """Add a user to a workspace."""
    if role not in VALID_ROLES:                                      # only validates the value
        raise ValueError(f"Invalid role: {role}. Must be one of {VALID_ROLES}")
    member = Member(workspace_id=workspace_id, user_id=user_id, role=role)
    self._session.add(member)                                        # <-- BUG: no caller-permission check
    await self._session.flush()
    return member

Why it's wrong: workspace member management is the textbook capability that must be gated on owner role. The role hierarchy is implemented (MemberService.has_role, member_service.py:80-96), the dependency-tunable min_role parameter exists (require_workspace_member(min_role), deps.py:58), but the POST .../members route uses neither. The VALID_ROLES enum check is purely cosmetic — it accepts "owner" from any caller because the route never asked whether the caller has the right to assign that role.

Exploit Chain

1. Attacker registers two accounts (or recruits a member account on the target workspace W). Account A is an existing member of W; Account B is a fresh signup the attacker controls (any account on the platform — auth/register is open by default). State: attacker holds tokens for both A and B.
2. Attacker authenticates as Account A and POSTs Authorization: Bearer <A_jwt> to POST /workspaces/W/members with body {"user_id": "<B_user_id>", "role": "owner"}. State: control flow enters add_member.
3. require_workspace_member(W, A) passes (A is a member). MemberService.add(W, B, "owner") writes a new row Member(workspace_id=W, user_id=B, role="owner"). State: Account B is now a workspace-W owner.
4. Attacker switches to Account B and acts as workspace owner — change settings, add/remove members, delete the workspace, or pivot to the companion advisories' primitives. State: attacker holds owner of any workspace they had member access to, via a fresh…

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have aprivilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. PraisonAI Platform version 0.1.4 patches the issue.

Summary

Type: Privilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101; services/member_service.py, lines 26-38. Root cause: MemberService.add validates only that role is in VALID_ROLES = {"owner", "admin", "member"} — the value, not the caller's right to assign it. The route's Depends(require_workspace_member) resolves to the default min_role="member". So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that would otherwise gate them.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101.

@router.post("/{workspace_id}/members", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"
    session: AsyncSession = Depends(get_db),
):
    member_svc = MemberService(session)
    member = await member_svc.add(workspace_id, body.user_id, body.role)  # <-- writes any (user, role)
    return MemberResponse.model_validate(member)

File 2: src/praisonai-platform/praisonai_platform/services/member_service.py, lines 26-38.

async def add(
    self,
    workspace_id: str,
    user_id: str,
    role: str = "member",
) -> Member:
    """Add a user to a workspace."""
    if role not in VALID_ROLES:                                      # only validates the value
        raise ValueError(f"Invalid role: {role}. Must be one of {VALID_ROLES}")
    member = Member(workspace_id=workspace_id, user_id=user_id, role=role)
    self._session.add(member)                                        # <-- BUG: no caller-permission check
    await self._session.flush()
    return member

Why it's wrong: workspace member management is the textbook capability that must be gated on owner role. The role hierarchy is implemented (MemberService.has_role, member_service.py:80-96), the dependency-tunable min_role parameter exists (require_workspace_member(min_role), deps.py:58), but the POST .../members route uses neither. The VALID_ROLES enum check is purely cosmetic — it accepts "owner" from any caller because the route never asked whether the caller has the right to assign that role.

Exploit Chain

1. Attacker registers two accounts (or recruits a member account on the target workspace W). Account A is an existing member of W; Account B is a fresh signup the attacker controls (any account on the platform — auth/register is open by default). State: attacker holds tokens for both A and B.
2. Attacker authenticates as Account A and POSTs Authorization: Bearer <A_jwt> to POST /workspaces/W/members with body {"user_id": "<B_user_id>", "role": "owner"}. State: control flow enters add_member.
3. require_workspace_member(W, A) passes (A is a member). MemberService.add(W, B, "owner") writes a new row Member(workspace_id=W, user_id=B, role="owner"). State: Account B is now a workspace-W owner.
4. Attacker switches to Account B and acts as workspace owner — change settings, add/remove members, delete the workspace, or pivot to the companion advisories' primitives. State: attacker holds owner of any workspace they had member access to, via a fresh…

Summary

Type: Privilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101; services/member_service.py, lines 26-38. Root cause: MemberService.add validates only that role is in VALID_ROLES = {"owner", "admin", "member"} — the value, not the caller's right to assign it. The route's Depends(require_workspace_member) resolves to the default min_role="member". So a member-level token plus one POST gives the attacker an alternate identity with owner role inside the same workspace, bypassing every owner-only operation that would otherwise gate them.

Affected Code

File 1: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101.

@router.post("/{workspace_id}/members", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)
async def add_member(
    workspace_id: str,
    body: MemberAdd,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"
    session: AsyncSession = Depends(get_db),
):
    member_svc = MemberService(session)
    member = await member_svc.add(workspace_id, body.user_id, body.role)  # <-- writes any (user, role)
    return MemberResponse.model_validate(member)

File 2: src/praisonai-platform/praisonai_platform/services/member_service.py, lines 26-38.

async def add(
    self,
    workspace_id: str,
    user_id: str,
    role: str = "member",
) -> Member:
    """Add a user to a workspace."""
    if role not in VALID_ROLES:                                      # only validates the value
        raise ValueError(f"Invalid role: {role}. Must be one of {VALID_ROLES}")
    member = Member(workspace_id=workspace_id, user_id=user_id, role=role)
    self._session.add(member)                                        # <-- BUG: no caller-permission check
    await self._session.flush()
    return member

Why it's wrong: workspace member management is the textbook capability that must be gated on owner role. The role hierarchy is implemented (MemberService.has_role, member_service.py:80-96), the dependency-tunable min_role parameter exists (require_workspace_member(min_role), deps.py:58), but the POST .../members route uses neither. The VALID_ROLES enum check is purely cosmetic — it accepts "owner" from any caller because the route never asked whether the caller has the right to assign that role.

Exploit Chain

1. Attacker registers two accounts (or recruits a member account on the target workspace W). Account A is an existing member of W; Account B is a fresh signup the attacker controls (any account on the platform — auth/register is open by default). State: attacker holds tokens for both A and B.
2. Attacker authenticates as Account A and POSTs Authorization: Bearer <A_jwt> to POST /workspaces/W/members with body {"user_id": "<B_user_id>", "role": "owner"}. State: control flow enters add_member.
3. require_workspace_member(W, A) passes (A is a member). MemberService.add(W, B, "owner") writes a new row Member(workspace_id=W, user_id=B, role="owner"). State: Account B is now a workspace-W owner.
4. Attacker switches to Account B and acts as workspace owner — change settings, add/remove members, delete the workspace, or pivot to the companion advisories' primitives. State: attacker holds owner of any workspace they had member access to, via a fresh…