Plane EUVD-2026-92483

Requires a valid authenticated account that is an active ProjectMember of at least one project in the target workspace - any role suffices, including Guest - because the flawed SAFE_METHODS check only verified workspace-scoped project membership. The attacker must supply the project_id of a foreign private project in the same workspace (known or enumerated). Limiting factors: it is NOT exploitable by fully unauthenticated external users, cross-workspace access is not implied, and only versions prior to 1.4.0 are affected; impact is read-only disclosure of member roster PII with no write or availability effect.

This is a broken-access-control information disclosure (CWE-862) with a confirmed, source-code-level root cause: the SAFE_METHODS branch of ProjectMemberPermission checked only for active workspace-level project membership and never bound the check to view.project_id, while the view filtered only by the URL-supplied project_id. The provided CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N = 6.5) is internally consistent with the description - network-reachable REST endpoint, low attack complexity, and a low-privileged authenticated caller (explicitly including Guest role). No EPSS score, no CISA KEV listing, and no public exploit were provided in the intelligence; absence of those signals should not be read as low risk, but nothing here indicates active exploitation. The real-world severity is moderate and bounded: the impact is confined to confidentiality of project-member roster metadata (emails, names, display names, avatars, roles) rather than code execution, data modification, or credential exposure, so I assess the confidentiality impact as Low rather than High (see assessed vectors). Net: a legitimate but not urgent priority - a credible internal-threat/PII-leak issue in self-hosted deployments, not a high-CVSS-but-no-real-risk false alarm, yet also not an externally wormable RCE. Note the one data discrepancy: the technique tag labels this an 'Authentication Bypass,' but it is an authorization/access-control failure (CWE-862) - authentication is still required.

An authenticated workspace user with only Guest access to a single project enumerates or already knows the project_id of a different private project in the same workspace and issues GET /api/v1/workspaces/{slug}/projects/{project_id}/members/. The server returns that private project's complete member roster - emails, first/last names, display names, avatars, and roles - despite the caller never being a member. No public exploit was identified at time of analysis, but the vendor advisory and patch diff fully document the flaw, making reproduction trivial.