Skip to main content
VulnerabilityPublished Updated

CVE-2026-48169: MervinPraison praisonai-platform · Insecure Direct Object Reference

Affects MervinPraison praisonai-platformSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 8.8 High : upgrade to 0.1.4 soon.

Data as of 5 Nov 2026, 00:01 UTC

CVSS 3.1 base score
8.8High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 38% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 0.1.4
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 7 Aug 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 5 Nov 2026.

What to do

Upgrade praisonai-platform and mervinpraison/praisonai-platform to 0.1.4.

Affected software

ProductAffectedFixed in
MervinPraisonpraisonai-platformAffected
  • <0.1.4
Fixed in
  • 0.1.4
GitHubmervinpraison/praisonai-platformpkg:github/mervinpraison/praisonai-platformOther threatsAffected
  • <0.1.4
Fixed in
  • 0.1.4

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade to PraisonAI Platform API version 0.1.4 or later, which patches these authorization bypass issues. No other mitigation is indicated as the fix addresses the root cause in the service layer authorization logic.

Description

PraisonAI is a multi-agent teams system. Versions prior to 0.1.4 of the PraisonAI Platform API have 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 themselves to owner and kick out the original owner. A low-privilege member of one workspace can steal data from every other workspace and take over any workspace they belong to. Both issues come from the same gap: the route layer pulls `workspace_id` from the URL and verifies membership, but the service layer ignores the workspace scope for resource lookups and ignores the caller's role level for member operations. The `require_workspace_member()` dependency does its job correctly. The problem is that the service layer doesn't use the information it provides. Version 0.1.4 of the PraisonAI Platform API patch the issue.

References

Community reviews

Loading reviews…