CVE-2026-47416 - PraisonAI Platform workspace owner promotion

PraisonAI Platform versions 0.1.2 and earlier allow a workspace member to change workspace membership roles through the member update endpoint. The route uses a generic workspace-membership dependency that defaults to member, then passes the URL-supplied target user and body-supplied role into the member service without proving the caller is an owner or admin.

For multi-tenant agent platforms, this is a direct authorization-boundary failure. A low-privilege member can become workspace owner, demote legitimate owners, add or remove members, change settings, and then reach adjacent workspace data or agent-management surfaces. The fix is not just a package bump: repositories that wrap, fork, or deploy the platform need role-hierarchy checks, negative authorization tests, and operator review of suspicious membership changes.

Affected versions

  • Vulnerable package: praisonai-platform <=0.1.2
  • Fixed package: praisonai-platform 0.1.4+
  • Affected coordinate: praisonai-platform on PyPI
  • Affected surface: PraisonAI Platform workspace membership APIs, especially role update, member add/remove, workspace update, and workspace delete routes that rely on a default member-level dependency
  • Affected code pattern: a route authorizes Depends(require_workspace_member) or an equivalent default member gate, then mutates workspace roles or workspace state without a second owner/admin check.

Indicator-of-exposure

  • The repository depends on, vendors, forks, or deploys praisonai-platform <=0.1.2.
  • The repository owns a PraisonAI Platform API deployment with workspaces, projects, agents, issues, comments, labels, or team/member management.
  • Route code uses require_workspace_member without a per-route min_role wrapper for privileged operations.
  • Service code updates member.role or workspace state without receiving and validating the caller’s workspace role.
  • Tests cover happy-path member management but do not assert that plain members cannot promote themselves, demote owners, remove members, update workspaces, or delete workspaces.

Quick checks:

rg -n "praisonai-platform|praisonai_platform|require_workspace_member|update_member_role|update_role|VALID_ROLES|workspace_id.*members|member\\.role|delete_workspace|add_member|remove_member" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='

Windows:

rg -n "praisonai-platform|praisonai_platform|require_workspace_member|update_member_role|update_role|VALID_ROLES|workspace_id.*members|member\\.role|delete_workspace|add_member|remove_member" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='

Do not probe production membership APIs with real user accounts, live tenants, or crafted role-change requests during repository triage.

Remediation strategy

  • Upgrade every controlled praisonai-platform dependency, lockfile, image, deployment, SBOM, and generated dependency report to 0.1.4+.
  • Require owner-level authorization for changing member roles. If admins may manage members, explicitly prevent admins from creating, promoting, demoting, or removing owners unless product policy says otherwise.
  • Move authorization into both the route layer and service layer where the repository owns code. The service that changes a role should receive the caller identity and workspace role, not only the target user_id and new role.
  • Replace default FastAPI dependency usage with explicit role-scoped dependencies or dependency factories, then test that each privileged route uses the intended minimum role.
  • Add audit logging for member role changes without logging bearer tokens, session cookies, tenant data, prompts, agent secrets, or model-provider keys.
  • Review recent membership and workspace-setting changes if an affected deployment was reachable by untrusted users.

When to use it

Use this recipe when a repository deploys, vendors, forks, wraps, or packages PraisonAI Platform and exposes workspace membership, invite, member removal, role update, owner transfer, workspace update, or workspace delete routes. It is most important when default member-level dependencies protect privileged member-management operations.

Use it to upgrade the package and prove role hierarchy in both routes and services. Do not use it to send role-change probes to production tenants or to broaden the fix into unrelated PraisonAI advisories unless the same role gate is shared.

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.
  • Membership surfaces: update_member_role, add member, remove member, workspace update, workspace delete, owner transfer, last-owner protection, role validation, and dependency factories such as require_workspace_member.
  • Authorization evidence: caller identity propagation, caller role, target-user role, owner/admin policy, service-layer checks, route-layer checks, audit events, CSRF/session controls, and not-found/forbidden behavior.
  • Synthetic fixtures for owner, admin, member, non-member, self-promotion, owner demotion, owner removal, last-owner loss, and allowed owner actions.
  • Operator evidence for membership-log review: unexpected owner promotions, owner demotions, member removals, workspace updates, workspace deletion, and adjacent agent/project/issue access after promotion.

The prompt

You are remediating CVE-2026-47416 / GHSA-c2m8-4gcg-v22g, a PraisonAI
Platform workspace RBAC flaw where any member can promote themselves or another
member to owner. Produce exactly one output:

- A reviewer-ready PR/change request that upgrades affected package usage,
  fixes owner/admin authorization for member-role changes, adds negative RBAC
  tests, refreshes generated artifacts, and documents operator review actions,
  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-47416 / GHSA-c2m8-4gcg-v22g and directly related
  workspace membership authorization.
- Treat bearer tokens, cookies, user IDs, email addresses, workspace IDs,
  tenant data, prompts, agent configuration, model-provider keys, audit logs,
  and database rows as sensitive.
- Do not send role-change requests to production, use real customer accounts,
  print live tokens, dump tenant membership tables, or broaden into unrelated
  PraisonAI advisories except where the same role gate must be fixed in the
  touched route family.
- Do not weaken authentication, authorization, tenant isolation, CSRF
  protection, audit logging, 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, and local API wrappers.
2. Determine every resolved `praisonai-platform` version. A target is
   vulnerable if it resolves to `0.1.2` or earlier.
3. Search owned code for workspace membership and role changes:
   `require_workspace_member`, `min_role`, `update_member_role`,
   `MemberService.update_role`, `VALID_ROLES`, `add_member`, `remove_member`,
   `delete_workspace`, `update_workspace`, and routes under
   `/workspaces/{workspace_id}/members`.
4. If this repository only calls an externally owned PraisonAI Platform
   service, stop with `TRIAGE.md` listing checked files, the external owner,
   and the required fixed version and 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 role hierarchy:
   - member-role updates require owner authority unless product policy
     explicitly allows a narrower admin action;
   - the service method receives the caller identity and validates the caller's
     current workspace role before mutating the target member;
   - a caller cannot promote themselves above their current role;
   - an admin cannot create, promote, demote, or remove owners unless the
     product policy and tests explicitly allow it;
   - the last owner cannot be demoted or removed without a safe ownership
     transfer path.
7. Replace unsafe dependency usage. If FastAPI dependencies are used, add an
   explicit owner/admin dependency factory or wrapper instead of relying on a
   default `member` value that route code cannot override.
8. Add safe regression tests using local fixtures only:
   - member cannot promote self to owner;
   - member cannot promote another member;
   - member cannot demote an owner;
   - admin behavior matches product policy;
   - owner can perform the intended member-management action;
   - last-owner protection works;
   - denied responses and audit logs omit tokens, cookies, prompts, and tenant
     data.
9. Add or verify audit events for successful and denied privileged membership
   changes. Include actor, target, workspace, old role, new role, request ID,
   and decision, but do not log credentials or sensitive content.
10. Add a PR body section named `CVE-2026-47416 operator actions` that states:
    - PraisonAI Platform versions before and after;
    - every workspace/member route reviewed;
    - before/after role gate behavior;
    - whether members, admins, or owners could change roles before the patch;
    - whether workspace, agent, project, issue, comment, or label data may have
      been reachable after owner promotion;
    - audit-log queries or application events operators should review for
      unexpected owner promotions or owner demotions.
11. Run relevant validation: dependency install, lockfile checks, RBAC unit
    tests, API route tests, migration checks, lint/typecheck, deployment
    template rendering, container build, SBOM refresh, dependency/security
    scans, and non-secret smoke checks available in this repository.
12. Use PR title:
    `fix(sec): remediate CVE-2026-47416 in PraisonAI workspace RBAC`.

## 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.
- The repository intentionally allows members to assign owner roles; document
  the business owner and required design decision in `TRIAGE.md`.
- Verification would require production role-change probes, live customer
  accounts, tenant-data queries, 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 to 0.1.2 or earlier.
  • Member-role updates require the intended owner/admin role at the route layer and at the service method that performs the mutation.
  • Negative tests prove low-privilege members cannot promote themselves, promote other members, demote owners, or remove ownership protection.
  • Audit events are present for successful and denied membership changes and do not leak credentials or tenant content.
  • Operator notes include membership-log review for unexpected owner promotions and owner demotions.

Watch for

  • Updating the package while a Docker image, lockfile, constraints file, or generated dependency report still resolves 0.1.2.
  • A FastAPI dependency that has a min_role parameter but is referenced as Depends(require_workspace_member) with the default member role.
  • Fixing only PATCH /members/{user_id} while add-member, remove-member, workspace-update, or workspace-delete routes keep the same default member gate.
  • Service methods that trust route-layer authorization and still accept only workspace_id, target user_id, and requested role.
  • Tests that cover owner success but not member denial, self-promotion, owner demotion, and last-owner protection.

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 for member-role changes, enforces role hierarchy in services and routes, protects the last owner, emits safe audit events, adds negative RBAC tests, refreshes artifacts, and documents operator review actions.
  • TRIAGE.md when no affected runtime, package pin, fork, wrapper, image, deployment, membership route, service layer, or dependency is controlled by the repository.

The output must list versions before/after, every workspace/member route reviewed, before/after role gate behavior, self-promotion and owner-demotion test coverage, audit events, validation commands, and logs to review for unexpected owner changes. It must not use live tenants, expose tokens or tenant data, weaken authorization, or rely only on owner-success tests.

References