CVE-2026-47412 - PraisonAI Platform workspace delete RBAC bypass

PraisonAI Platform versions before 0.1.4 allow a regular workspace member to call the workspace deletion endpoint. The route checks that the caller is a member of the workspace, but it does not require owner authority before calling the destructive service method. In deployments with real tenants, projects, issues, comments, agents, labels, and member records can be removed by a low-privilege account.

This recipe is for repositories that deploy, vendor, fork, wrap, or package PraisonAI Platform. The safest fix is to upgrade and then prove the destructive workspace lifecycle action is guarded by explicit owner-level authorization, confirmation, audit logging, and tests that deny plain members.

Affected versions

  • Vulnerable package: praisonai-platform <0.1.4
  • Fixed package: praisonai-platform 0.1.4+
  • Affected coordinate: praisonai-platform on PyPI
  • Affected surface: DELETE /workspaces/{workspace_id} and any local fork or wrapper that deletes a workspace after only a member-level check
  • Affected code pattern: a route uses Depends(require_workspace_member) or an equivalent default member gate, then calls WorkspaceService.delete or another destructive tenant-delete operation without owner/admin authorization.

Indicator-of-exposure

  • The repository depends on, vendors, forks, wraps, or deploys praisonai-platform <0.1.4.
  • The deployment supports multi-user workspaces, team invites, agents, projects, issues, comments, labels, or any tenant-owned data.
  • Workspace delete routes use a default membership dependency instead of an explicit owner/admin dependency.
  • Service-layer delete methods accept only workspace_id and do not receive the caller identity, current caller role, confirmation state, or deletion policy.
  • Tests cover owner deletion success but do not assert member denial, last owner handling, soft-delete behavior, recovery, or audit events.

Quick checks:

rg -n "praisonai-platform|praisonai_platform|delete_workspace|WorkspaceService|require_workspace_member|min_role|workspace_id.*delete|status.HTTP_204_NO_CONTENT" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='

Windows:

rg -n "praisonai-platform|praisonai_platform|delete_workspace|WorkspaceService|require_workspace_member|min_role|workspace_id.*delete|status.HTTP_204_NO_CONTENT" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='

Do not validate by deleting production workspaces, using customer accounts, or probing live tenants. Use local fixtures and synthetic workspace IDs.

Remediation strategy

  • Upgrade every controlled praisonai-platform dependency, constraints file, lockfile, image, deployment artifact, SBOM, and generated dependency report to 0.1.4+.
  • Require owner authority for workspace deletion. If the product has an admin role, document whether admins may delete workspaces and enforce that rule in code and tests.
  • Put authorization in the route and in the service layer where this repository owns code. The delete service should receive caller identity, workspace role, and policy inputs instead of trusting the route to have done enough.
  • Add a typed confirmation or equivalent deliberate action for destructive deletion. Prefer soft-delete with a restore window over immediate hard cascade delete where the product can support it.
  • Add audit events for successful and denied delete attempts without logging bearer tokens, cookies, prompts, model-provider keys, tenant content, or secret values.
  • If an affected deployment was reachable, review audit logs for workspace delete attempts by non-owner accounts and for adjacent member-role changes that could have preceded deletion.

When to use it

Use this recipe when a repository deploys, vendors, forks, wraps, or packages PraisonAI Platform and exposes workspace deletion, tenant lifecycle, archival, soft-delete, restore, member-management, or admin routes. It is most important when a default member dependency protects a destructive workspace operation or when tests only prove owner success.

Use it to upgrade the package and require explicit owner/admin authorization, confirmation, recovery behavior, and audit events for workspace deletion. Do not use it to validate against live tenants or delete production workspaces.

Inputs

  • Python manifests, lockfiles, constraints, Dockerfiles, Compose files, Helm charts, Kubernetes manifests, Procfiles, systemd units, CI jobs, deployment templates, docs, SBOMs, generated dependency reports, forks, wrappers, and local API routes.
  • Destructive workspace paths: DELETE /workspaces/{workspace_id}, delete_workspace, WorkspaceService.delete, cascade deletes, archive, restore, soft-delete, member removal, owner transfer, and recovery flows.
  • Authorization evidence: route dependencies, service signatures, caller role, owner/admin policy, last-owner protection, confirmation state, CSRF/session checks, and not-found/forbidden behavior.
  • Synthetic test fixtures for owner, admin, plain member, non-member, foreign workspace ID swaps, confirmation success/failure, audit events, and recovery.
  • Operator evidence: audit logs, backup/recovery posture, public exposure, unexpected delete attempts, member-role changes, ownership changes, and workspace recovery needs.

The prompt

You are remediating CVE-2026-47412 / GHSA-g8rr-7rj2-f627, a PraisonAI
Platform RBAC flaw where any workspace member can delete the entire workspace.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades affected package usage,
  requires owner-scoped authorization for workspace deletion, adds confirmation
  and audit behavior where this repository owns the runtime, refreshes
  generated artifacts, and adds negative RBAC tests, or
- TRIAGE.md if this repository does not control an affected PraisonAI Platform
  runtime, fork, wrapper, image, deployment, or dependency.

## Rules

- Scope only CVE-2026-47412 / GHSA-g8rr-7rj2-f627 and directly related
  workspace deletion authorization.
- Treat bearer tokens, cookies, user IDs, email addresses, workspace IDs,
  tenant data, prompts, agent configuration, model-provider keys, audit logs,
  backups, and database rows as sensitive.
- Do not delete production workspaces, use real customer tenants, print live
  tokens, dump tenant tables, or send destructive requests to live services.
- Do not remove authentication, authorization, tenant isolation, CSRF
  protection, audit logging, recovery controls, or tests to silence the
  finding.
- Do not auto-merge.

## Steps

1. Inventory every PraisonAI Platform reference controlled by this repository:
   requirements, pyproject files, lockfiles, constraints, Dockerfiles,
   Compose files, Helm charts, Kubernetes manifests, Procfiles, systemd units,
   CI jobs, deployment templates, `.env.example`, docs, SBOMs, generated
   dependency reports, forks, wrappers, and local API routes.
2. Determine every resolved `praisonai-platform` version. A target is
   vulnerable if it resolves to a version earlier than `0.1.4`.
3. Search owned code for destructive workspace actions:
   `delete_workspace`, `WorkspaceService.delete`, `require_workspace_member`,
   `min_role`, `owner`, `admin`, `workspace_id`, `cascade`, `soft_delete`,
   `archive`, `restore`, and routes under `/workspaces/{workspace_id}`.
4. If this repository only calls an externally owned PraisonAI Platform
   service, stop with `TRIAGE.md` listing checked files, the external owner,
   the required fixed version, and the required workspace-delete RBAC contract.
5. Upgrade all controlled package pins to `praisonai-platform 0.1.4+`.
   Regenerate lockfiles, constraints, image metadata, SBOMs, dependency
   reports, and generated docs.
6. Where the repository owns a fork, wrapper, route, or compatibility shim,
   enforce destructive-action authorization:
   - workspace deletion requires owner authority unless product policy
     explicitly assigns that power elsewhere;
   - route code uses an explicit owner/admin dependency instead of a default
     member gate;
   - service code receives caller identity and validates the caller's current
     workspace role before deleting;
   - not-found and forbidden responses do not leak whether a guessed workspace
     exists;
   - the last-owner and ownership-transfer behavior is explicit and tested.
7. Add a confirmation guard for destructive delete where this repository owns
   the API or UI:
   - require a typed workspace name, fresh reauthentication, a one-time
     confirmation token, or another deliberate user action;
   - reject empty or stale confirmations;
   - do not log confirmation payloads if they contain tenant-sensitive names;
   - prefer soft-delete and restore where the product supports it.
8. Add safe local regression tests with synthetic tenants:
   - plain member cannot delete the workspace;
   - admin behavior matches documented product policy;
   - owner can delete only with required confirmation;
   - owner cannot delete a different workspace by ID swap;
   - denied delete attempts emit safe audit events;
   - logs and test output omit tokens, prompts, tenant content, and secret
     values.
9. Add or verify audit events for successful and denied deletion attempts.
   Include actor, workspace, role, decision, request ID, and confirmation
   status, but no credentials or sensitive content.
10. Add a PR body section named `CVE-2026-47412 operator actions` that states:
    - PraisonAI Platform versions before and after;
    - every workspace delete route, service, wrapper, and deployment reviewed;
    - before/after minimum role for deletion;
    - whether deletion is hard delete or soft delete;
    - what confirmation or recovery behavior exists;
    - which logs operators should review for unexpected workspace deletion
      attempts, member-role changes, and ownership changes;
    - which validation commands passed.
11. Run relevant validation: dependency install, lockfile checks, RBAC unit
    tests, API route tests, migration checks, recovery/soft-delete tests where
    available, lint/typecheck, deployment-template rendering, container build,
    SBOM refresh, dependency/security scans, and local non-secret smoke checks.
12. Use PR title:
    `fix(sec): remediate CVE-2026-47412 in PraisonAI workspace deletion`.

## Stop conditions

- No affected PraisonAI Platform runtime, package pin, fork, wrapper, image, or
  deployment is controlled by this repository.
- A fixed `praisonai-platform` version cannot be consumed without a broader
  platform migration.
- Product policy intentionally lets any member delete a workspace; document the
  security-owner approval required in `TRIAGE.md`.
- Verification would require production workspace deletion, live customer
  accounts, tenant-data queries, backup restoration, or credential disclosure.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled lockfile, image, SBOM, or deployment target resolves praisonai-platform below 0.1.4.
  • Workspace deletion requires the documented owner/admin role at both the route boundary and the service method that performs deletion.
  • Negative tests prove plain members cannot delete workspaces and cannot swap a foreign workspace ID into the request.
  • Destructive deletion requires deliberate confirmation or a documented reason why the product cannot support it yet.
  • Operator notes include audit-log review for delete attempts, membership changes, owner promotions, and workspace recovery needs.

Watch for

  • Updating the package while Docker images, lockfiles, constraints, generated reports, or SBOMs still resolve a vulnerable version.
  • A FastAPI route that uses Depends(require_workspace_member) with a default member role for destructive workspace operations.
  • Service methods that trust route-layer authorization and still accept only workspace_id.
  • Tests that prove owner success but never assert member denial.
  • Immediate hard cascade deletes with no confirmation, audit trail, recovery window, or operator runbook.
  • Returning different errors that reveal whether a guessed workspace exists.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades every controlled praisonai-platform runtime to 0.1.4+, requires owner/admin authorization at route and service layers, adds deliberate confirmation or documented recovery behavior, emits safe audit events, adds negative RBAC tests, and refreshes artifacts.
  • TRIAGE.md when no affected runtime, package pin, fork, wrapper, image, deployment, route, destructive workspace flow, or dependency is controlled by the repository.

The output must list versions before/after, every delete route and service reviewed, before/after minimum role, hard vs soft delete behavior, confirmation/recovery design, audit events, validation commands, and logs to review for delete attempts or member/owner changes. It must not delete production workspaces, expose tenant data, weaken authorization, or rely only on owner-success tests.

References