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}
- 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
- 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
- Attacker is a member of workspace
Wwith role "member". State: attacker holds JWT. - Attacker sends
PATCH /workspaces/WwithAuthorization: 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 entersupdate_workspace. require_workspace_member(W, attacker)passes.WorkspaceService.update(W, ...)writes the three fields. State: workspaceWnow has attacker-chosen name, description, and settings.- 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.
- 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
| Package | Vulnerable | Fixed 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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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