CVE-2026-63401 in Coop
Summary
by MITRE • 10/31/2026
Coop is an open source review and moderation tool from ROOST. Prior to 1.0.2, `addAccessibleQueuesForUser` and `removeAccessibleQueuesForUser` accepted arbitrary `queueId` and `userId` values without organization scoping. An authenticated user belonging to one organization and holding MRT queue-edit permission could grant or revoke another organization's users' access to manual review queues. The existing queue-edit permission check did not bind the supplied identifiers to the caller's organization. The attacker could not read the other organization's queues or jobs, so this issue did not disclose confidential data. This issue is fixed in version 1.0.2.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/31/2026
The vulnerability identified in Coop versions prior to 1.0.2 represents a critical failure in access control logic within an open-source review and moderation tool developed by ROOST. The core technical flaw lies in the improper implementation of authorization checks for two specific API endpoints: addAccessibleQueuesForUser and removeAccessibleQueuesForUser. These functions are designed to manage user permissions regarding manual review queues, which are central to the workflow of content moderation platforms. However, the underlying code failed to enforce organization-level scoping when validating these requests. Specifically, while the system correctly verified that an authenticated user possessed queue-edit permissions within their own organizational context, it neglected to bind the target userId and queueId parameters to that same organizational boundary. This architectural oversight created a horizontal privilege escalation vector where the scope of action was not restricted by the caller's tenant identity.
From a technical perspective, this flaw allows for unauthorized modification of access control lists across organizational boundaries in multi-tenant deployments. An attacker who has successfully authenticated and holds queue-edit permissions within their own organization can manipulate the permission structures of other organizations hosted on the same instance. By supplying arbitrary identifiers for both the target user and the target queue, the attacker can grant or revoke access to manual review queues belonging to different tenants. This behavior violates the fundamental principle of isolation in multi-tenant architectures, where data and configuration states must remain strictly segregated between distinct organizational units. The vulnerability is classified under CWE-269, which covers Improper Privilege Management, specifically highlighting the failure to enforce proper authorization checks for administrative functions relative to resource ownership.
The operational impact of this vulnerability is significant regarding system integrity and workflow disruption, although it does not directly compromise data confidentiality in terms of reading sensitive content. Because the attacker cannot read the contents of other organizations' queues or jobs, there is no direct risk of information disclosure or exfiltration of private review materials. However, the ability to alter access permissions allows an adversary to disrupt operational workflows by locking out legitimate moderators from their assigned queues or granting unauthorized users access to sensitive moderation interfaces. This can lead to service denial for specific teams and potentially allow malicious actors within other organizations to interfere with content moderation processes if they gain sufficient control over queue assignments. The lack of scoping means that the integrity of administrative configurations is compromised, undermining trust in the platform's security model for enterprise customers who rely on strict tenant isolation.
In terms of threat modeling, this vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, as it leverages legitimate credentials to perform unauthorized actions due to flawed logic rather than credential theft or exploitation of a separate authentication bypass. It also reflects aspects of lateral movement within the application layer, where an actor moves from their authorized scope into another tenant's administrative context. The mitigation for this issue was implemented in version 1.0.2 by enforcing strict organization scoping on both the queueId and userId parameters during permission validation. Administrators running older versions must upgrade immediately to patch this logic error. Additionally, organizations should audit their access control policies to ensure that all API endpoints performing state changes verify resource ownership against the authenticated user's tenant ID, thereby preventing similar cross-tenant manipulation in future updates or custom extensions of the software.