Praisonai-Platform — CraftedSignal Threat Feedhttps://feed.craftedsignal.io/products/praisonai-platform/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 29 May 2026 22:51:38 +0000praisonai-platform: Cross-Workspace Label IDOR Vulnerabilityhttps://feed.craftedsignal.io/briefs/2026-05-praisonai-idor/Fri, 29 May 2026 22:51:38 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-praisonai-idor/Praison AI's praisonai-platform is vulnerable to an insecure direct object reference (IDOR) in the label endpoints (CVE-2026-47414), allowing cross-workspace label modification and information disclosure due to improper validation of label and issue IDs.The praisonai-platform is vulnerable to an Insecure Direct Object Reference (IDOR) vulnerability affecting label management endpoints. The vulnerability resides in src/praisonai-platform/praisonai_platform/services/label_service.py (lines 35-100) and src/praisonai-platform/praisonai_platform/api/routes/labels.py (lines 42-106), and is tracked as CVE-2026-47414. Specifically, the application fails to validate if the label_id and issue_id provided in API requests belong to the workspace associated with the request. Instead, it relies solely on require_workspace_member(workspace_id) for access control, without extending this validation to the data layer. This allows an attacker with valid credentials for one workspace to manipulate labels and issue associations in other workspaces. The affected package is pip/praisonai-platform with versions 0.1.2 and earlier.

Attack Chain

  1. The attacker registers a workspace W_attacker and obtains a valid authentication token for this workspace.
  2. The attacker identifies label_id (L_T) and issue_id (I_T) from a target workspace W_target. These IDs can be harvested from responses (e.g., list_labels for attacker’s workspace, or from issue records, activity feeds, exported dumps or error messages of the target workspace).
  3. The attacker crafts a PATCH request to /workspaces/W_attacker/labels/L_T with a malicious payload to rename or recolor the label. This bypasses access control because the application only checks the attacker’s workspace membership, not whether the label belongs to that workspace.
  4. The LabelService.update(L_T, ...) function is called, modifying the foreign label in the database without proper authorization, resulting in the label’s name and color being changed across the target workspace.
  5. The attacker can send a DELETE request to /workspaces/W_attacker/labels/L_T. The LabelService.delete(L_T) function is called, deleting the label from the database and potentially disrupting associations within the target workspace.
  6. The attacker crafts a POST request to /workspaces/W_attacker/issues/I_T/labels/L_T2 to attach a foreign label L_T2 to a foreign issue I_T.
  7. The LabelService.add_to_issue(I_T, L_T2) function is executed, writing the association row without validating that either the issue or label ID belong to the attacker’s workspace.
  8. The attacker now has the ability to rewrite and delete labels from other workspaces, attach arbitrary labels to issues in other workspaces, detach valid labels from issues in other workspaces, and read the current label set on any issue.

Impact

Successful exploitation of this IDOR vulnerability allows an attacker to rename and delete labels across workspaces, attach and detach labels on issues in unauthorized workspaces, and list label assignments for any issue. This can lead to data corruption, disruption of triage workflows due to incorrect labeling, and unauthorized information disclosure. The vulnerability has a CVSS score of 6.3 (sec-moderate) with high integrity damage, low confidentiality impact, and low availability impact. If combined with the IssueService IDOR, an attacker can tamper with both the issue and its labels, making detection even more difficult.

Recommendation

  • Apply the suggested fix provided in the advisory to src/praisonai-platform/praisonai_platform/services/label_service.py and src/praisonai-platform/praisonai_platform/api/routes/labels.py to ensure workspace validation for label and issue IDs.
  • Deploy the Sigma rule “Detect Cross-Workspace Label Modification via IDOR” to identify malicious PATCH requests attempting to modify labels using a workspace ID mismatch.
  • Deploy the Sigma rule “Detect Cross-Workspace Label Deletion via IDOR” to identify malicious DELETE requests attempting to delete labels using a workspace ID mismatch.
  • Upgrade pip/praisonai-platform to a version greater than 0.1.2 to mitigate CVE-2026-47414.
]]>highadvisoryidorvulnerabilityprivilege-escalationcollectionimpactcloudPraisonAI Platform Workspace Cross-Access Vulnerabilityhttps://feed.craftedsignal.io/briefs/2026-05-praisonai-workspace-bypass/Fri, 29 May 2026 22:39:55 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-praisonai-workspace-bypass/PraisonAI Platform's workspace-scoped REST routes have an object-level authorization flaw allowing authenticated users from one workspace to access, modify, and delete objects in another workspace by providing the victim object's global UUID.PraisonAI Platform is vulnerable to an object-level authorization flaw in its workspace-scoped REST routes. This vulnerability, disclosed on May 29, 2026, allows an authenticated user belonging to one workspace (e.g., workspace_attacker) to bypass intended access controls and interact with objects (agents, projects, issues, comments) belonging to another workspace (e.g., workspace_victim). The vulnerability stems from the service layer resolving target objects by global UUID without validating workspace membership after initial authorization, leading to a breach of workspace isolation. Successful exploitation enables unauthorized data access, modification, and deletion, impacting data confidentiality, integrity, and availability across different workspaces in the PraisonAI Platform.

Attack Chain

  1. Attacker creates an account on the PraisonAI Platform.
  2. Attacker logs into the PraisonAI Platform and creates a workspace named workspace_attacker.
  3. Victim creates an account on the PraisonAI Platform.
  4. Victim logs into the PraisonAI Platform and creates a workspace named workspace_victim.
  5. Victim creates an agent (or project, issue, or comment) within workspace_victim, obtaining the global UUID of the object (victim_agent_id).
  6. Attacker crafts a request to a workspace-scoped route (e.g., /api/v1/workspaces/{workspace_attacker}/agents/{victim_agent_id}) supplying their workspace ID and the victim’s object UUID.
  7. The server authenticates the attacker based on their membership in workspace_attacker, but retrieves the victim’s object from workspace_victim using the provided UUID without validating its workspace association.
  8. Attacker reads, modifies, or deletes the victim’s object, successfully breaching workspace isolation.

Impact

Successful exploitation of this vulnerability allows an attacker with access to any workspace to access, modify, and delete data belonging to other workspaces within the PraisonAI Platform. This could lead to unauthorized data breaches, data corruption, and denial of service for legitimate users. The number of affected users and organizations depends on the deployment size of the PraisonAI Platform.

Recommendation

  • Deploy the Sigma rule Detect PraisonAI Platform Cross-Workspace Agent Access to identify attempts to access agents in different workspaces based on workspace ID and agent ID.
  • Deploy the Sigma rule Detect PraisonAI Platform Cross-Workspace Project Access to identify attempts to access projects in different workspaces based on workspace ID and project ID.
  • Examine webserver logs for unusual patterns in requests to the agent, project, issue, and comment API routes to detect potential exploitation attempts (logsource: webserver).
]]>criticalthreatauthorizationprivilege-escalationworkspace-bypass