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.