CVE-2026-47413 - PraisonAI Platform member-add owner injection

PraisonAI Platform releases before 0.1.4 can allow a low-privilege workspace member to add another account to the same workspace with the owner role. The vulnerable route accepts POST /workspaces/{workspace_id}/members, proves only that the caller is already a workspace member, and passes the request body’s user_id and role into the member service. The service validates that the role string is one of the known roles, but it does not prove the caller is allowed to assign that role.

This is different from the companion role-update advisory. The attacker does not need to modify their own membership row with PATCH; they can plant a second attacker-controlled identity, or any known user account, as a workspace owner through the member-add flow. That alternate owner can then change workspace settings, manage members, reach owner-only routes, and make incident review harder because the elevated actions come from a different principal.

GitHub Advisory Database lists the affected range as <0.1.4. The upstream PraisonAI advisory describes the vulnerable code in 0.1.2 and earlier, and both sources agree that 0.1.4 is the fixed release. Treat every controlled praisonai-platform version below 0.1.4 as vulnerable unless a fork has a reviewed equivalent fix.

When to use it

Use this recipe when a repository or PraisonAI Platform deployment manages workspace membership, invitations, or role assignment. It supports source-code remediation, RBAC review, tenant-boundary audit, and evidence that ordinary members cannot assign owner-level privileges.

Inputs

  • PraisonAI Platform version, workspace member routes, role model, session model, invitation flow, and deployment exposure.
  • Source paths for POST /workspaces/{workspace_id}/members, role validation, caller authorization, member service code, audit logs, and notifications.
  • Regression fixtures for owner, admin, member, cross-workspace, invalid role, and owner-assignment attempts.
  • Boundary evidence for impacted workspaces, existing membership changes, audit records, invitations, tokens, and any required rollback/notification.

Affected versions

  • Vulnerable package: praisonai-platform <0.1.4
  • Fixed package: praisonai-platform 0.1.4+
  • Affected coordinate: praisonai-platform on PyPI
  • Affected surface: PraisonAI Platform workspace member invitation/add APIs, especially POST /workspaces/{workspace_id}/members
  • Affected code pattern: a route authorizes only basic workspace membership, then calls a member-add service with a target user_id and requested role without checking the caller’s role or allowed assignment ceiling.
  • Weaknesses: CWE-269 Improper Privilege Management and CWE-862 Missing Authorization

Indicator-of-exposure

  • The repository depends on, vendors, forks, wraps, builds, or deploys praisonai-platform <0.1.4.
  • The repository owns a PraisonAI Platform API deployment with workspaces, members, projects, issues, agents, labels, comments, dependencies, or tenant-level data.
  • Route code uses require_workspace_member or an equivalent member-level dependency for member-add, invitation, membership import, bulk member add, owner assignment, or team synchronization routes.
  • Service code creates membership rows from (workspace_id, user_id, role) without receiving the caller identity and proving the caller can assign the requested role.
  • User registration, directory sync, SSO provisioning, or invitation flows can create or identify another user account that a low-privilege member can add as owner.
  • Tests cover owner happy paths but do not assert that plain members cannot add another user as owner, admin, or any role above their own.

Quick checks:

rg -n "praisonai-platform|praisonai_platform|require_workspace_member|MemberAdd|add_member|MemberService\\.add|VALID_ROLES|workspace_id.*members|user_id.*role|members.*POST|invite|invitation|bulk.*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|MemberAdd|add_member|MemberService\\.add|VALID_ROLES|workspace_id.*members|user_id.*role|members.*POST|invite|invitation|bulk.*member" .
python -m pip show praisonai-platform
python -m pip freeze | rg -i '^praisonai-platform=='

Do not test by adding real users, inviting external accounts, probing production tenants, printing bearer tokens, or dumping membership tables.

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 adding members when the requested role is owner, and use a documented product policy for whether admins may add ordinary members or admins.
  • Enforce role-assignment rules in the service layer as well as the route layer. A member-add service should receive the caller identity and caller role, not only the target user and requested role.
  • Prevent privilege inflation through invitations, bulk imports, SSO/SCIM sync adapters, CLI wrappers, and API compatibility shims that reuse the same member-add primitive.
  • Preserve last-owner and owner-transfer controls. Do not let a member-add fix accidentally create unmanaged owners, duplicate owners, or owner rows for disabled users.
  • Add audit events for successful and denied member-add attempts without logging bearer tokens, cookies, prompts, tenant content, model-provider credentials, or raw membership table dumps.
  • Review recent membership-add events if an affected deployment was reachable by untrusted workspace members.

The prompt

You are remediating CVE-2026-47413 / GHSA-8g2p-pqm3-fcfh, a PraisonAI
Platform member-add authorization flaw where any workspace member can add
another user as workspace owner through `POST /workspaces/{workspace_id}/members`.
Produce exactly one output:

- A reviewer-ready PR/change request that upgrades affected package usage,
  fixes owner/admin authorization for member-add and invitation flows, 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-47413 / GHSA-8g2p-pqm3-fcfh and directly related
  workspace member-add, invitation, owner assignment, role hierarchy, service
  authorization, dependency, image, deployment, and operator-review controls.
- Treat bearer tokens, cookies, user IDs, email addresses, workspace IDs,
  tenant data, prompts, agent configuration, model-provider keys, audit logs,
  invite links, SSO claims, SCIM payloads, and database rows as sensitive.
- Do not add real users, invite external accounts, probe production tenants,
  print tokens, dump tenant membership tables, or use customer workspaces for
  verification.
- Do not broaden into unrelated PraisonAI advisories except where the same
  member-add primitive, role gate, or package upgrade must be changed in the
  touched route family.
- Do not weaken authentication, authorization, tenant isolation, CSRF
  protection, audit logging, registration 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, copied route/service code, local API wrappers,
   CLI wrappers, invitation flows, SSO/SCIM adapters, and bulk member import
   jobs.
2. Determine every resolved `praisonai-platform` version. A target is
   vulnerable if it resolves below `0.1.4`.
3. Search owned code for workspace member-add paths:
   `require_workspace_member`, `MemberAdd`, `add_member`,
   `MemberService.add`, `VALID_ROLES`, `workspace_id`, `user_id`, `role`,
   `members`, `invite`, `invitation`, `bulk member`, `SCIM`, 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 member-add RBAC contract.
5. Upgrade all controlled package pins to `praisonai-platform 0.1.4+`.
   Regenerate lockfiles, constraints, image metadata, SBOMs, dependency
   reports, generated docs, and deployment manifests.
6. Where the repository owns a fork, wrapper, route, compatibility shim, or
   local service layer, enforce role hierarchy for member creation:
   - member-add routes require owner authority when assigning `owner`;
   - admins may add `member` or `admin` only if documented product policy
     allows it;
   - a caller cannot assign a role higher than their own;
   - service methods receive caller identity and caller role, then enforce the
     role assignment before creating the membership row;
   - member-add writes are scoped to the URL workspace and cannot target a
     different workspace through body fields;
   - duplicate membership, disabled users, suspended users, pending invites,
     and external-account invites are handled explicitly.
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-level dependency for privileged member-add routes.
8. Audit adjacent membership entry points in the same repository:
   invitations, bulk imports, SSO/SCIM provisioning, admin CLI tools, API
   clients, workflow actions, seed data, tests, and migration scripts. Apply
   the same role-assignment ceiling where those paths can create workspace
   owners or admins.
9. Add safe regression tests using local fixtures only:
   - member cannot add another account as owner;
   - member cannot add another account as admin if policy reserves that action;
   - member cannot add themselves through an alternate endpoint;
   - admin behavior matches product policy;
   - owner can add the intended role;
   - service-layer checks reject unsafe calls even when a route omits the
     correct dependency;
   - duplicate, disabled, pending, and external-user edge cases do not bypass
     the role gate;
   - denied responses and audit logs omit tokens, cookies, prompts, tenant
     content, invite secrets, and model-provider credentials.
10. Add or verify audit events for successful and denied member-add attempts.
    Include actor, target user, workspace, requested role, decision, request
    ID, and source route, but no credentials or sensitive content.
11. Add a PR body section named `CVE-2026-47413 operator actions` that states:
    - PraisonAI Platform versions before and after;
    - every member-add, invitation, import, and provisioning route reviewed;
    - before/after role gate behavior for members, admins, and owners;
    - whether low-privilege members could add owners before the patch;
    - which logs operators should review for unexpected owner/admin additions,
      external-account invites, duplicate memberships, or unusual second-account
      ownership;
    - what deployment artifacts, SBOMs, and generated docs changed;
    - which validation commands passed.
12. Run relevant validation: dependency install, lockfile checks, RBAC unit
    tests, API route tests, service-layer authorization tests, migration checks,
    lint/typecheck, deployment-template rendering, container build, SBOM
    refresh, dependency/security scans, and local non-secret smoke checks
    available in this repository.
13. Use PR title:
    `fix(sec): remediate CVE-2026-47413 in PraisonAI member adds`.

## Stop conditions

- No affected PraisonAI Platform runtime, package pin, fork, wrapper, image,
  deployment, member-add path, invitation path, or provisioning path is
  controlled by this repository.
- A fixed `praisonai-platform` version cannot be consumed without a broader
  platform migration.
- The repository intentionally allows ordinary members to add owner accounts;
  document the business owner and required design decision in `TRIAGE.md`.
- Verification would require production role-change probes, live customer
  accounts, tenant-data queries, external-user invitations, or credential
  disclosure.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Output contract

  • A reviewer-ready PR or change request that upgrades PraisonAI Platform, requires owner-scoped authorization for privileged role assignment, adds negative RBAC tests, and documents cleanup/notification steps.
  • Or a TRIAGE.md file that lists inspected files, owner, observed version, role-assignment boundary, affected workspaces, required fix, and residual risk.
  • The output must include exact validation commands and must not expose real member lists, invitations, tokens, customer data, or production audit logs.

Verification - what the reviewer looks for

  • No controlled lockfile, image, SBOM, or deployment target resolves praisonai-platform below 0.1.4.
  • Member-add, invitation, import, and provisioning routes require the intended owner/admin role before assigning owner or admin privileges.
  • Service-layer authorization rejects unsafe member creation even if a route or wrapper passes a target user and requested role directly.
  • Negative tests prove low-privilege members cannot add another account as owner or admin, including through invite/import paths.
  • Audit events are present for successful and denied member-add attempts and do not leak credentials, invite secrets, prompts, or tenant content.
  • Operator notes include review of membership-add logs for unexpected owners, external-account invitations, and second-account ownership.

Watch for

  • Fixing PATCH /members/{user_id} while leaving POST /members or invite flows behind a default member-level dependency.
  • Treating a role enum check as authorization. role in VALID_ROLES only proves the string is recognized, not that the caller may assign it.
  • Upgrading a Python package pin while Docker images, Helm values, SBOMs, or generated dependency reports still install an older platform version.
  • Allowing admins to create owners without a product-approved policy and tests.
  • Adding owner-gate checks only in routes while background jobs, CLI tools, sync adapters, or service methods can still create owner rows directly.
  • Logging user tokens, invite links, membership table contents, prompts, or tenant data while reviewing suspicious additions.

References