CVE-2026-47412

Type: Authorization bypass enabling destructive action. The DELETE /workspaces/{workspace_id} endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member"). Any member of the workspace can issue a single DELETE to wipe the entire workspace, including every project, issue, comment, agent, label, and member record (cascading via the foreign-key relationships). There is no owner-role gate, no confirmation token, no soft-delete window, no recovery path.
File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 77-86; services/workspace_service.py's delete() method.
Root cause: the route uses Depends(require_workspace_member) which defaults to min_role="member" and is never overridden. The service method WorkspaceService.delete(workspace_id) performs the destructive operation without any caller-permission verification. The role hierarchy (MemberService.has_role, member_service.py:80-96) is implemented but unused for this endpoint.

Affected Code

File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 77-86.

@router.delete("/{workspace_id}", status_code=status.HTTP_204_NO_CONTENT)
async def delete_workspace(
    workspace_id: str,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"
    session: AsyncSession = Depends(get_db),
):
    ws_svc = WorkspaceService(session)
    deleted = await ws_svc.delete(workspace_id)                     # <-- destructive, no role check
    if not deleted:
        raise HTTPException(status_code=404, detail="Workspace not found")

Why it's wrong: workspace deletion is the most destructive single action in this product, it wipes every member, project, issue, comment, agent, and label belonging to the tenant. The standard convention is to gate this on owner role, ideally with a confirmation parameter (typed workspace name) and a recovery window. This endpoint does none of that. The require_workspace_member(min_role) parameter exists precisely for this kind of tightening but is never invoked with anything other than the default.

Exploit Chain

1. Attacker is a member of workspace W (joined via invite, signup default, or any other route into membership). State: attacker holds JWT with Member(workspace_id=W, user_id=attacker, role="member").
2. Attacker sends DELETE /workspaces/W with Authorization: Bearer <attacker_jwt>. State: control flow enters delete_workspace.
3. require_workspace_member(W, attacker) passes (attacker is a member, default min_role="member" satisfied). WorkspaceService.delete(W) removes the workspace row; SQLAlchemy cascade rules drop every related row (members, projects, issues, comments, agents, labels). State: workspace W no longer exists.
4. Final state: a low-privilege member has wiped the workspace. The legitimate owner has no recovery: no soft-delete, no audit-trail event for the deletion (the Activity log row would have been deleted too as part of the cascade). The same primitive at scale (script that DELETEs every workspace_id the attacker can enumerate) becomes a multi-tenant griefing tool.

Security Impact

Severity: sec-high. CVSS 8.1: network attack, low complexity, low privileges, no user interaction, scope unchanged, no confidentiality (just destruction), high integrity (every workspace child row wiped), high availability (workspace gone for legitimate owner).
Attacker capability: with one workspace-member token plus one DELETE request, the attacker irreversibly deletes the workspace and every child resource. The deletion is silent and immediate.
Preconditions: praisonai-platform is deployed multi-tenant; the attacker has any membership token in the target workspace.
Differential: source-inspection-verified. The asymmetry between require_workspace_member's clearly-tunable min_role parameter and this endpoint's use of the default value confirms the gap. With the suggested fix below, member-tier tokens fail the gate at the dependency, the destructive action never reaches the service layer, and the endpoint returns 403 instead of 204.

The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access. Typical impact: privilege escalation beyond the intended level.

CVE-2026-47412 has a CVSS score of 8.1 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.1.4); upgrading removes the vulnerable code path.

Kodem intelligence

--- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
+++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
@@ -75,11 +75,15 @@
+def _require_workspace_owner(workspace_id: str, user, session):
+    return require_workspace_member(workspace_id, user, session, min_role="owner")
+
 @router.delete("/{workspace_id}", status_code=status.HTTP_204_NO_CONTENT)
 async def delete_workspace(
     workspace_id: str,
-    user: AuthIdentity = Depends(require_workspace_member),
+    user: AuthIdentity = Depends(_require_workspace_owner),
     session: AsyncSession = Depends(get_db),
 ):
     ws_svc = WorkspaceService(session)
     deleted = await ws_svc.delete(workspace_id)
     if not deleted:
         raise HTTPException(status_code=404, detail="Workspace not found")

Defence-in-depth: require a typed-confirmation parameter (e.g. body {"confirm_name": "<workspace_name>"}) and implement a 30-day soft-delete with restore. The four companion workspace-mutation endpoints (update_workspace, add_member, update_member_role, remove_member) exhibit the same default-min-role gap and are filed as their own advisories.

1. What is CVE-2026-47412? CVE-2026-47412 is a high-severity improper privilege management vulnerability in praisonai-platform (pip), affecting versions < 0.1.4. It is fixed in 0.1.4. The application assigns, modifies, tracks, or checks privileges incorrectly, allowing a user to gain elevated access.
2. How severe is CVE-2026-47412? CVE-2026-47412 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
3. Which versions of praisonai-platform are affected by CVE-2026-47412? praisonai-platform (pip) versions < 0.1.4 is affected.
4. Is there a fix for CVE-2026-47412? Yes. CVE-2026-47412 is fixed in 0.1.4. Upgrade to this version or later.
5. Is CVE-2026-47412 exploitable, and should I be worried? Whether CVE-2026-47412 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
6. What actually determines whether CVE-2026-47412 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
7. How do I fix CVE-2026-47412? Upgrade praisonai-platform to 0.1.4 or later.