Description

Plane is an open-source project management tool. Prior to 1.4.0, Plane's project update endpoint authorizes the caller against the workspace slug in the request URL but loads the target project globally by UUID without binding it to that workspace. An administrator of one workspace can modify a project in another workspace when the victim project UUID is known. This violates tenant isolation and permits unauthorized cross-workspace changes to project metadata and configuration. This issue is fixed in 1.4.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-10-05T17:17:11.943Z",
  "pubdate": "2026-10-05T17:17:11.943Z",
  "executiveSummary": "Plane, an open-source project management tool, contains an Insecure Direct Object Reference (IDOR) vulnerability prior to version 1.4.0 that leads to a critical failure in multi-tenant isolation.\nThe vulnerability allows an authenticated user, such as an administrator of a specific workspace, to perform unauthorized modifications to project configurations and metadata located within an entirely different workspace.\nThis authorization bypass occurs because the application performs validation against the workspace slug provided in the request URI while simultaneously resolving the target project entity globally using its UUID, ignoring the necessary relationship binding between the project and the workspace.\nAn attacker possessing the UUID of a target project in a foreign workspace can manipulate project settings, effectively crossing tenant boundaries.\nThe impact is significant, as it compromises the integrity of project data and violates the core security premise of logical tenant separation within the multi-tenant architecture.\nSuccessful exploitation requires the attacker to be an authenticated user within the system and to obtain the target project's unique identifier.",
  "technicalDetails": "The root cause of this vulnerability lies in a flawed authorization design within the project update endpoint. While the API correctly validates that the requester has administrative privileges over the workspace defined by the slug parameter in the URL, it fails to verify that the project UUID identified in the request body or path is actually associated with that specific workspace scope.\nIn the affected versions (prior to 1.4.0), the application logic retrieves the project object using a global lookup function that ignores context-aware scoping. By querying the database directly by UUID, the application retrieves the target object regardless of its parent workspace relationship. Once the object is retrieved, the application proceeds to apply updates to the project configuration without further validation of ownership or cross-tenant validity.\nThe attack flow follows a predictable pattern: 1) The attacker authenticates to their own authorized workspace to obtain a valid session token. 2) The attacker identifies or brute-forces the UUID of a project belonging to a victim workspace. 3) The attacker crafts a request to the project update endpoint, specifying their own workspace slug (to pass initial authorization checks) but referencing the victim's project UUID. 4) The server validates the attacker's administrative rights against their own workspace, proceeds to load the victim's project globally by UUID, and performs the requested modifications.\nThis vulnerability highlights a failure in the application's access control layer, specifically failing to implement 'scoped' resource lookups. Instead of performing a scoped query such as 'WHERE project_id = ? AND workspace_slug = ?', the backend executes an 'unscoped' query based solely on the identifier. This bypasses the multi-tenant architecture entirely, as the authorization logic is decoupled from the resource identification logic.\nThe impact includes the ability for malicious actors to alter project names, descriptions, and other metadata, potentially leading to unauthorized data exposure, process disruption, or organizational misconfiguration within the target workspace. This issue reflects a fundamental flaw in object-level authorization handling where global lookups take precedence over tenant-bound security constraints."
}