https://feed.craftedsignal.io/products/praisonai-platform--0.1.2/Trending threats, MITRE ATT&CK coverage, and detection metadata. Fed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioFri, 29 May 2026 22:57:51 +0000https://feed.craftedsignal.io/briefs/2026-05-praisonai-platform-takeover/Fri, 29 May 2026 22:57:51 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-praisonai-platform-takeover/An authorization bypass vulnerability exists in praisonai-platform where any member can remove any other member, including the workspace owner, due to missing role checks and owner protection logic, allowing an attacker to lock the legitimate owner out of their own workspace, leading to a permanent denial-of-service and potential workspace takeover (CVE-2026-47409).An authorization bypass vulnerability exists in the praisonai-platform version 0.1.2 and earlier. The vulnerability resides in the DELETE /workspaces/{workspace_id}/members/{user_id} endpoint. Due to insufficient access controls, any member of a workspace, regardless of their role, can remove any other member, including the workspace owner. This is because the endpoint is only gated by require_workspace_member(workspace_id) with a default min_role="member". There is no caller-role check, no target-role check, and no protection against removing the last owner. This lack of proper authorization checks allows a malicious member to lock out the legitimate owner and potentially take over the workspace.

Attack Chain

1. Attacker becomes a member of workspace W with the “member” role.
2. Attacker enumerates members of workspace W via GET /workspaces/W/members to discover the workspace owner’s user_id (O_id).
3. Attacker sends a DELETE /workspaces/W/members/O_id request with their valid JWT.
4. The require_workspace_member(W, attacker) check passes, as the attacker is a member of the workspace.
5. MemberService.remove(W, O_id) is called, which removes the owner’s member record from the database.
6. The owner attempts to access workspace resources, such as GET /workspaces/W/..., but require_workspace_member(W, O_id) now fails, resulting in a 403 error.
7. The legitimate owner is locked out of their own workspace.
8. The attacker can potentially combine this with other vulnerabilities (e.g., update_member_role, delete_workspace) to promote themselves to owner and/or completely wipe the workspace, further exacerbating the impact.

Impact

Successful exploitation of this vulnerability allows any member of a workspace to remove any other member, including the workspace owner. This leads to a permanent denial-of-service for the legitimate owner, as they are locked out of their own workspace. An attacker can potentially gain full control of the workspace and its resources. This vulnerability is rated as sec-high, with a CVSS score of 8.1. Version 0.1.2 and earlier are affected.

Recommendation

• Apply the patch suggested in the advisory, specifically modifying src/praisonai-platform/praisonai_platform/api/routes/workspaces.py to include stricter role checks and owner protection logic.
• Implement a detection rule to identify unauthorized attempts to remove workspace owners, focusing on webserver logs and the DELETE /workspaces/{workspace_id}/members/{user_id} endpoint (see Sigma rule below).
• Review and harden other workspace-mutation endpoints to ensure proper authorization checks, as the advisory mentions similar vulnerabilities in companion endpoints.

]]>highadvisoryauthorizationprivilege-escalationdenial-of-servicehttps://feed.craftedsignal.io/briefs/2026-05-praisonai-idor-privesc/Fri, 29 May 2026 22:35:47 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-05-praisonai-idor-privesc/PraisonAI Platform is vulnerable to cross-workspace IDOR and member-role privilege escalation, allowing unauthorized users to read, update, or delete resources across workspaces, escalate privileges, and potentially take over accounts and workspaces due to insufficient access controls and role enforcement.PraisonAI Platform is susceptible to critical vulnerabilities stemming from insufficient access controls and role enforcement. The platform exposes resources under /api/v1/workspaces/{workspace_id}/..., intending to protect them with a require_workspace_member(workspace_id) FastAPI dependency. However, this dependency only validates the workspace_id in the URL prefix, neglecting to verify the resource’s own workspace_id. This oversight enables a malicious actor to manipulate the URL, accessing resources across different workspaces. Furthermore, member-management routes lack proper role enforcement, allowing basic members to elevate their privileges to admin or owner. Open registration without email verification at /api/v1/auth/register and a default server bind to 0.0.0.0:8000 further exacerbate the risk. Successful exploitation allows attackers to read, update, or delete resources across workspaces, escalate privileges, and potentially take over accounts and workspaces. The vulnerability affects praisonai-platform versions 0.1.2 and earlier.

Attack Chain

1. An attacker registers an account via the open /api/v1/auth/register endpoint to obtain a valid bearer token.
2. The attacker identifies a target workspace ID and a resource ID (agent, issue, project, etc.) within that workspace.
3. The attacker crafts a request to /api/v1/workspaces/{attacker_workspace_id}/{resource_type}/{target_resource_id}, substituting {attacker_workspace_id} with their own workspace ID and {target_resource_id} with the target resource ID.
4. The require_workspace_member dependency checks if the attacker is a member of the attacker’s workspace, which passes.
5. The service layer retrieves the target resource based solely on the target_resource_id, bypassing workspace context validation.
6. The attacker reads, modifies, or deletes the cross-tenant resource. For example, PATCH /api/v1/workspaces/{attacker_workspace_id}/agents/{target_agent_id} modifies the target agent’s instructions.
7. A low-privileged member uses the PATCH /{workspace_id}/members/{user_id} route to promote themself to admin due to missing role checks.
8. The attacker deletes the original owner and assumes full control of the workspace.

Impact

Successful exploitation of these vulnerabilities can have severe consequences. Any registered user can read every agent, issue, project, label, comment, and dependency across all workspaces. Sensitive information such as API keys and connection strings stored within agent.instructions and agent.runtime_config fields are exposed. Malicious actors can rewrite agent.instructions to exfiltrate conversations or manipulate behavior. Additionally, attackers can reassign issues, edit project metadata, and delete critical resources, leading to data loss and service disruption. Basic members can escalate their privileges to admin, evict the owner, and seize control of workspaces. The default deployment configuration exposes the platform to network-based attacks, amplifying the impact of the vulnerability.

Recommendation

• Apply the suggested fix outlined in the advisory to re-scope every nested-resource lookup to the URL workspace to prevent cross-workspace IDOR vulnerabilities.
• Implement explicit min_role arguments on member-management routes to enforce role-based access control and prevent unauthorized privilege escalation.
• Monitor web server logs for suspicious requests to /api/v1/workspaces/{workspace_id}/agents/{agent_id} and other nested-resource routes using the provided Sigma rules.
• Deploy the Sigma rule detecting privilege escalation attempts via the PATCH /{workspace_id}/members/{user_id} route.
• Block registration from untrusted networks until email verification is implemented.

]]>criticalthreatidorprivilege-escalationcross-tenant-accessfastapi