Coop CVE-2026-63401

Requires an authenticated Coop user account in some organization that holds MRT (manual review tool) queue-edit permission; the attacker then invokes the addAccessibleQueuesForUser or removeAccessibleQueuesForUser GraphQL mutations with a queueId and userId referencing a different organization. The limiting factors are: a valid authenticated account plus the queue-edit permission are mandatory (PR:L, not unauthenticated); only Coop deployments running versions prior to 1.0.2 are affected; and impact is confined to tampering with cross-org queue-access assignments - the attacker cannot read the other org's queues or jobs, so there is no confidentiality exposure.

This is a genuine but moderate-priority cross-organization IDOR (CWE-639). The signals are largely consistent and point to a limited blast radius rather than an emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L) scores an authenticated, network-reachable, low-complexity flaw with no confidentiality impact and only low integrity/availability impact - matching the description's statement that the attacker cannot read another org's queues or jobs, only grant or revoke access. Note a scoring discrepancy: the input lists CVSS 5.3, while the GHSA advisory states Moderate / CVSS 6.9; both agree on 'moderate' severity but the exact number conflicts, so treat the band (medium) as the reliable signal, not the precise score. No EPSS probability is provided, there is no CISA KEV listing, and no public exploit is identified; the Decision label is 'this_month' (not act_now/emergency), reinforcing a planned-remediation posture rather than drop-everything urgency. The main realistic risk is operational disruption within multi-tenant Coop deployments (an attacker in one org tampering with another org's reviewer-to-queue assignments), which is meaningful for a moderation platform but does not expose confidential data. Overall: a real authorization defect worth patching this cycle, not a high-CVSS-but-illusory issue, yet clearly below critical given PR:L, no confidentiality loss, and no evidence of exploitation.

An authenticated user in Coop organization A who holds MRT queue-edit permission issues the addAccessibleQueuesForUser or removeAccessibleQueuesForUser GraphQL mutation, supplying a queueId and userId belonging to a different organization B. Because the pre-1.0.2 code did not bind those identifiers to the caller's org, the server grants or revokes org B users' access to org B's manual review queues. No verified public exploit exists, though the fixing PR/commit diff is public and reveals the missing org-scoping check.