A workspace member can permanently delete any resource — projects, agents, issues, labels, issue dependencies, and issue-label attachments — created by the workspace owner or other members. All six content DELETE endpoints enforce workspace membership but perform no ownership or role check. A single malicious or compromised member account can wipe an entire workspace's content irreversibly.
This is the familiar default-secret shape — a hardcoded fallback used to sign authentication tokens — with the additional twist that this one has a guard the author intended to catch the misconfiguration but whose polarity is wrong. Every route in praisonai_platform.api.app:create_app is authenticated via Bearer JWT, and every Bearer JWT is signed and verified with the public default secret. An unauthenticated network-adjacent attacker mints a token carrying any user-id …
The issue create and update endpoints in praisonai-platform accept a project_id in the request body and persist it without validating that the project belongs to the URL workspace. A user who is a member of workspace W_B (and has no access to workspace W_A) can create issues that reference a project owned by W_A. Because ProjectService.get_stats() aggregates issues by project_id with no workspace constraint, those foreign issues are then counted …
Affected: praisonai-platform (PyPI) <= 0.1.4 — including 0.1.4, the version GHSA-3qg8-5g3r-79v5 declares as the patch; main HEAD 8acf77c531e624c46d3d61dcae37e9942e90972c is also affected. File src/praisonai-platform/praisonai_platform/services/auth_service.py CWE: CWE-1188 (Insecure Default Initialization) + CWE-798 (Use of Hard-coded Credentials) -> CWE-287 (Improper Authentication)
Type: Insecure Direct Object Reference. The agent CRUD endpoints (GET / PATCH / DELETE /workspaces/{workspace_id}/agents/{agent_id}) gate access on require_workspace_member(workspace_id) only, then resolve agent_id through AgentService.get(agent_id) which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace W1 can read, modify, or delete agents that belong to a different workspace W2 by guessing or harvesting an agent UUID and calling …/workspaces/W1/agents/<W2-agent-id>. File: src/praisonai-platform/praisonai_platform/services/agent_service.py, lines …
Type: Insecure Direct Object Reference. The project CRUD endpoints (GET / PATCH / DELETE /workspaces/{workspace_id}/projects/{project_id} and GET …/{project_id}/stats) gate access on require_workspace_member(workspace_id) only, then resolve project_id through ProjectService.get(project_id) / update(project_id, …) / delete(project_id) / get_stats(project_id). None of these calls thread workspace_id through to constrain the lookup. A user who is a member of any workspace W1 can read, modify, delete, or read stats for projects that belong to a different …
Type: Insecure Direct Object Reference. The issue CRUD endpoints (GET / PATCH / DELETE /workspaces/{workspace_id}/issues/{issue_id}) gate access on require_workspace_member(workspace_id) only, then resolve issue_id through IssueService.get(issue_id) which is a primary-key lookup with no workspace constraint. A user who is a member of any workspace W1 can read, modify, or delete issues that belong to a different workspace W2. File: src/praisonai-platform/praisonai_platform/services/issue_service.py, lines 72-156; route handlers at src/praisonai-platform/praisonai_platform/api/routes/issues.py, lines 82-137. Root cause: the …
Type: Insecure Direct Object Reference. The comment endpoints (POST /workspaces/{workspace_id}/issues/{issue_id}/comments and GET …/comments) gate access on require_workspace_member(workspace_id) only, then call CommentService.create(issue_id=issue_id, …) and CommentService.list_for_issue(issue_id) without verifying that issue_id belongs to workspace_id. A user who is a member of any workspace W1 can read every comment on, and post new comments to, any issue in any other workspace W2. File: src/praisonai-platform/praisonai_platform/api/routes/issues.py, lines 143-171; src/praisonai-platform/praisonai_platform/services/comment_service.py, lines 19-53. Root cause: the route extracts …
Type: Authorization bypass enabling workspace metadata + settings tampering. The PATCH /workspaces/{workspace_id} endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member"). Any member can rewrite the workspace's name, description, and the settings JSON blob. The settings field is a free-form JSON object — depending on which downstream code reads it, this becomes a configuration-injection primitive for any setting the platform exposes there. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 63-74; services/workspace_service.py's update() method. Root cause: …
Type: Authorization bypass enabling destructive action. The DELETE /workspaces/{workspace_id} endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member"). Any member of the workspace can issue a single DELETE to wipe the entire workspace, including every project, issue, comment, agent, label, and member record (cascading via the foreign-key relationships). There is no owner-role gate, no confirmation token, no soft-delete window, no recovery path. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 77-86; services/workspace_service.py's delete() method. Root cause: …
Type: Privilege escalation / cross-tenant member injection. The POST /workspaces/{workspace_id}/members endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member") and forwards the request body's user_id and role straight into MemberService.add(workspace_id, user_id, role), which has no caller-permission check. A user with the lowest workspace privilege can add any user (including a new attacker-controlled second account, or an existing account they want to grief) as owner of the workspace. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 92-101; …
Type: Authorization bypass enabling owner lockout. The DELETE /workspaces/{workspace_id}/members/{user_id} endpoint is gated only by require_workspace_member(workspace_id) (default min_role="member"). Any member can remove any other member, including the workspace owner, using a single DELETE. There is no caller-role check, no target-role check, no "cannot remove last owner" guard. File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 130-140; services/member_service.py, lines 71-78. Root cause: MemberService.remove(workspace_id, user_id) performs the deletion without any caller-permission check or owner-protection logic. The route accepts …
Type: Insecure Direct Object Reference. The GET /workspaces/{workspace_id}/issues/{issue_id}/activity endpoint is gated by require_workspace_member(workspace_id) and dispatches to ActivityService.list_for_issue(issue_id), which executes SELECT * FROM activity WHERE issue_id = :issue_id with no workspace constraint. A user who is a member of any workspace can read the full activity log of any issue across the entire multi-tenant deployment. File: src/praisonai-platform/praisonai_platform/api/routes/activity.py, lines 32-43; services/activity_service.py's list_for_issue method. Root cause: the route extracts workspace_id from the URL …
Type: Insecure Direct Object Reference. Five label endpoints — PATCH /workspaces/{workspace_id}/labels/{label_id}, DELETE …/labels/{label_id}, POST …/issues/{issue_id}/labels/{label_id}, DELETE …/issues/{issue_id}/labels/{label_id}, GET …/issues/{issue_id}/labels — gate access on require_workspace_member(workspace_id) only and pass URL-supplied label_id and issue_id straight through to LabelService without verifying either belongs to the workspace. File: src/praisonai-platform/praisonai_platform/services/label_service.py, lines 35-100; route handlers at src/praisonai-platform/praisonai_platform/api/routes/labels.py, lines 42-106. Root cause: identical pattern to the agent / issue / project / comment IDORs in this codebase: the …
Type: Insecure default cryptographic key. The JWT signing secret defaults to the hardcoded literal "dev-secret-change-me" when PLATFORM_JWT_SECRET is unset. A safety check exists but only fires when PLATFORM_ENV != "dev"; the default value of PLATFORM_ENV is "dev", so the check is silently bypassed in any deployment that does not explicitly opt out. The attacker reads the literal from this public source file, mints a JWT with arbitrary sub and email …
Type: Insecure Direct Object Reference. The dependency endpoints (POST/GET /workspaces/{workspace_id}/issues/{issue_id}/dependencies and DELETE …/dependencies/{dep_id}) gate access on require_workspace_member(workspace_id) only, then dispatch to DependencyService calls that take URL/body-supplied issue and dependency IDs without verifying any of them belong to the membership-checked workspace. Most damaging: create_dependency accepts body.depends_on_issue_id from the request body — that ID is checked against nothing — letting an attacker create a "blocks" or "related" link between any two issues …
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 …
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 …
PraisonAI Platform's workspace-scoped REST routes contain a systemic object-level authorization flaw that allows an authenticated user from one workspace to access, modify, and delete objects belonging to another workspace by supplying the victim object's global UUID. The affected pattern appears in workspace-scoped routes such as agents, projects, issues, and comments. The route layer verifies that the caller is a member of the workspace_id provided in the URL, but the service …
The Platform server exposes resources under /api/v1/workspaces/{workspace_id}/… and protects them with a require_workspace_member(workspace_id) FastAPI dependency. The dependency only checks that the caller is a member of the workspace_id in the URL prefix. The route handlers then look up the inner resource (agent_id, issue_id, project_id, label_id, comment_id, dependency_id) by primary key alone. The resource's own workspace_id is never compared to the URL's workspace_id. A user can therefore put their own workspace …
The PraisonAI Platform API has two authorization failures that together break workspace isolation. The service layer for issues and projects performs global primary-key lookups without checking workspace ownership, so any authenticated user can read, modify, and delete resources in any workspace just by swapping UUIDs in their API requests. On top of that, every member management endpoint (add, update role, remove) only requires min_role="member", which lets any workspace member promote …