CVE-2026-47418 in praisonai-platforminfo

Summary

by MITRE • 07/21/2026

PraisonAI Platform is the platform layer for the PraisonAI multi-agent teams system. Versions prior to 0.1.4 have an 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 workspace `W2`. PraisonAI Platform version 0.1.4 patches the issue.

Be aware that VulDB is the high quality source for vulnerability data.

Analysis

by VulDB Data Team • 07/21/2026

The PraisonAI Platform vulnerability represents a critical Insecure Direct Object Reference (IDOR) flaw that undermines the system's access control mechanisms. This security weakness exists in versions prior to 0.1.4 and stems from improper authorization checks within the platform's RESTful API endpoints. The vulnerability specifically affects CRUD operations targeting workspace projects through endpoints such as GET, PATCH, DELETE requests directed at `/workspaces/{workspace_id}/projects/{project_id}` and statistics retrieval at `.../{project_id}/stats`. The fundamental flaw lies in the implementation where access control is initially validated only against workspace membership through the `require_workspace_member(workspace_id)` function, yet subsequent project operations fail to maintain this contextual constraint during object resolution.

The technical execution of this vulnerability occurs because the system's service layer methods do not propagate the original workspace context when performing project lookups. Specifically, calls to `ProjectService.get(project_id)`, `update(project_id, ...)`, `delete(project_id)`, and `get_stats(project_id)` operate independently of their originating workspace context, allowing unauthorized access to cross-workspace resources. This architectural gap creates a scenario where legitimate access control validation occurs at the initial endpoint level but fails to persist across subsequent service layer operations, effectively bypassing the intended multi-tenant isolation between workspaces.

The operational impact of this vulnerability extends beyond simple data exposure, creating significant risks for organizations utilizing PraisonAI's multi-agent team system. An authenticated user belonging to one workspace can arbitrarily access, modify, or delete projects owned by other workspaces within the same platform instance. This cross-tenant data leakage could result in unauthorized modification of critical project configurations, deletion of important work products, or retrieval of sensitive statistical information from competing teams. The implications are particularly severe in enterprise environments where multiple organizations might share the same PraisonAI Platform instance while maintaining strict data isolation requirements.

This vulnerability aligns with CWE-639 (Authorization Bypass Through User-Controlled Key) and maps to ATT&CK technique T1078.101 (Valid Accounts: Local Accounts) as it exploits legitimate user credentials to gain unauthorized access to resources outside their intended scope. The fix implemented in version 0.1.4 addresses this by ensuring that workspace context is properly maintained throughout the service layer operations, preventing cross-workspace object reference attacks. Organizations should immediately upgrade to version 0.1.4 or later and implement additional monitoring for unauthorized cross-workspace access patterns. Security teams should also review existing access logs for potential exploitation attempts and consider implementing additional perimeter controls to limit the blast radius of such vulnerabilities in shared platform environments.

Responsible

GitHub M

Reservation

05/19/2026

Disclosure

07/21/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you know our Splunk app?

Download it now for free!