CVE-2026-47416: praisonai-platform Any Workspace Member Can Promote Vulnerability

CRITICAL
Advisory Identifier: GHSA-c2m8-4gcg-v22g
CVSS 9.6
CWE-269 CWE-862
Published
Advisory Summary

CVE-2026-47416 is a CRITICAL (CVSS 9.6) any workspace member can promote vulnerability (CWE-269: Improper Privilege Management) affecting praisonai-platform libraries in the PyPI ecosystem. The issue involves any workspace member can promote themselves or others to owner via patch /workspaces/{id}/members/{user_id}. Remediation is available by upgrading affected packages to version 0.1.4.

CVE-2026-47416 at a Glance

CVE Identifier CVE-2026-47416
GHSA Identifier GHSA-c2m8-4gcg-v22g
Severity CRITICAL
CVSS v3.1 Base Score 9.6
CWE Classification CWE-269: Improper Privilege Management
Affected Product praisonai-platform
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 9.6

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-47416

To remediate this vulnerability, upgrade all affected praisonai-platform dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

praisonai-platform fixed: 0.1.4
pip install praisonai-platform>=0.1.4
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show praisonai-platform

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-47416, inspect your installed packages using pip:

pip show praisonai-platform

Analyze the terminal output to locate any version of praisonai-platform in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.1.4), your application is affected.

Note: The pip show praisonai-platform command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-269: Improper Privilege Management, where the product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. In praisonai-platform, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary **Type:** Vertical privilege escalation. The `PATCH /workspaces/{workspace_id}/members/{user_id}` endpoint is gated by `require_workspace_member(workspace_id)`, which defaults to `min_role="member"` and is never overridden by the route. The handler then calls `MemberService.update_role(workspace_id, user_id, body.role)` which sets the target member's role to whatever the request body specifies, with no check that the caller has owner-or-admin privilege, no check that the new role is not higher than the caller's own, and no check that the caller is not silently promoting themselves. **File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127; `services/member_service.py`, lines 55-69; `api/deps.py`, lines 54-73. **Root cause:** `require_workspace_member` exists with a `min_role` parameter (deps.py:58) but FastAPI's `Depends(require_workspace_member)` cannot pass arguments, so every route uses the default `"member"`. The route then passes the URL-supplied `user_id` and the body-supplied `role` directly to `MemberService.update_role`, which contains zero permission checks: it loads the member by composite key and assigns `member.role = new_role`. A user with the lowest possible privilege ("member") thus sets their own role to "owner" with one HTTP PATCH, completing a member-to-owner privilege escalation in a single request. ## Affected Code **File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127. ```python @router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse) async def update_member_role( workspace_id: str, user_id: str, body: MemberUpdate, user: AuthIdentity = Depends(require_workspace_member), # <-- BUG: defaults to min_role="member"; no role gate session: AsyncSession = Depends(get_db), ): member_svc = MemberService(session) member = await member_svc.update_role(workspace_id, user_id, body.role) # <-- writes any role to any member if member is None: raise HTTPException(status_code=404, detail="Member not found") return MemberResponse.model_validate(member) ``` **File 2:** `src/praisonai-platform/praisonai_platform/services/member_service.py`, lines 55-69. ```python async def update_role( self, workspace_id: str, user_id: str, new_role: str, ) -> Optional[Member]: """Update a member's role.""" if new_role not in VALID_ROLES: # only validates the *value*, not the *caller's right* raise ValueError(f"Invalid role: {new_role}. Must be one of {VALID_ROLES}") member = await self.get(workspace_id, user_id) if member is None: return None member.role = new_role # <-- BUG: no caller-role check, no target-vs-caller hierarchy check await self._session.flush() return member ``` **File 3:** `src/praisonai-platform/praisonai_platform/api/deps.py`, lines 54-73. ```python async def require_workspace_member( workspace_id: str, user: AuthIdentity = Depends(get_current_user), session: AsyncSession = Depends(get_db), min_role: str = "member", # <-- default that no route overrides ) -> AuthIdentity: member_svc = MemberService(session) has = await member_svc.has_role(workspace_id, user.id, min_role) if not has: raise HTTPException(status_code=403, detail="Not a member of this workspace or insufficient role") user.workspace_id = workspace_id return user ``` **Why it's wrong:** `require_workspace_member` was clearly designed to be tunable per-route — the `min_role` parameter is right there — but `Depends(require_workspace_member)` in FastAPI cannot pass arguments to a dependency, so every route resolves to the default `"member"`. The author's intent is also evident in `MemberService.has_role` (member_service.py:80-96), which implements an `owner > admin > member` hierarchy that this endpoint should be enforcing. The endpoint uses none of it. The `VALID_ROLES = {"owner", "admin", "member"}` enum check (member_service.py:62) only validates the *new role string is recognised*, not that the *caller has the right to assign it*. As a result, a member can write `{"role": "owner"}` to their own membership row and become owner in one PATCH. ## Exploit Chain 1. Attacker registers an account and joins (or is invited to) any workspace `W` as a "member" (the lowest privilege tier — typically anyone can be added by an owner during onboarding, or self-joins via an invite link). State: attacker has a JWT, is a `Member(workspace_id=W, user_id=attacker, role="member")`. 2. Attacker sends `PATCH /workspaces/W/members/<attacker_user_id>` with `Authorization: Bearer <attacker_jwt>` and body `{"role": "owner"}`. State: control flow enters `update_member_role`. 3. `require_workspace_member(W, attacker)` runs. Its default `min_role="member"` is satisfied because the attacker is a member. The dependency returns the attacker's identity. State: route handler proceeds with no further role gate. 4. `MemberService.update_role(W, attacker, "owner")` runs. `VALID_ROLES` accepts `"owner"`. `self.get(W, attacker)` returns the attacker's existing member row. The next line, `member.role = "owner"`, mutates the attacker's role in place. `await self._session.flush()` commits. State: attacker is now `Member(workspace_id=W, user_id=attacker, role="owner")`. 5. Attacker re-issues `GET /auth/me` (or any owner-gated endpoint) and is now treated as workspace owner. State: full administrative control of the workspace, including the ability to add/remove members, change settings, delete the workspace, and exfiltrate everything via the agent/issue/project/comment IDORs that were filed as separate advisories. 6. Final state: starting from the lowest workspace privilege, the attacker holds owner of the workspace within one HTTP request. The same primitive also lets the attacker DEMOTE the legitimate owner by sending `PATCH /workspaces/W/members/<owner_user_id>` with `{"role": "member"}` — owner lockout in two requests total. ## Security Impact **Severity:** sec-critical. CVSS 9.1: network attack, low complexity, low privileges (the lowest tier on the platform), no user interaction, scope changed (the privilege boundary the attacker crosses is the workspace owner, a different security principal), high confidentiality and integrity (full workspace control), no availability claim (the attacker can also DELETE the workspace via the companion `delete_workspace` advisory, but that is a separate finding). **Attacker capability:** with one workspace-member token plus one PATCH request, the attacker becomes workspace owner. From there: add/remove any user as owner, change every workspace setting (including the `settings` JSON blob), demote the legitimate owner to "member", or chain into the companion `delete_workspace` advisory to wipe the workspace entirely. In multi-tenant SaaS deployments where any signup yields a member-level account in some default workspace, this is effectively pre-auth. **Preconditions:** `praisonai-platform` is deployed multi-tenant (more than one workspace exists OR the deployment grants member access on signup); the attacker has any membership token in the target workspace. **Differential:** source-inspection-verified end-to-end. The asymmetry between `require_workspace_member`'s `min_role` parameter (which exists, defaults to "member", and is never overridden) and `MemberService.has_role`'s clearly tiered `owner > admin > member` hierarchy (which exists but is never invoked with anything but the default) is the smoking gun. With the suggested fix below, the route resolves with `min_role="owner"`, the attacker's member-level token fails the gate at the dependency, and the privilege escalation never reaches the service layer. ## Suggested Fix The fix has two parts. First, the route must resolve `require_workspace_member` with `min_role="owner"` (or at least `"admin"`). Second, `MemberService.update_role` should refuse to set a target's role higher than the caller's own role, so that an admin cannot accidentally produce another owner. ```diff --- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py +++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py @@ -115,11 +115,16 @@ +def _require_owner(workspace_id: str, user, session): + return require_workspace_member(workspace_id, user, session, min_role="owner") + @router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse) async def update_member_role( workspace_id: str, user_id: str, body: MemberUpdate, - user: AuthIdentity = Depends(require_workspace_member), + user: AuthIdentity = Depends(_require_owner), session: AsyncSession = Depends(get_db), ): member_svc = MemberService(session) + if not await member_svc.has_role(workspace_id, user.id, "owner"): + raise HTTPException(status_code=403, detail="Only owners can change member roles") member = await member_svc.update_role(workspace_id, user_id, body.role) ``` Defence-in-depth in the service layer: ```diff --- a/src/praisonai-platform/praisonai_platform/services/member_service.py +++ b/src/praisonai-platform/praisonai_platform/services/member_service.py @@ -55,7 +55,7 @@ - async def update_role(self, workspace_id: str, user_id: str, new_role: str) -> Optional[Member]: + async def update_role(self, workspace_id: str, caller_id: str, user_id: str, new_role: str) -> Optional[Member]: """Update a member's role.""" + if not await self.has_role(workspace_id, caller_id, "owner"): + raise PermissionError("Only owners can update member roles") if new_role not in VALID_ROLES: raise ValueError(...) ``` The companion endpoints `add_member`, `remove_member`, `delete_workspace`, and `update_workspace` exhibit the same `Depends(require_workspace_member)` default-min-role pattern and are filed as their own advisories so each gets a separate CVE.

CVE-2026-47416 Affected praisonai-platform Versions

1 component(s)
Fixed Versions:
0.1.4
Product / Package Ecosystem Affected Versions Fixed Version
praisonai-platform
PyPI
< 0.1.4
0.1.4

References

Frequently Asked Questions

What is CVE-2026-47416?
CVE-2026-47416 is a security vulnerability in praisonai-platform involving Any workspace member can promote themselves or others to owner via PATCH /workspaces/{id}/members/{user_id} under CWE-269: Improper Privilege Management.
Which praisonai-platform versions are affected?
Affected versions include releases prior to 0.1.4 across affected packages: praisonai-platform.
What version fixes CVE-2026-47416?
Upgrading to 0.1.4 (or the latest patched release for your respective branch) resolves the vulnerability.
Is praisonai-platform affected?
Yes, praisonai-platform is affected in releases prior to 0.1.4. Upgrade your dependency to 0.1.4 or later.
What is the CVSS score of CVE-2026-47416?
CVE-2026-47416 has a CVSS v3.1 base score of 9.6 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N.
What CWE is associated with CVE-2026-47416?
CVE-2026-47416 is classified under CWE-269: Improper Privilege Management (The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.).
How can I check PyPI dependencies for CVE-2026-47416?
Run the dependency tree command: 'pip show praisonai-platform'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-c2m8-4gcg-v22g",
  "modified" : "2026-05-29T23:01:59Z",
  "published" : "2026-05-29T23:01:59Z",
  "aliases" : [ "CVE-2026-47416" ],
  "summary" : "praisonai-platform: Any workspace member can promote themselves or others to owner via PATCH /workspaces/{id}/members/{user_id}",
  "details" : "## Summary\n\n**Type:** Vertical privilege escalation. The `PATCH /workspaces/{workspace_id}/members/{user_id}` endpoint is gated by `require_workspace_member(workspace_id)`, which defaults to `min_role=\"member\"` and is never overridden by the route. The handler then calls `MemberService.update_role(workspace_id, user_id, body.role)` which sets the target member's role to whatever the request body specifies, with no check that the caller has owner-or-admin privilege, no check that the new role is not higher than the caller's own, and no check that the caller is not silently promoting themselves.\n**File:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127; `services/member_service.py`, lines 55-69; `api/deps.py`, lines 54-73.\n**Root cause:** `require_workspace_member` exists with a `min_role` parameter (deps.py:58) but FastAPI's `Depends(require_workspace_member)` cannot pass arguments, so every route uses the default `\"member\"`. The route then passes the URL-supplied `user_id` and the body-supplied `role` directly to `MemberService.update_role`, which contains zero permission checks: it loads the member by composite key and assigns `member.role = new_role`. A user with the lowest possible privilege (\"member\") thus sets their own role to \"owner\" with one HTTP PATCH, completing a member-to-owner privilege escalation in a single request.\n\n## Affected Code\n\n**File 1:** `src/praisonai-platform/praisonai_platform/api/routes/workspaces.py`, lines 115-127.\n\n```python\n@router.patch(\"/{workspace_id}/members/{user_id}\", response_model=MemberResponse)\nasync def update_member_role(\n    workspace_id: str,\n    user_id: str,\n    body: MemberUpdate,\n    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role=\"member\"; no role gate\n    session: AsyncSession = Depends(get_db),\n):\n    member_svc = MemberService(session)\n    member = await member_svc.update_role(workspace_id, user_id, body.role)  # <-- writes any role to any member\n    if member is None:\n        raise HTTPException(status_code=404, detail=\"Member not found\")\n    return MemberResponse.model_validate(member)\n```\n\n**File 2:** `src/praisonai-platform/praisonai_platform/services/member_service.py`, lines 55-69.\n\n```python\nasync def update_role(\n    self,\n    workspace_id: str,\n    user_id: str,\n    new_role: str,\n) -> Optional[Member]:\n    \"\"\"Update a member's role.\"\"\"\n    if new_role not in VALID_ROLES:                                  # only validates the *value*, not the *caller's right*\n        raise ValueError(f\"Invalid role: {new_role}. Must be one of {VALID_ROLES}\")\n    member = await self.get(workspace_id, user_id)\n    if member is None:\n        return None\n    member.role = new_role                                           # <-- BUG: no caller-role check, no target-vs-caller hierarchy check\n    await self._session.flush()\n    return member\n```\n\n**File 3:** `src/praisonai-platform/praisonai_platform/api/deps.py`, lines 54-73.\n\n```python\nasync def require_workspace_member(\n    workspace_id: str,\n    user: AuthIdentity = Depends(get_current_user),\n    session: AsyncSession = Depends(get_db),\n    min_role: str = \"member\",                                        # <-- default that no route overrides\n) -> AuthIdentity:\n    member_svc = MemberService(session)\n    has = await member_svc.has_role(workspace_id, user.id, min_role)\n    if not has:\n        raise HTTPException(status_code=403, detail=\"Not a member of this workspace or insufficient role\")\n    user.workspace_id = workspace_id\n    return user\n```\n\n**Why it's wrong:** `require_workspace_member` was clearly designed to be tunable per-route — the `min_role` parameter is right there — but `Depends(require_workspace_member)` in FastAPI cannot pass arguments to a dependency, so every route resolves to the default `\"member\"`. The author's intent is also evident in `MemberService.has_role` (member_service.py:80-96), which implements an `owner > admin > member` hierarchy that this endpoint should be enforcing. The endpoint uses none of it. The `VALID_ROLES = {\"owner\", \"admin\", \"member\"}` enum check (member_service.py:62) only validates the *new role string is recognised*, not that the *caller has the right to assign it*. As a result, a member can write `{\"role\": \"owner\"}` to their own membership row and become owner in one PATCH.\n\n## Exploit Chain\n\n1. Attacker registers an account and joins (or is invited to) any workspace `W` as a \"member\" (the lowest privilege tier — typically anyone can be added by an owner during onboarding, or self-joins via an invite link). State: attacker has a JWT, is a `Member(workspace_id=W, user_id=attacker, role=\"member\")`.\n2. Attacker sends `PATCH /workspaces/W/members/<attacker_user_id>` with `Authorization: Bearer <attacker_jwt>` and body `{\"role\": \"owner\"}`. State: control flow enters `update_member_role`.\n3. `require_workspace_member(W, attacker)` runs. Its default `min_role=\"member\"` is satisfied because the attacker is a member. The dependency returns the attacker's identity. State: route handler proceeds with no further role gate.\n4. `MemberService.update_role(W, attacker, \"owner\")` runs. `VALID_ROLES` accepts `\"owner\"`. `self.get(W, attacker)` returns the attacker's existing member row. The next line, `member.role = \"owner\"`, mutates the attacker's role in place. `await self._session.flush()` commits. State: attacker is now `Member(workspace_id=W, user_id=attacker, role=\"owner\")`.\n5. Attacker re-issues `GET /auth/me` (or any owner-gated endpoint) and is now treated as workspace owner. State: full administrative control of the workspace, including the ability to add/remove members, change settings, delete the workspace, and exfiltrate everything via the agent/issue/project/comment IDORs that were filed as separate advisories.\n6. Final state: starting from the lowest workspace privilege, the attacker holds owner of the workspace within one HTTP request. The same primitive also lets the attacker DEMOTE the legitimate owner by sending `PATCH /workspaces/W/members/<owner_user_id>` with `{\"role\": \"member\"}` — owner lockout in two requests total.\n\n## Security Impact\n\n**Severity:** sec-critical. CVSS 9.1: network attack, low complexity, low privileges (the lowest tier on the platform), no user interaction, scope changed (the privilege boundary the attacker crosses is the workspace owner, a different security principal), high confidentiality and integrity (full workspace control), no availability claim (the attacker can also DELETE the workspace via the companion `delete_workspace` advisory, but that is a separate finding).\n**Attacker capability:** with one workspace-member token plus one PATCH request, the attacker becomes workspace owner. From there: add/remove any user as owner, change every workspace setting (including the `settings` JSON blob), demote the legitimate owner to \"member\", or chain into the companion `delete_workspace` advisory to wipe the workspace entirely. In multi-tenant SaaS deployments where any signup yields a member-level account in some default workspace, this is effectively pre-auth.\n**Preconditions:** `praisonai-platform` is deployed multi-tenant (more than one workspace exists OR the deployment grants member access on signup); the attacker has any membership token in the target workspace.\n**Differential:** source-inspection-verified end-to-end. The asymmetry between `require_workspace_member`'s `min_role` parameter (which exists, defaults to \"member\", and is never overridden) and `MemberService.has_role`'s clearly tiered `owner > admin > member` hierarchy (which exists but is never invoked with anything but the default) is the smoking gun. With the suggested fix below, the route resolves with `min_role=\"owner\"`, the attacker's member-level token fails the gate at the dependency, and the privilege escalation never reaches the service layer.\n\n## Suggested Fix\n\nThe fix has two parts. First, the route must resolve `require_workspace_member` with `min_role=\"owner\"` (or at least `\"admin\"`). Second, `MemberService.update_role` should refuse to set a target's role higher than the caller's own role, so that an admin cannot accidentally produce another owner.\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py\n+++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py\n@@ -115,11 +115,16 @@\n+def _require_owner(workspace_id: str, user, session):\n+    return require_workspace_member(workspace_id, user, session, min_role=\"owner\")\n+\n @router.patch(\"/{workspace_id}/members/{user_id}\", response_model=MemberResponse)\n async def update_member_role(\n     workspace_id: str,\n     user_id: str,\n     body: MemberUpdate,\n-    user: AuthIdentity = Depends(require_workspace_member),\n+    user: AuthIdentity = Depends(_require_owner),\n     session: AsyncSession = Depends(get_db),\n ):\n     member_svc = MemberService(session)\n+    if not await member_svc.has_role(workspace_id, user.id, \"owner\"):\n+        raise HTTPException(status_code=403, detail=\"Only owners can change member roles\")\n     member = await member_svc.update_role(workspace_id, user_id, body.role)\n```\n\nDefence-in-depth in the service layer:\n\n```diff\n--- a/src/praisonai-platform/praisonai_platform/services/member_service.py\n+++ b/src/praisonai-platform/praisonai_platform/services/member_service.py\n@@ -55,7 +55,7 @@\n-    async def update_role(self, workspace_id: str, user_id: str, new_role: str) -> Optional[Member]:\n+    async def update_role(self, workspace_id: str, caller_id: str, user_id: str, new_role: str) -> Optional[Member]:\n         \"\"\"Update a member's role.\"\"\"\n+        if not await self.has_role(workspace_id, caller_id, \"owner\"):\n+            raise PermissionError(\"Only owners can update member roles\")\n         if new_role not in VALID_ROLES:\n             raise ValueError(...)\n```\n\nThe companion endpoints `add_member`, `remove_member`, `delete_workspace`, and `update_workspace` exhibit the same `Depends(require_workspace_member)` default-min-role pattern and are filed as their own advisories so each gets a separate CVE.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "praisonai-platform"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.1.4"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.1.2"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-c2m8-4gcg-v22g"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/MervinPraison/PraisonAI"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-269", "CWE-862" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-29T23:01:59Z",
    "nvd_published_at" : null
  }
}