Skip to content

GHSA-rcmc-q9rj-4wmq CVE-2026-47411 PYSEC-2026-2937

praisonai-platform: Any workspace member can rewrite workspace name, description, and settings via PATCH /workspaces/{id}

Medium PyPI
Severity
6.5 / 10
Medium · CVSS 3.1
Exploit chance (EPSS)
0.34%
Chance of exploitation in the next 30 days. Higher than 26.89% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-269 Improper Privilege Management
CWE-862 Missing Authorization
Fix
0.1.4
Upgrade praisonai-platform to this version or later

Description

Summary

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: Depends(require_workspace_member) resolves to default min_role="member". WorkspaceService.update(workspace_id, name, description, settings) writes the new fields to the workspace row without any caller-permission check. The role hierarchy (MemberService.has_role) is never consulted.

Affected Code

File: src/praisonai-platform/praisonai_platform/api/routes/workspaces.py, lines 63-74.

@router.patch("/{workspace_id}", response_model=WorkspaceResponse)
async def update_workspace(
    workspace_id: str,
    body: WorkspaceUpdate,
    user: AuthIdentity = Depends(require_workspace_member),         # <-- BUG: defaults to min_role="member"
    session: AsyncSession = Depends(get_db),
):
    ws_svc = WorkspaceService(session)
    ws = await ws_svc.update(workspace_id, body.name, body.description, body.settings)  # <-- writes any value
    if ws is None:
        raise HTTPException(status_code=404, detail="Workspace not found")
    return WorkspaceResponse.model_validate(ws)

Why it's wrong: workspace name and settings are owner-tier fields. Renaming the workspace to a profanity is a low-impact griefing vector; rewriting the JSON settings blob is potentially a much higher-impact configuration injection (depending on what fields downstream code reads from settings, the attacker may flip feature flags, redirect webhook URLs, change LLM provider keys for shared configs, disable audit logging, etc.). The require_workspace_member(min_role) parameter is implemented and unused. This endpoint should require owner.

Exploit Chain

  1. Attacker is a member of workspace W with role "member". State: attacker holds JWT.
  2. Attacker sends PATCH /workspaces/W with Authorization: Bearer <attacker_jwt> and body {"name": "Compromised", "description": "Owned by attacker", "settings": {"allow_public_invite": true, "ai_provider_url": "https://attacker.example/v1"}}. State: control flow enters update_workspace.
  3. require_workspace_member(W, attacker) passes. WorkspaceService.update(W, ...) writes the three fields. State: workspace W now has attacker-chosen name, description, and settings.
  4. The settings JSON is read by any downstream code that consults workspace settings (LLM proxying, invite flows, webhook routing). If the deployment uses settings-keyed configuration overrides, those overrides now point at attacker-controlled endpoints.
  5. Final state: with one member-level token plus one PATCH, the attacker rewrites the workspace's metadata and settings, with effects ranging from cosmetic (rename) to substantive (settings-keyed config injection).

Security Impact

Severity: sec-moderate. CVSS 6.5: network attack, low complexity, low privileges, no user interaction, scope unchanged, no confidentiality directly (though settings rewrites may enable indirect data exfiltration via attacker-pointed integration URLs), high integrity, no availability claim. Attacker capability: rewrite any workspace's name, description, and settings JSON. The actual blast radius depends on what fields the deployment reads from settings — but that field is documented as a free-form JSON blob, so any future configuration the platform adds there becomes attacker-tunable. Preconditions: praisonai-platform is deployed multi-tenant; attacker has any membership token in the target workspace. Differential: source-inspection-verified. With the suggested fix below, member-tier tokens fail the gate and the metadata rewrite is rejected with 403.

Suggested Fix

--- a/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
+++ b/src/praisonai-platform/praisonai_platform/api/routes/workspaces.py
@@ -63,11 +63,11 @@
 @router.patch("/{workspace_id}", response_model=WorkspaceResponse)
 async def update_workspace(
     workspace_id: str,
     body: WorkspaceUpdate,
-    user: AuthIdentity = Depends(require_workspace_member),
+    user: AuthIdentity = Depends(_require_workspace_owner),  # see member-update-role advisory for helper
     session: AsyncSession = Depends(get_db),
 ):
     ws_svc = WorkspaceService(session)
     ws = await ws_svc.update(workspace_id, body.name, body.description, body.settings)
     if ws is None:
         raise HTTPException(status_code=404, detail="Workspace not found")
     return WorkspaceResponse.model_validate(ws)

Defence-in-depth: validate the keys allowed in body.settings against an allowlist so the field cannot become an arbitrary config-injection primitive even for owners. The four companion workspace-mutation endpoints (add_member, update_member_role, remove_member, delete_workspace) exhibit the same default-min-role gap and are filed as their own advisories.

Affected versions

PyPI

PackageVulnerableFixed in
praisonai-platform
< 0.1.4
0.1.4

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

praisonai-platform PyPI → 0.1.4

pip
pip install --upgrade "praisonai-platform>=0.1.4"
poetry
poetry add "praisonai-platform>=0.1.4"
uv
uv add "praisonai-platform>=0.1.4"

Severity breakdown

CVSS 3.1 6.5

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

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Weakness

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 to prevent it
  • Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
  • Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
  • Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.

CWE-862: Missing Authorization

The product does not perform an authorization check when an actor attempts to access a resource or perform an action.

How to prevent it
  • Architecture and Design: Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • Architecture and Design: Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
  • Architecture and Design: Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, consider using authorization frameworks such as the JAAS Authorization Framework [REF-233] and the OWASP ESAPI Access Control feature [REF-45].
  • Architecture and Design: For web applications, make sure that the access control mechanism is enforced correctly at the server side on every page. Users should not be able to access any unauthorized functionality or information by simply requesting direct access to that page. One way to do this is to ensure that all pages containing sensitive information are not cached, and that all such pages restrict access to requests that are accompanied by an active and authenticated session token associated with a user who has the required permissions to access that page.
  • System Configuration, Installation: Use the access control capabilities of your operating system and server environment and define your access control lists accordingly. Use a "default deny" policy when defining these ACLs.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-xxgv-vgvj-qvxh
PraisonAI: Platform members can rewrite shared labels and owner issue labels without owner/admin authorization
High Also affects praisonai-platform
GHSA-c78w-2q4r-68r7
PraisonAI: Platform member PATCH routes allow owner resource rewrites and project lead reassignment delete bypass
High Also affects praisonai-platform
GHSA-mxmx-rh57-jx58
PraisonAI: Platform members can delete owner issue dependencies through member-owned related issues
High Also affects praisonai-platform
GHSA-2fjj-qqg8-fg7x
praisonai-platform: Authorization Bypass Through User-Controlled Key
Medium Also affects praisonai-platform
GHSA-cwj8-7gp2-ggcw
praisonai-platform: default JWT signing secret 'dev-secret-change-me' enables token forgery
Critical Also affects praisonai-platform
GHSA-f38v-77qj-h4jq
praisonai-platform 0.1.4 still boots on the hardcoded JWT secret dev-secret-change-me (default-open production guard)
Critical Also affects praisonai-platform
GHSA-rh39-9c67-59mh
PraisonAI: Missing ownership check on DELETE endpoints allows members to delete others' content in Platform API
High Also affects praisonai-platform
GHSA-7p8g-6c6g-h9w7
praisonai-platform: Agent endpoints accept any agent_id without workspace ownership check, cross-workspace read/update/delete IDOR
High Also affects praisonai-platform
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor