dbcve.org
Improper Access ControlWeakness · CWE-284

CVE-2026-47399

HIGH · 8.8 CVSS v3.1 Published 2026-07-21
Patch available
A vendor patch is available. No clean upgrade release — apply the published patch.
See remediation →
94/100
Remediation priority · Urgent
Remotely reachable Zero-click Patch available 4 weeks old

Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.

NVD · unedited
PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Prior to version 0.1.4, the 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 layer later resolves the target object by global object ID only. It does not verify that the resolved object actually belongs to the workspace in the URL. As a result, a valid member of `workspace_attacker` can call a route under `/api/v1/workspaces/{workspace_attacker}/...` while supplying an object UUID from `workspace_victim`. The server authorizes the request based on membership in `workspace_attacker`, then fetches or mutates the victim object by global UUID. This breaks the platform's workspace isolation boundary. PraisonAI Platform version 0.1.4 patches the issue.

Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.

dbcve analysis · high confidence

A broken object-level authorization (BOLA) vulnerability in PraisonAI Platform allows authenticated users from one workspace to access, modify, or delete objects in another workspace by supplying the victim object's global UUID. The route layer correctly verifies the caller is a member of the workspace in the URL, but the service layer resolves objects by global UUID without validating that the object belongs to that workspace, breaking workspace isolation.

MitigationUpgrade to PraisonAI Platform version 0.1.4 which contains the patch for this authorization flaw.

Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.

CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.

From the vector
Attack vector
Network
Complexity
Low
Privileges
Low
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

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

Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.

dbcve checks

Work through these to decide whether this CVE applies to you.

  1. Identify installed PraisonAI Platform version
    Run 'pip show praisonai' or check the package version in your deployment environment (e.g., requirements.txt, pyproject.toml, or the installed package metadata)
    Affected if The installed version is any version prior to 0.1.4 (e.g., 0.1.3, 0.1.2, etc.)
  2. Confirm workspace functionality is in use
    Check if your PraisonAI deployment has multiple workspaces configured or if users are assigned to specific workspaces through the platform configuration
    Affected if Workspaces are enabled and users have access to more than one workspace
  3. Identify workspace-scoped REST API endpoints
    Review your API documentation or trace HTTP requests to identify REST routes that include a workspace identifier in the URL path (e.g., /api/workspaces/{workspace_id}/objects)
    Affected if Your deployment exposes REST API endpoints that take a workspace ID in the URL path for object operations
  4. Verify authorization logic in service layer
    Examine the service layer code responsible for object resolution (the code that fetches objects by UUID) to determine if it validates that the resolved object belongs to the workspace specified in the request
    Affected if The service layer resolves objects by global UUID without checking object-workspace ownership before returning the object

You are affected if running PraisonAI Platform version below 0.1.4 and using workspace-scoped REST routes, where an authenticated user in one workspace could access objects from another workspace by supplying a cross-workspace UUID.

Generated from the published advisory. Verify against your own configuration.

Check your environment

Paste your version and any relevant configuration and it will be compared against the affected criteria above. Do not include secrets or credentials.

AI-assisted, checked against the advisory. Informational, not a guarantee.

Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.

dbcve · scoped
Patch available Apply the vendor patch
Vendor patch github.com →
Interim mitigation

Upgrade to PraisonAI Platform version 0.1.4 which contains the patch for this authorization flaw.

Recommended fix High confidence

0.1.4

  1. Confirm the currently installed PraisonAI Platform version using the package manager or application diagnostics
  2. Upgrade PraisonAI Platform to version 0.1.4 or later using the appropriate package manager (e.g., pip install praisonai==0.1.4 or equivalent)
  3. Verify the upgrade was successful by checking the installed version matches 0.1.4 or higher
  4. Test the workspace-scoped REST API endpoints (agents, projects, issues, comments) to confirm the authorization flaw is remediated and cross-workspace access is no longer possible

Generated from the published advisory — verify against the referenced sources before acting.

Have this fixed Scoped from the published advisory
  • Consultation3.0 h
  • Implementation6.0 h
  • Testing5.0 h
  • Review / QA2.0 h
16.0 hours of engineering $2,790
Get the patch applied

An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,464.

Scan for this in your stack

Free · runs locally
dbcve dependency scanner

Check whether your project pulls in CVE-2026-47399 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.

Get it on GitHub Scan in the browser

References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.

Primary sources

Practitioner notes

Contributed

Peer-ranked notes from engineers who’ve handled CVE-2026-47399 in production — separate from our analysis above.

No notes yet

Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.

What this is

A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.

What belongs here
  • Verified mitigations, workarounds, and config changes
  • Version or environment caveats, and links to real fixes
  • No weaponised exploit code, or anything meant to cause harm
  • No spam, self-promotion, credentials, or personal data