Plane EUVD-2026-92520

Exploitation requires an authenticated Plane account with any workspace role (ADMIN, MEMBER, or GUEST) on the target instance - the attacker does NOT need to be a member of the victim workspace. The specific vulnerable surfaces are DuplicateAssetEndpoint (source FileAsset fetched without workspace scoping), WorkspaceFileAssetEndpoint and the legacy FileAssetEndpoint (missing workspace authorization on read/create/modify/delete), and WorkspaceViewViewSet.retrieve (missing the authorization decorator its sibling actions use). The principal limiting factor is that valid authentication is required (no anonymous access), so the realistic threat model is a multi-workspace deployment with multiple tenants/users who should be isolated from one another; a single-workspace single-tenant instance has little exposure. Affected versions are all releases prior to 1.4.0 (cpe:2.3:a:makeplane:plane).

This is a genuine high-priority issue for organizations running self-hosted Plane, though the signals are a mix of confirmed and absent. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5) is internally consistent with the description: a network-reachable, low-complexity flaw requiring only a low-privilege authenticated account (any workspace member), no user interaction, and a changed scope because the authorization boundary crossed is the workspace tenant boundary - exactly the cross-tenant IDOR pattern of CWE-639. No EPSS probability was provided, so widespread-exploitation likelihood cannot be quantified. The vulnerability is NOT in CISA KEV and no exploit POC was supplied; the GitHub PR diff in the input is the vendor FIX, not weaponized exploit code, so it must not be conflated with active exploitation. The practical risk driver is that exploitation needs only a valid authenticated account on the instance, and multi-tenant/multi-workspace SaaS-style deployments are precisely where this becomes damaging - any member of one workspace can reach assets in workspaces they do not belong to. One point to verify: the description says attackers can 'read, create, modify, or delete assets' cross-workspace, which implies integrity impact arguably higher than the I:L in the published vector - treat the modify/delete capability as a meaningful integrity exposure, not merely low.

An authenticated user holding even a guest/member seat in one Plane workspace calls the DuplicateAssetEndpoint or the legacy/WorkspaceFileAssetEndpoint with an asset identifier belonging to a different workspace, and because the backend omits a workspace-membership check, the request succeeds. The attacker can thereby exfiltrate confidential files from unrelated tenants or tamper with/delete their assets, and separately read workspace-view data via WorkspaceViewViewSet.retrieve. No public exploit code was identified at time of analysis, but the fix commit reveals the exact missing authorization checks, lowering the bar to reproduce.